9

I'm working on breaking down a monolith application in smaller applications or microservices. Like always, sometimes it's easy and sometimes it's harder to identify domains and split those into smaller applications and databases.

I've found a number of domains (I'll show you two as an example) which all share the use of a set of entities (units of care or so called care units). These care units are updated once in a while by data integration tools (SSIS). There are over a milion of care units in the database. In the example below, you see how different domains all act on these care units. Simplified application architecture - domains using care units

We could duplicate those care units to every domain, but I think this would add a lot of complexity considering synchronization issues etc. At the moment we can just do aggregations between these domains using simple join queries in SQL Server. Are there other ways to achieve what I want without a lot of data duplication? If not, what are recommended ways to synchronize tables between domains?

Our application is written in c# .net using SQL Server as a database. So answers using these technologies are preferred, but not mandatory.

4
  • I would keep the domain separation and just have the CareUnitId in your Policy and Contract objects
    – Ewan
    Commented Jan 22, 2020 at 11:10
  • The problem is in groups. What if I want to know which policies belongs to which contract. The contract has a CareUnitId and the policy has a CareUnitGroupId. I would have to first get all care units for that care unit group, which could be thousands. Then I would have to find all policies that have those CareUnitIds.
    – annemartijn
    Commented Jan 22, 2020 at 11:53
  • you have to do that any way you cut it
    – Ewan
    Commented Jan 22, 2020 at 15:10
  • Sometimes it's good to step back and look at the big picture; while there might be a way to decouple these, reconsider if you should. What is the relationship between the two? Do clients use them together? What's the usage pattern? Do contracts and policies even need to be retrieved separately in every (or any) case? If the two are fairly related, can you just consider them parts of a single service that serves two closely related needs?
    – Filip Milovanović
    Commented Jan 22, 2020 at 17:30

2 Answers 2

Reset to default
5
+50

The point of microservices is to enable independent development and operation of parts of a larger software system. What is your goal in this project, what is the reason you are doing this?

A microservice is not a subtree of a data model. It is a closed, feature complete part of the whole, that has (ideally) no request-response dependency to other systems, let alone common data. Again, this is not a random rule, it is necessary to be able to individually evolve and operate the service, which in turn makes it possible to maintain such systems.

So to achieve a proper separation, here are the questions for any potential boundaries:

  1. Does this separation serve my project goals? For example: does this let me scale this part better, does it enable this team to accelerate their release cycles, etc.?
  2. Does it result in an adequately independent system?

There are some tools with which you can cheat, but you have to use them sparingly if you want to keep your sanity. These tools are:

  • Synchronization of data. This has to be offline to be independent, so "eventually" consistent.
  • Submit the necessary data as parameters in the request. This means the target service doesn't need to keep those.
  • Integrate through hypermedia (Web/HTML) and have the client coordinate calls and data it has based on forms and links.
3
  • As for question 1, yes this would lead into splitting the system in smaller subsystems that developers could work with. This will lead to smaller release cycles and it will increase testability. Question 2, well that depends on your definition of independent. The software solution would consist of roughly 30 subsystems, which all serve different purposes but you would always use groups of them to execute business purposes. What would you recommend as eventually consistent data synchronization solutions? And are there alternatives? Special mult-api join databases perhaps?
    – annemartijn
    Commented Jan 22, 2020 at 15:42
  • 1
    @annemartijn My point was, that there can not be an independent release cycle, nor independent development, if business functions span multiple services. Changes from business people are usually framed in business-function terms. If those span multiple services, well, your teams will have to coordinate most of the time. I hesitate to propose a technical solution to synchronized data, since I think that may only make your problems worse.
    – Robert Bräutigam
    Commented Jan 22, 2020 at 16:05
  • @annemartijn - "that developers could work with", that's too vague. The architectural/design aspect of microservices is less about organization of code/work, and more about alignment with the axes of change in the domain. The way you minimize interdependencies is you design the boundaries around domain concepts that have low coupling, or around things can be reconceptualized & restructured so that there is long-term low coupling. So consider rethinking the design itself (or some aspects of it). Or just have a brainstorming session, throw ideas around, see what happens.
    – Filip Milovanović
    Commented Jan 22, 2020 at 17:14
2

It's fair for microservices to access other services for data. I'd look into the saga pattern for ideas how to deal with distributed data in a microservices architecture.

Your Answer

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

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