CODEWITHSUNDEEP
domain-driven-design
Sebastian K
Sebastian K

Reputation: 6383

Should entity contain only behavior that modifies the state?

I had a discussion recently with a co-worker, where he insisted that in Domain-Driven Design entities should not have a behavior that does not modify its state. In my experience to date, I never heard about this limitation. Is it a valid DDD rule?

To give some context (simplified scenario) - in our domain we have Computer entity, on which you can start Processes, our integration layer will actually delegate it to a remote physical Computer and start a process there.

So, should StartProcess be a behaviour of a Computer entity? Or should it be included in Domain Service as it does not affect the state of the Computer entity directly? (it modifies the state indirectly as once the process is over, and data is synchronized back to our system).

To me Entity is a natural place for it, as it follows the ubiquitous language, but I am wondering if someone has good reasons against (or other reasons for).

Upvotes: 2

Views: 254

Answers (1)

eulerfx
eulerfx

Reputation: 37719

IMO an entity behavior does not need to modify state, but at the very least should emit an event. In this case, the event would be something like ProcessStarted. CQRS/event-sourcing views aggregates essentially as command handlers - they handle commands and emit events. State is made explicit when required for behavior or when denormalized for query purposes.

Upvotes: 2

Related Questions