I have a very simple scenario but for some reason I am not being able to get my head around it.
I have to design an IT Device Request where the device eligibility is dependant on the requestor’s position and whether they already have another device of the same kind. Therefore, the request handler will need to read HR data (i.e. user’s position) and IT data (i.e. user’s devices).
I am trying to avoid request/response with HR service and also do not want to duplicate the HR positions in the IT service. To be honest, a lot of services need HR data to enforce their business rules. What do you suggest?
I agree, you should not be querying the location from another component but could you change it in such a way that the location gets published so that the thing that you are building can take a subscription to the location?
In regard to who owns location depends likely on the “latitude/longitude” vs mapping to a zone, office, floor, vehicle.
The fact that currently all of that is stored in HR might be a ownership issue. To me it feels more that HR could represent a user interface that shows data from various sources but that is just a very short 1 minute thought on your question.
Could the publishing of location help your problem to prevent querying?
Hi @ramonsmits and thx for passing by. I should have clarified what I mean by position in the HR context: it is the level of the employee on the managerial ladder (e.g. Directors and above).
I can subscribe to the HR events of PositionHeirarchyStructured/PositionHeirarchyRestructured, which can also include an ordered list of position IDs but I have no clue which ones represent “Directors and above” without querying back to HR from the event handler.
I have two questions here:
1- Should the HR events include the position IDs in the first place?
2- Is there a better solution than querying back to HR from the event handler?
Why wouldn’t the HR boundary not contain any information about the devices? In what boundary would you currently want to store that information?
A service boundary isn’t a physical mapping to a single ‘service’. Everything within a logical service boundary is allowed to access data as its assumed everything in it is tightly coupled and often maintained as a single repository. It could have multiple physical deployments of all kinds of components.
Events leaving a service boundary must avoid sharing anything else than IDs, timestamps, and state transitions as that would mean sharing schema thus increasing the risk of coupling.
Under the assumption that all this is tightly coupled your logic could even query directly to storage.
There is an exception though. Within ADSD there is a special boundary that is named ITOps. It’s a boundary that contains a lot of logic and rules around infrastructure, security, etc. Maybe your problem is related to that? Logins, org units etc, often are managed in that boundary. These could be partially mapped to some organization data that is owned by your HR boundary.
Maybe you might want to view the following presentation on the topic of finding your boundaries:
HR service is handling hiring, firing, promoting, performance evaluation, position structuring, position assignment, organization structuring, and the like. I do not think IT devices fits in here.
IT service is handling many things including assigning IT devices to employees upon their request. IT has a policy that certain IT devices (e.g. MS Surface Pro) are only assignable to employees of position equivalent to directors or above. I think IT devices fits in here, but not HR positions, except for their IDs of course.
Now assuming that HR is publishing events like PositionHierarchyStructured and PositionHierarchyRestructured with an ordered list of position IDs from highest to lowest position. How would IT know that the 6th position ID on that list corresponds to, for example, the Director position? Are we hardcoding the number 6 in the IT event handler? Are we querying back to HR asking which one is which and hardcoding the name of the position instead (i.e. “Director”)?
I hope that I did not get my service boundaries wrong after watching the ADSD online course multiple times I also have watched the mentioned presentation and other ones. I do not think I have a physical/logical view issue here.
@ramonsmits what’s your thoughts on my question in the previous post? Also, do you see the order in the events’ list of position IDs as communicating HR domain knowledge that should not be communicated?
So, you are not actually interested in the position in the hierarchy. You are interested in a certain capability of the requestor: permission to get category x devices.
What the underlying condition or rule is for this permission is something you don’t care about. That is the responsibility of HR, not IT Service.
When you get the hierarchy from HR and decide inside IT Service if someone is allowed to get a certain device, then it’s not under control anymore of HR.
So, if you follow this alternative thinking, you maybe come to different solutions. Like a permission/capability request-response, or move a capability inside AD, publish permissions/capabilities, etc.
Hi @remyvd and thanks for joining. Yes, what you are saying makes perfect sense! The policy should have been owned by HR not IT, then HR can publish an event that EmployeeIsEligibleForSeniorManagementITDevices whenever the underlying rules are met. I am now thinking how HR will come to establishing such policy that includes a technical aspect related to IT although they are not IT and maybe do not realize the full drivers behind it. Maybe I am wrong… though IT will certainly have an influence on such HR policies, which should be discussed during the system design.
Like a permission/capability request-response, or move a capability inside AD, publish permissions/capabilities, etc.
I am not sure I understand your suggestions here. Why would you suggest a request/response?
I guess you are referring to Active Directory by AD where the HR eligibility events are translated into IT as permissions in AD, right?
To me it is not a technical aspect. It’s a specification of an IT budget that is being agreed on during contact negations. Same as the allowed budget for a car.
I know you try to avoid this but can solve it by ask the HR-service if the requestor has the specified permission (or ask for all the permissions) using request-response flow.
Instead of messages you can also directly call the service by making an HTTP call inside your handler. It’s ok to do that for queries.
But you can also let HR-Service publish an event and subscribe to that.
What I personally would not do is to call it ‘EmployeeIsEligibleForSeniorManagementITDevices’-event. This has the current decision logic into the name. What if that logic changes to middle management? Or what if a requestor agrees with HR that he is entitled to a Surface Pro, even he is not Senior Management?
Normally you would have IT budget levels or classifications.
Yes, kind of. I meant to optional store it as a Claim in AD. But that goes too far for this case.
I could not get something even close to such informative discussion on other famous QA websites. Most “reputed experts” there just told me that what I am after of decoupling and not sharing business data across boundaries is dogma and if two services need to share such data then they need to share it, period It even came down to “who told you this advice…” and the like.
Anyhow… I appreciate your time and to have this open-minded discussion forum!
We could split the policy into two different stages. A human presumably performs policy configuration and policy evaluation/execution.
The execution doesn’t need anything else than:
the current employee position ID, which I assume comes in with the AssignDeviceToEmployee command (EmployeeID, DeviceID, EmployeePositionID)
some configuration data explaining which device IDs can be assigned to employees’ positions IDs
During the execution phase, there is no need for “labels”. The policy/saga doesn’t need to know that employee position 12 means VP and device ID 3 means MS Surface Pro. That’s a human concern. That leads me to the policy configuration part.
Assuming a sort of back office allows an operator to set configuration options, they need to see labels; they cannot really work with IDs. That seems to be a ViewModel (de)composition concern. The configuration UI can compose data coming from IT and HR to show that the configured IDs are labeled in specific ways. When the back office operator updates the configuration, a decomposition process sends the relevant IDs to the IT service for later usage in the policy.
Many thanks for the suggestion dear @mauroservienti.
I just managed to see it as I did not think there is more options to add to the discussion.
Actually, your suggestion is a middle ground when upper management refuses to transfer the policy from IT to HR.
It’s more of a data decomposition process rather than a transfer. Not all data must reside in the same service when dealing with distributed systems. In many cases, we end up with data in the same service because we think in terms of presenting those data to humans, and if all the data are in the same place it’s easier.
How departments work in the company, or think they work, doesn’t mean they have to work in your system.
In the past I worked at a company and tried to get information about how prices were defined. Sales mentioned they were responsible and came up with the prices. I asked them how they figured out what the cost was (it was a digital product) and what they should charge to make enough money. They said it was experience and more excuses.
When I then spoke to finance, they mentioned they always provide what something costs to sales. And that they made up the cost, because they learned from experience what sales would do with it. They knew (as a simplified example) that if they told sales cost was 1 USD, that sales would charge 2 USD. But if the price needed to be 3 USD to actually make money, finance would just say it was 2 USD because they knew that sales would make the price 3 USD.
So it’s not always the full truth what departments and managers tell you, but that’s because often times no one really knows how processes go and everyone bends the “rules” because of experience. It still works, but it’s very hard for us to come up with how a company actually works