CODEWITHSUNDEEP
domain-driven-designmicroservicesdata-access-layerentities
Airton Gomes de Lima
Airton Gomes de Lima

Reputation: 1377

In a DDD oriented microservice the Infrastructure and Entities can be reused?

I'm thinking in a DDD oriented microservice architecture as described in this article (https://learn.microsoft.com/en-us/dotnet/standard/microservices-architecture/microservice-ddd-cqrs-patterns/ddd-oriented-microservice). But I'm in doubt about the data access and the entities.

Would it make sense for me to put domain entities and data access into a common project or even into a nugget? Because I think I would be rewriting the same data access multiple times for each service.

Upvotes: 2

Views: 362

Answers (2)

Alexey Zimarev
Alexey Zimarev

Reputation: 19640

No matter if you use DDD or not, the four tenets of SOA are:

  • Services have explicit boundaries
  • Services are autonomous
  • Services share schema and contract, not class
  • Services interoperate based on policy

One of the consequences of this is that services never share their persistence.

There are discussions about how service boundaries align with bounded contexts, but you can start simple and have one-to-one alignment to start with and bounded context is also something that never exposes it's persistence in any other way than using contracts.

Upvotes: 2

Alessandro Santini
Alessandro Santini

Reputation: 2003

TL;DR: no.

Micro services should talk to each other using APIs.

Two reasons:

  • Micro services as aggregate roots define clear transactional boundaries. Reusing code means potentially taking a shortcut that dodges preconditions, postconditions and invariant checks.
  • Secondly, code sharing forces you to integrate changes to the model with all the depending micro services, potentially defeating the purpose of adopting micro services. Having different API version will help you gradually manage that.

Upvotes: 3

Related Questions