CODEWITHSUNDEEP
domain-driven-designmicroservices
Vitor Villar
Vitor Villar

Reputation: 1925

How to slice down a monolith where my domain depends heavily from other domains?

I'm currently learning about Microservices because in the company where I work, we will split down our giant monolith into microservices.

We have a lot of business logic in our application, but this rules basically validate data from many different domains and act accordingly the status of this data.

Our domain has it's own data, of course, but I even dare to say we depend something like 60 ~ 70% of data from different domains, which makes our domain kind of an aggregator.

I created a little diagram to illustrate it: enter image description here

So like I said before, my domain (Domain A) has a lot of business logic to validate data and status from all those different domains. And then after this validation, take the appropriate actions and save the result of it in the DB.

I feel like I hit a dead end, cause I have read a few articles how to break down a monolith, but I haven't got any good example where it explains this situation.

So I ask you guys, do you have any suggestions to tell me? :) Thanks!

Upvotes: 0

Views: 257

Answers (2)

Eben Roux
Eben Roux

Reputation: 13256

In DDD speak a bounded context approximates a microservice. The different domains in your diagram are probably going to be bounded contexts.

You most certainly do not want concepts from various BCs polluting each other as you are going to end up with quite a mess.

There is one place, however, where you may run into this and that is on integration/orchestration. Here you should approach this concern almost as a separate BC that relates to the orchestration or integration.

For instance, let's assume that you have an Assets domain and an Accounting domain. The two should know nothing about each other. However, when you decommission an asset (say some huge machine that grinds down rocks into stones) you perhaps need to have the accounting domain register some write-off value if the asset has not reached the end of its useful life. In this layer you would integrate the various bits of your process and manage the state using a process manager. Although the process manager, and related state, may belong to the Assets BC the AssetsOrchestration BC may make use of objects from both the Assets as well as the Accounting BCs. Typically you would attempt to limit that interaction to, say, messages using some messaging infrastructure but YMMV.

Upvotes: 2

VoiceOfUnreason
VoiceOfUnreason

Reputation: 57307

A good starting point may be Sam Newman's Microservice Decomposition Patterns.

About 18 minutes into the talk, Newman offers this pattern:

  • Within your monolith, identify the coarse modules of functionality.
  • Draw the dependency graph
    • OK, your dependency graph has cycles in it. That's no good, you want an acyclic graph. So iterate on the graph until you are able to eliminate the cycles. DO NOT PASS GO until you have this done
  • Identify candidate modules that have no inbound dependencies - you want the bits that nothing else depends on.
  • Pick one, and see if you can redesign your system to allow you to deploy that module independently of the monolith.

Upvotes: 0

Related Questions