CODEWITHSUNDEEP
domain-driven-designmicroservicessoasolid-principles
user7492327
user7492327

Reputation:

microservice shared domain layer

I have a doubt about Microservices Architecture. We are developing an ERP and there're several microservices such as Human Resources, Identity, Orders and so on.

We've implemented a shared domain layer for entities that are common for all those layers, including abstractions ( interfaces ) of Company, Location and some value objects.

My question is: What's the boundary of shared items for microservices and how bad is that?

In that case, Those shared entities would be the same for each microservice, so that help us to write less code BUT at the same time creates a small level of coupling.

Upvotes: 1

Views: 2686

Answers (2)

MeTitus
MeTitus

Reputation: 3428

My question is: What's the boundary of shared items for microservices and how bad is that?

Up until a few years ago it was complicated to get the boundaries a microservice defined because there was simply no agreement on how to archieve that, but Evans sorted that out a few years ago:

GOTO 2015 • DDD & Microservices: At Last, Some Boundaries! • Eric Evans

Microservices also follow the four tenants of SOA and the same 9 fallacies of distributed system are to take in consideration nevertheless their business scopes are different. Bear in mind that a microservice architecture should follow a Shared-nothing sort of architecture, so services don't really share entities, what they do is subscribe to messages, typically in a bus, and store local copies of the pieces of data they are interested in. This obviously introduce another concept called eventual consistency and depending on your business requirements,that might or might not if in your overall design.

Upvotes: 0

Pedro Goes
Pedro Goes

Reputation: 726

Usually microservice architectures adopt a "share nothing" concept, which mean your code bases should be ideally separate. Yes, that will mean you will write more code but will keep your microservices more manageable, uncoupled and probably lighter.

Also, regarding the DDD-part do the question, you should really strive to keep well defined boundaries within your application, which means you shouldn't be scared to have "redundant" entities in different bounded contexts because the same concept usually mean different things to different domain areas of your application.

Keeping onto the "ERP" theme, you'd expect the "Order Placing" context of your application to have quite a different view on the "Product" entity than that of the "Tax" context. Keeping those in distinct contexts in different code bases will allow you to model smaller aggregates with a higher level of cohesion that will be way less coupled to the other constructs of your model thus, making evolve your microservices way easier.

Upvotes: 5

Related Questions