One of the smells when practicing DDD (Domain Driven Design) is when you are presented with a Data Model (extracted from an existing set of tables or constructed through rigorous but confirmed hypotheses) and asked to consider this as your Domain Model
Domain Model is not the same as a Data Model
This is an easy trap to fall into because both contain describe some information model and capture references. Yet, there are key differences and there are 2 key things that I would consider
1. Business led or Technology led model?
Ask who created the model?
A Domain Model is created in conversation with Business and Technical Domain experts. The key to this model is language – we capture nuances of language and the context. These help us understand there are subtle variations of the information model in different contexts
For example, if I describe the word “Cart” then you are curious as a domain modeller to ask me the context (Shopping-Cart, Gardening-Cart or Mario-Cart depending on Shopping, Gardening or Gaming contexts)
In contrast a Data Model comes from technical point of view and may not capture behaviour and nuances in language. The risks are that the technical model may have generalised language leading to multiple contexts accessing the same model leading to coupling across these context which we want to avoid. We must evaluate the data model presented in the context of an organisation against the various business domains and contexts in which the software is to be engineered. This comes from business led conversations, domain storytelling and then we can evaluate data models presented to see how various integrated systems master and store these
2. Does the model capture behaviour?
Domain models are richer than simple data models as they capture the behaviour and domain logic. An “anemic domain model” with CRUD style implementation is an anti-pattern as it lacks details about the “how”, “when”, “what-if” etc
Consider an example of an application processing service where the need is to allow users to submit forms with some of their details. This is a common use case (can you identify this in your recent experience?) and in this scenario if purely start from a data model of a form with attributes of an applicant, their address, related contacts etc then when modelling this into a service with end up with a basic accept and persist type service. Our software has no inputs about any other processing to be done on the data leading us to believe we are done and shoving the hard-work to something else down the road. As a result one issue could be that there are multiple services acting on the same model (one for storing the other for processing etc) leading to the store and model becoming shared across the teams maintaining the services and coupling. We lose cohesiveness
Now consider modelling the domain service with processing logic such as validation (what is the minimum required details, some address validation etc.) and business rules (applicant must be local, some date within the form must in current or in some range). This would lead to a domain service that was richer, deeper and cohesive. Changes would be managed by the maintainers of the service and the model would not leak outwards to other areas
Summary
Domain modelling is a process of understanding how to design the software based on business needs and consists of mapping not just the information but also the behaviour, rules and processing logic. Building domain models from a data model (from a system or some other construct) can miss the key ingredients to a good domain model leading to different implementations, ownership and fragmentation. It is therefore key to differentiate between the two and understand where both provide value – use domain modelling is it richer story about how to build software from a business perspective then understand how to apply/enrich a data model
Alok Mishra 