Database terminology or naming creeps into the code
Design pattern terminology creeps into the code which is not how the business talks
Properties, methods, events,enums, etc should all use the terms used by the business users
Industry may seem more “proper” or “correct” but if the business uses the term so should you. One exception is when you are building an app to be used by multiple businesses in the same industry.
Making your code read like the business speaks
Database terminology or naming creeps into the code
Business usually talks in focused areas. i.e. Inventory or Invoicing or Accounting.
Business usually talks in focused areas. i.e. Inventory or Invoicing or Accounting.
Except in the smallest of apps
Aggregate roots will overlap with each other. This is fine. Remember to work within the context of that aggregate root though.
Invoice might be detailed as outlined in our previous example. Statement.Invoice might just be a summary of that information.
Model clarity is significantly more valuable than code reuse in almost all cases. Interface Segregation Principle is very important here.
The context that you are working in is more important than the overriding concept
When we take a business action it’s very common for many things to need to happen. Encapsulate those into methods on the Aggregate root
Law of Demeter. You can pick your nose and you can pick your friends. You can’t pick your friend’s nose. You can, however, look at your friend’s nose.
Service and Data Access layers know about Domain Model, but not the other way around
The only items that should be passed to the data access layer are the aggregate root objects.
The pattern of work that results from only doing data access with the aggregate root.
Working with aggregate roots only can mean you are going to load data into objects in the tree that you may not use.
Without an ORM the aggregate root DAL approach becomes very painful
Leverage the functionality of the ORM. Load data only when you need it.
A domain model that is only properties. We want our models to be rich, or Rubenesque; properties, methods and events will exist.
If domain objects only use default constructors something is missing. Usually when you create a “new” instance of an object there will be minimum requirements for that object to be valid.
1 repository to 1 aggregate root. All data access happens via aggregate roots.
Domain model maps to the business functionality not to how it displays
Auto-mapping from domain to UI is a great thing. When pulling data from the UI we want to apply it to the domain model via methods exposed on the aggregate root. Auto-mapping can’t do this. It can only do property to property
Publically exposing property setters can indicate that the model is anemic.
Changing your thought pattern to having overlapping aggregates and multiple classes representing the same data tables is difficult.
Sometimes it seems like silly extra work to keep a UI model and a domain model separate. Sometimes this can indicate that all you’re building is forms-over-data with no business richness.
DDD is great for the C, U and D parts of CRUD but it isn’t a great solution for the R portion. Separating how you read data for display on the screen makes the retrieval of the data much easier. Look into CQRS which separates these two concepts nicely.
Knowing when there isn’t enough complexity to warrant DDD is just as important as knowing how to do DDD
