We are often told to avoid sharing business data across service boundaries. However, I tend to see the need for a service to access data from a different service.

An example of this would be IT functions needing to access employee position and corporate structure (i.e. the managerial ladder) - this information is typically maintained by HR. Specifically if there is an IT policy that only directors and above are eligible to request certain IT devices if they do not have ones already from the company. In order to enforce this rule, the IT service will need to access HR data as part of its business logic to accept/reject such requests.

The SOA guideline is also not to couple services via request-response communication purely to ask for data.

If data sharing is discouraged across service boundaries, how could other services enforce their dependent business rules on data from another service? For example the request of an IT device cannot be initiated from the HR service.

What is your advice?

  • 1
    If you need to share data, then you need to share data, "SOA guidelines" notwithstanding. If said guidelines are preventing you from doing something you need to do, maybe it's time to revisit the guidelines. Ask yourself " what does this guideline add to my system that benefits our system and user requirements? " If the answer is " nothing " then scrap the guideline, or at least reevaluate it based on your specific needs. Apr 15 at 17:23
  • @RobertHarvey Maybe there is something I am missing that would allow me to maintain the decoupling and data ownership in such scenarios.
    – geeko
    Apr 16 at 11:02

5 Answers 5


We are often told to avoid sharing business data across service boundaries

I don't know who told you this, but is sounds to me like misinterpreting a strategic recommendation how to draw service boundaries (ideally in a way which reduces the need of sharing lots of business data) as some dogma about not sharing any business data.

IMHO this makes not much sense.

When two services both need the same data, then they need to share them - fullstop. Of course, it helps to organize and scale a system by having each piece of data only stored and/or maintained in one place (service), and provide other services only copies of the data they need. Using your example, an HR service maintains and manages employee data, and an IT service just gets a copy of it.


I suspect the real advice is: don't try to draw service boundaries across data flows (and not "avoid sharing business data across service boundaries").

In other words, you start by determining the necessary data flows to support the functionality you want, and you can then draw service boundaries in the gaps (if any).

You don't start by drawing the service boundaries (on what criteria, arbitrarily?), then wondering how on earth you do or don't get data to flow across them.

Implicitly, it seems the very definition of a "service boundary" is a relationship between two services where there is a de facto absence of data flow.

If there is a data flow in one direction, then the sending service can be considered distinct, but the receiving service is now composed of the sending service. The receiving service is treated as having no boundary against the sending service (or existence independent of it), although the sending service continued to have a boundary against the receiving service.

Implicitly now, a "service boundary" is not just a relationship between each and every pair of services, but it's a relationship that has a different nature depending on which side of the relationship it is viewed from (and which way data flows).

If there is a data flow in both directions between supposedly two separate services, then there cannot be a service boundary, and you are in fact dealing with the internals of a single service.

I don't know whether this complicated scheme of services, with their containment and relationships, is useful in general.

With just 4 services in this conceptual model, you have 12 bilateral pairings and thus 24 boundary statuses to keep track of.

I suspect in most businesses, no data is sufficiently isolated that more than one "service" can exist (and such "services" as are claimed to exist, are just fancy ways of describing the parts of one business information system, whose real nature is monolithic and indivisible).


Maybe a perspective that is really important here is data ownership.

I would treat data read(reading data I can't change and don't own), and data write (making changes to the data I own) as two separate contexts.

As for data writing, only the data owner should be able to change it and apply any business rules to that data change. On that aspect, it must be aligned to "Service" boundaries and no other "Service" may have access to change that piece of data.

However, when it comes to data reading, technically, any "Service" or a technical component can read data as long as they don't try to change it or treat it as its own data.

On a technical/implementation level, one might take many different approaches, from publish/subscribe to Provider Patterns to data warehousing and data lakes.

Hope this helps


Before the advent of microservices there was a strict separation between atomic services and orchestration services. These kind of issues (the access of to the HR data and the filtering out of unnecessary data) would be addressed in an orchestration layer and the IT functions at an atomic level would receive in input all the data they need and only the data they need.


Accessing HR data is a wrong approach. Instead, there should be a system that manages authorization (permissions). Employees should get permissions in this system. When a new employee is being onboarded, administrators should be instructed by HR department to give this employee corresponding permissions. If employee role from the HR view changes (new role assigned), again the HR department should instruct the admins to assign corresponding permissions.

Thus the authorization service should have no connection to the HR data.

Applications should only use authorization service.

Thus, no application needs any access to HR data.

  • 2
    Dear, my question is in the context of SOA, not cybersecurity. I am asking how to decouple not how to secure.
    – geeko
    Apr 15 at 16:25
  • @geeko: I explain you how to decouple. Business application, authorization/management and HR management should be 3 separate applications, not 2. This is decoupling. Put authorization logic to a separate application - this is decoupling.
    – mentallurg
    Apr 15 at 17:08
  • If an employee is promoted and get new role, the contract may be effective in 1-2 months. But if the company trusts this employee, the HR may decide to give some permissions related to the new role now. If you us HR system as a base for access management, you will not be able to implement it. If you decouple it as I described, you can give access permissions at any time, without having to wait until HR system implements it.
    – mentallurg
    Apr 15 at 17:12
  • Another example: An employee was suspended, but the contract will end in 2 months. All this time this employee has all the roles. You will not be able to cancel any access permissions. But if you decouple as I described, you will be able to revoke access permissions at any time, without having to wait 2 months until the contract ends and the employee doesn't have the role in the HR system.
    – mentallurg
    Apr 15 at 17:16
  • As long as you use HR system as the base for access management, you will not reach decoupling.
    – mentallurg
    Apr 15 at 17:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.