When Should Domain Objects Contain Methods in a Rich DDD Model?

Domain‑Driven Design promotes a rich domain model, but developers often disagree on how "rich" an aggregate should be.

The author describes two anti‑patterns: (1) treating the aggregate root as a pure data container and moving all business logic to services, and (2) overloading the aggregate with complex creation flows and even RPC calls.

To resolve this, the team adopted a simple rule: "who has the data, provides the method." A method belongs in an aggregate only if it requires data that is entirely contained within that aggregate.

For example, instead of a service repeatedly comparing order.getStatus() to the string "pending", the Order entity should expose isPending(), which uses only this.status and returns the answer without database queries or external calls.

Similarly, in a marketing‑activity system, methods like isStarted(), isEnded() and isOngoing() belong on the Activity entity because they depend only on the entity's startTime, endTime, and the current time, not on external services.

The author emphasizes that method complexity is irrelevant to placement; even logic involving dozens of fields and many conditional branches stays inside the entity as long as it does not need external data.

The decisive boundary is the need for interaction with the outside world. An aggregate is a closed computation unit that can perform all calculations in memory given sufficient input data, while any requirement to fetch external data or coordinate multiple systems should be handled by the Service layer.

Thus, the criterion for a rich model is data self‑sufficiency, not the intricacy of the method: if the data lives on the aggregate, the method belongs there; otherwise, it belongs elsewhere.