Anemic Model is considered an anti-pattern in Domain Driven Design. Based on Martin Fowler, Anemic model is a situation where we are declaring unnecessary model throughout our system. These model consists of classes that mostly having getter and setter. Anemic model does become a plague when we have n-tier application. Where each tier declared or created a specific classes to perform their task in their tier boundaries. Sometimes we are force to create a specific data model at a specific tier, but having unnecessary data model is what lead to Anemic Models symptom. In this article, we will discuss on how to design our system to reduce the risk of having Anemic Models.
Properly Decide Your Micro services Domain/Functions
We need to be able to get the big picture on how to design our micro services. It is not necessary to implement an atomic services for each table in a database for example. Having these pattern in our system will introduce a lot of soap/rest call to other services when we are dealing with relationships. It is advisable to segregate the micro services based on its functions like Accounting Module, Human Resource Module etc . With these technique it will significantly reduce the needs to perform unnecessary Anemic Models in our micro services. Example Accounting Module, does interact with Warehouse module and sales module but doesn't interact with human resource module.
Pick When Should We Avoid Data Conversion
Performance, it takes machine operation to perform object transformation, These domain object mapping algorithm will somehow introduce overhead in our machine execution. It somehow will cause unnecessary processing but with the same results by using original previous tier object model. Before we started to create an object conversion at a specific layer, we should decide if we should really need to create a new Object Model and perform the mapping/object conversion to that particular specific Tier.
Prepare Some Sweet Data For The Next Layer
In micro services, chances is going to be a specific layer performing their domain tasks, with consideration on how the next layer will implement/process based on the transmitted data, we might able to reduce the next 'layer' load by performing 'short cut' transformation/processing at the business layer. Take an example of accounting module is calculating an invoice total, we might perform the calculation of 'Total' at the accounting module rather that at the presentation layer or vice versa. These need a proper design plan and estimation of the future system users behavior.
Front End Model Design
If we are using a tightly coupled front end / presentation layer, It is somehow quite hard to not to create a specific class for presentation layer. Here is the tricky part. At this stage we are required to really consider reusing/refactoring repeatable line of code, and possibly avoid creating a new 'FrontEnd' model. Its totally different with SPA/Mobile Apps, where we may declare the presentation model at the client side, this is then will go back to on how the micro services is designed and how we wanted to perform the object/data delivery.
Ref no : DTC-WPUB-000093
About Author
Comments
Post a Comment