Is anaemic model or transaction script good enough for micro service?
Is anaemic model or transaction script good enough for micro service?
While we always talking about anaemic model being anti-pattern, I'm thinking whether it's just good enough for microservice.
As many has mentioned, anaemic model(or transaction script as Martin Fowler call it), is actually good with small applications. Though with monolithic architecture it's understandable we must use more sophisticated structure to handle complexity.
However, with microservice, it's unlikely we pack too much logic in one single service. Instead a service usually only contains related logic in one single domain, which is usually easy to understand and work upon. In this case, is it totally fine to use transaction script model inside microservice?
Thanks. It's right I don't expect services to literally 'micro'. Actually having been using micro service for several years, my personal experience is that we should try to avoid splitting services when possible. So right now we are managing some services with up to 30k lines of Java code and still growing. Unfortunately most of the logic is still in plain script style, so I'm just wondering is it worth to fully embrace DDD at this stage of development
– fankai
Aug 26 at 3:57
2 Answers
2
Hi That depends on the project,you keep in mind that we need to use rich models in ddd's approach because the nature of these projects with a domain approach is rich, and we need to use rich domains in those projects, and now in projects that They do not have an ddd’s approach, and I mean data driven projects are. We, too, have Anemic models that answer our work.
So That depends on the project and the approach taken for that project.
below link can help you:
https://blog.pragmatists.com/domain-driven-design-vs-anemic-model-how-do-they-differ-ffdee9371a86
Martin Fowler's Patterns of Enterprise Application Architecture is probably a reasonable starting point.
If you have complicated and ever changing business rules involving validation, calculations, and derivations, chances are that you'll want an object model to handle them. On the other hand, if you have simple not-null checks and a couple of sums to calculate, a Transaction Script is a better bet.
Another heuristic to consider is whether or not this specific micro service contributes to your companies competitive advantage. If you are building something you would rather buy, then a heave investment in domain modeling doesn't make a lot of sense.
On the other hand, if you are expecting to live in this code until it becomes catastrophically successful and you all retire to a beach somewhere, then domain modeling becomes more compelling.
Horses for Courses.
By experience I dont feel that a domain model is any slower to implement for simple use cases though. I'm pretty sure it's viable to always use a domain model if you are already an experienced modeler.
– plalx
Aug 25 at 12:38
@plalx: For simple stuff like showing some aggregated data from a db based log etc. you don't need DDD and a simple CRUD service does its work to. It boils down how much business logic is involved and how vital its for the business
– Tseng
Aug 25 at 16:10
By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.
Could be you got the wrong impressions about microservices. Just because its called "micro" doesn't mean there is none or little logic in it. DDD in Context of Microservices usually means, microservce = a bounded context. For simple CRUD applications you don't need any DDD etc. (such as fetching logs from a database or generating a report based on some aggregations)
– Tseng
Aug 25 at 16:13