a) As far as I understand it, in most cases Domain Model DM doesn’t contain code for creating/deleting domain entities, but instead it is the job of layers ( ie service layer or UI layer ) on top of DM to create/delete domain entities?
b) Domain entities are modelled after real world entities. Assuming particular real world entity being abstracted does have the functionality of creating/deleting other real world entities, then I assume the domain entity abstracting this real world entity could also contain logic for creating/deleting other entities?
class RobotDestroyerCreator
{
...
void heavyThinking()
{
...
if(...)
unitOfWork.registerDelete(robot);
...
if(...)
{
var robotNew = new Robot(...);
unitOfWork.registerNew(robotNew);
{
...
}
}
Thank you
1
a) DDD doesn’t specify that domain objects shouldn’t create domain objects. A domain object can very well create another domain object. An aggregate is responsible for enforcing a consistency boundary around a cluster of entities and value objects. As such, it could very well have behaviors which create entities. For example, the stereotypical sales order aggregate can create instances of order line entities (or value objects, depending on implementation). The important thing is to ensure that domain and entities are created or deleted in well defined places. Take a look at this article which evaluates aggregate creation in a domain model.
b) The mapping between a real world entity and the corresponding abstraction in code is never isomorphic. Abstractions in code are bound by technical constraints that cannot be overlooked. Code isn’t meant to be an isomorphism of reality, it is only meant exhibit functional characteristics which fulfill sets of requirements. The similarity between reality and code is an aspect that we strive for to streamline the development process. In other words, if a real world entity creates something, it doesn’t immediately translate to the corresponding abstraction in code, though it may – there is no hard rule.
0
a) A domain entity may occasionally create or delete other entities. However, it will typically do so by adding to or removing from one of its internal collections if the entity to add/remove is one of its child entities from the same aggregate (in which case your ORM will most likely be able to track changes to the collection and persist them automatically), or by calling a Repository if the entity to create/delete is an Aggregate root. It hardly seems appropriate for a domain object to know about the unit of work and the current state of objects in the user transaction – this is a job for the Application layer.
You should also be careful not to place too complex object creation logic in an entity – assembling complex objects from various parts rather belongs to a Factory.
b) There’s elegance indeed in code that mirrors how real-world concepts play out – it’s smooth, very readable and easily understandable. Besides, it’s true that DDD encourages us to name our code constructs after real world concepts of the domain.
However, it also tells us that the model and ubiquitous language should be the result of a domain expert/developer collaboration. It’s not like you could just pour the domain on a keyboard and watch your domain objects write themselves magically. Abstraction is not just translation from real to code with nouns becoming classes and verbs becoming methods, it’s more than that. Some kind of transformation process is needed where the business needs and technical needs meet. During that process, some objects or relationships between objects that existed in the real world will be preserved, others won’t – because they are not conveniently representable in code, or because they defeat good software practices such as separation of concerns, cohesion, low coupling, etc. New domain objects will also appear, maybe ones that don’t have a materialization in the real world domain.
So the computerized version of a real-world domain problem or activity is a different animal, there’s no rule allowing you to tell in advance if there’s going to be a class for this business actor or a method for that business concept. All you can be sure about is that their names will probably be found somewhere in the code.