Entity Services is an Antipattern
- Share
-
- |
Read later
Reading List
A note to our readers: You asked so we have developed a set of features that allow you to reduce the noise: you can get email and web notifications for topics you are interested in. Learn more about our new features.
In a microservice based architecture, it is important to keep the different services separated. Entity services is a common pattern now applied to microservices, but entity services is an anti-pattern that works against separation, Michael Nygard claims in one of a short series of blog posts on how to work with microservices.
Nygard, among other things author of Release It!, notes that entity services is a solution to a problem that is commonly rediscovered, and refers both to a microservices architecture e-book from Microsoft and a tutorial from Spring for two of many new examples of usage of this pattern.
For Nygard, an antipattern is a pattern that makes things worse. In arguing that entity services really is an anti-pattern, he uses a large legacy monolithic application as an example. In this application there are multiple instances of the process with all features local and in-process:
Moving this application to a microservice architecture, using an example from the Spring tutorial, some feature will still be contained in one of the services, but Nygard claims that most features will require aggregates consisting of more than one entity, thus creating dependencies between two or more entity services. One example is setting the price on a cart which will involve all services depicted:
For Nygard these dependencies lead to an operational coupling which will affect availability, performance and capacity. He also notices that they create semantic coupling where a change in one service may ripple through to other services. In worst case scenarios this may even result in a service needing to deal with different versions of services.
For Nygard, the resulting context when moving to a microservice architecture with entity services includes:
- Teams can still deploy in their own cadence.
- The semantic coupling requires cross-team negotiation.
- Entity services are invoked in most requests, increasing the load.
- The overall availability is coupled to many services.
By this, Nygard believes the criteria are met for claiming that entity services is an anti-pattern.
In another blog post, Ben Morris, principal architect at Fourth.com, claims that entity services used in a microservices architecture is worse than a monolith and refers to Nygard's post. Morris argues that an important aspect of microservices is autonomy, but the more fine-grained services are the more they become coupled to other services, thus undermining this important autonomy. He notes that changes to a process may be hard as it tends to touch numerous services, and even harder if they are maintained by different development teams. A risk with small coupled services is also that failure in a single service can have a cascading effect, bringing down several processes.
Nygard's post spawned a long discussion. One of the authors from the Microsoft e-book notes that they in the book warn against coupling microservices with HTTP calls. He also notes the importance of having the right domain models to be able to make microservices autonomous.
In an upcoming blog post Nygard will look into alternatives to entity services.
Rate this Article
- Editor Review
- Chief Editor Action
Submit
Submit
Hello stranger!
You need to Register an InfoQ account or Login or login to post comments. But there's so much more behind being registered.Get the most out of the InfoQ experience.
Tell us what you think
Community comments
Great read
by
Vadim Samokhin
Posted
Re: Great read
by
Jan Stenberg
Posted
Re: Great read
by
Richard Clayton
Posted
Alternatives?
by
Pavel Grushetzky
Posted
Re: Alternatives?
by
Richard Clayton
Posted
Re: Alternatives?
by
Pavel Grushetzky
Posted
Re: Alternatives?
by
Chris _
Posted
Re: Alternatives?
by
Roland Heimdahl
Posted
Re: Alternatives?
by
Pavel Grushetzky
Posted
Re: Alternatives?
by
Adrian Ivan
Posted
Re: Alternatives?
by
Richard Clayton
Posted
Agree
by
Mileta Cekovic
Posted
Real-world context is everything
by
Rayna L
Posted
More input
by
Jan Stenberg
Posted
Consequence of a bad name
by
Erik Gollot
Posted
Great read
by
Vadim Samokhin
Though it's just one of the ways (still very popular) to identify service boundaries wrong. There are many more, listed here.
Alternatives?
by
Pavel Grushetzky
Interested in seeing the alternatives. Useful conversation arises from multiple approaches compared in context of the same problem.
Re: Great read
by
Jan Stenberg
Shaun, I followed the link, it was an interesting read. I think that domains, boundaries and contexts is also very well explained in Vaughn Vernons Implementing Domain-Driven Design
Re: Great read
by
Richard Clayton
Agree with Jan here. A "bounded context" seems to be the logical criterion for what "goes into a microservice". I feel like Shaun's link is the author's (Shaun?) journey towards "rediscovering" the core principals of DDD.
Re: Alternatives?
by
Richard Clayton
I seriously recommend looking at DDD. 95% of the concepts originally defined by Eric Evans, and later championed by Vernon Vaughan and others, have beautifully detailed the thought/design processes you need to design microservices (long before microservices were "a thing").
One of the failings, in my very humble opinion, with articles like these, is that they detail the operational/tactical struggle the author has in defining the responsibilities of services. When things "don't work", then it's an "anti-pattern". However, when you apply a methodology like DDD to the problem, you start at the strategic level which helps create the boundaries of your business and supporting subdomains. With those guidelines, you can begin to narrow down to operational and tactical design/planning which will help alleviate the problems the author describes.
Keep in mind that DDD advocates this strategy regardless of whether you are building a monolith or microservice -- you're probably going to split your code base up into modules anyways, be it a microservice or Java package, etc. The principles of splitting up the codebase are generally the same, regardless of whether cross-domain calls are to local functions or network requests to another service.
One of the failings, in my very humble opinion, with articles like these, is that they detail the operational/tactical struggle the author has in defining the responsibilities of services. When things "don't work", then it's an "anti-pattern". However, when you apply a methodology like DDD to the problem, you start at the strategic level which helps create the boundaries of your business and supporting subdomains. With those guidelines, you can begin to narrow down to operational and tactical design/planning which will help alleviate the problems the author describes.
Keep in mind that DDD advocates this strategy regardless of whether you are building a monolith or microservice -- you're probably going to split your code base up into modules anyways, be it a microservice or Java package, etc. The principles of splitting up the codebase are generally the same, regardless of whether cross-domain calls are to local functions or network requests to another service.
Re: Alternatives?
by
Pavel Grushetzky
I agree that defining the boundaries is a central topic here.
Thus would like to see what boundaries the author would suggest for this scenario; what exactly would work better than Products/Accounts/Carts/Orders.
Thus would like to see what boundaries the author would suggest for this scenario; what exactly would work better than Products/Accounts/Carts/Orders.
Agree
by
Mileta Cekovic
Agree on this: Entity services used in a microservices architecture is worse than a monolith
Entity services couple microservices too badly that the end result is more complex, harder to deploy, less scaleable, less performant... then monolit. No benefits, just drawbacks. Microservices should, like all other services be Aggregate and Use Case driven, not Entity driven (should we call Entity services nanoservices ? :))
Entity services couple microservices too badly that the end result is more complex, harder to deploy, less scaleable, less performant... then monolit. No benefits, just drawbacks. Microservices should, like all other services be Aggregate and Use Case driven, not Entity driven (should we call Entity services nanoservices ? :))
Re: Alternatives?
by
Chris _
I agree that defining the boundaries is a central topic here.
Thus would like to see what boundaries the author would suggest for this scenario; what exactly would work better than Products/Accounts/Carts/Orders.
An interesting possible answer for an alternative would be not to use microservices but some other architecture. Not to say there isnt a microservices way around the stated problem, Just bringing up the simple point that there may be cases were microservices dont add value.
Re: Alternatives?
by
Roland Heimdahl
Try the verbs for the tasks that the users/systems are doing.
* ManageProducts, not Products
* DevliverProducs, not Products or Delivies
* ManageOrders, not Orders
* ManageMyAccount, not Account
* AdminAccounts, not Account.
Each of these context will contain a set of activies and will therefore need a set of data (probalby overlapping sets of data). Now you can resolve how to handle exchange of data between the contexts, how to handle if a context is temprarly missing etc etc.
Slightly oversimplified (since this way of thinking have its own set of problems) but i belived that is is a good start to think outside the nouns (box is a noun :-)).
* ManageProducts, not Products
* DevliverProducs, not Products or Delivies
* ManageOrders, not Orders
* ManageMyAccount, not Account
* AdminAccounts, not Account.
Each of these context will contain a set of activies and will therefore need a set of data (probalby overlapping sets of data). Now you can resolve how to handle exchange of data between the contexts, how to handle if a context is temprarly missing etc etc.
Slightly oversimplified (since this way of thinking have its own set of problems) but i belived that is is a good start to think outside the nouns (box is a noun :-)).
Re: Alternatives?
by
Pavel Grushetzky
This is why I strongly believe that the preferred alternative is best presented
- in the same level of details (which is ~5 pages and 4 diagrams)
- in context of the same problem ("suppose we need to calculate the total price of a cartful of items")
- with pros/cons compared to the less-preferred approach
Otherwise it is easy to get lost or misinterpret the description, which may come across like "rename your domains and figure out what belongs where".
- in the same level of details (which is ~5 pages and 4 diagrams)
- in context of the same problem ("suppose we need to calculate the total price of a cartful of items")
- with pros/cons compared to the less-preferred approach
Otherwise it is easy to get lost or misinterpret the description, which may come across like "rename your domains and figure out what belongs where".
Real-world context is everything
by
Rayna L
If your Product Service is the size of an Entity Service (Entity Services being defined as "...finely-grained services that look after a single data entity, normally exposing nothing more than simple CRUD methods..."), then you probably don't need a microservices architecture right now.
Large retailers however will probably need a stand-alone solution just to deal with some part of the Product domain (www.google.co.za/search?q=Production+Informatio...).
Large retailers however will probably need a stand-alone solution just to deal with some part of the Product domain (www.google.co.za/search?q=Production+Informatio...).
Re: Alternatives?
by
Richard Clayton
I agree with you about modeling services around behavior - this is definitely the correct practice.
In the case of "Entity Services", I don't it's unreasonable to keep services small (maybe encapsulating one or two aggregate roots and related models). In this case, it's possible to have something that resembles an "Entity Service" but really just be a very small microservice.
In the case of "Entity Services", I don't it's unreasonable to keep services small (maybe encapsulating one or two aggregate roots and related models). In this case, it's possible to have something that resembles an "Entity Service" but really just be a very small microservice.
Consequence of a bad name
by
Erik Gollot
Agree with your vision and yes it's a misunderstanding of wgat is a DDD context.
But it's also one of the consequences of a very very bad name : micro-service
But it's also one of the consequences of a very very bad name : micro-service
