Through my journey of building Domain Models I had good and bad experiences that today I share with you to save a few hours of your development time. These are opinionated approaches that I follow when building Rich Domain Models. A Rich Domain Model is the technical part when applying DDD, it involves the building blocks like Entity, Value Objects and Aggregate Root. The goal is to build a ubiquitous language between developers and stakeholders using a vocabulary that describes the business rules. What are the business rules? Its what’s make or save money, irrespective of whether they were implemented on a computer or manually. This kind of rules are simple to be described in words as they do not require a database, in fact the database is just an IO device that our software requires to persist state. We could say the same about the Web, it is only a delivery mechanism to present information to our users and has nothing to do with the business rules. Having that clear is my way of thinking but what I find in our industry is a spaghetti of business rules, persistence libraries and frameworks code. In the next few topics, I’m going to expose code issues we want to avoid before you decide to invest time building rich domains models. The code issues I am referring to are known as code smells, and they are associated with architecture and development problems. The opposite of the Rich Domain Models are the Anemic Domain Models, in this second one the business logic is implemented far from the classes that own the data, it brings low cohesion and nonexistent encapsulation. The next topics introduce common code smells related to Anemic Domain Models.
