Cristian Batista
Cristian Batista

Reputation: 281

DDD Microservices

I've been researching DDD pattern for a few weeks ago and I got no answer for a question.

Following Eric Evans principles, the Domain module should have no dependencies with other modules, packages or anything. And here should be included all the models such as errors, entities, interfaces...

My question is, if for example, an error template is shared between all the microservices, should be repeated the same object on each microservice?

I think this gives an awesome modularity on the project because it have no external dependencies but the scalability is poor because on any change it is mandatory to change every microservice.

Have you got any thinking about this? Thanks.

Upvotes: 1

Views: 202

Answers (1)

Savvas Kleanthous
Savvas Kleanthous

Reputation: 2745

The guideline exists so as to:

  1. Not have your domain depend on shared libraries. This would impede development (and changes) in one domain because it would break another domains behaviour.
  2. Helps us make sure that we're not duplicating business behaviour across domains. This is very important.
  3. Not have your domain depend on infrastructure. I have a strong suspicion that this was far more important at a time when people used to put domain logic in stored procedures, but it's still quite relevant today because it ensures that logic is isolated and independent from repositories, storage, etc. making it very easily testable.

Considering the above, one can understand that some sharing is fine. Indeed, you're already sharing some stuff already: basic language structures and base class libraries. Sharing some helper libraries is absolutely fine and indeed in some cases, it helps immensely to do so. You should be very careful when doing so though:

  1. Sharing business logic in the form of shared helper libraries violates the first rule above since business logic can change as our understanding of our domain changes.
  2. Sharing domain-specific data structures violates the first and the second rule from above. Domain specific data structures can change as our understanding of the domain changes and having multiple domains depending on them will impede this process. It also violates the second rule because domain-specific data strucutures implicitly carry behaviour with them.

Specifically in your situation, it really depends on what an error template is:

  • Is it similar to some data structure that makes sure that exceptions contain some basic set of information that is useful in debugging and doesn't include any domain-specific data structures? If so then it's probably fine.
  • Does it accept domain-specific data structures? Then I would say it's not fine
  • Does it contain any domain-specific behaviour to interpret some domain-specific data and fill the template? Then again no.

Upvotes: 5

Related Questions