What constitutes a rich domain model in a POJO/POCO?

class-design, modeling, poco, pojo

Solution

"Rich" as used here implies "rich behavior" (as opposed to state).

There is technical behavior and domain behavior. Accessors and mutators are technical; they lack the "why" which defines business interest.

Domain objects represent the "why" and encapsulate the "how". Actually, all objects do that; domain objects do it specifically for business value.

Let's say you, as an employee domain object, have to request a day off of work. You have 2 options:

- Tell your manager and he marks the schedule.

- Ask your manager for the schedule and mark it.

Model 1 is rich. The "why" (vacation time) encapsulates the "how" (marking the schedule).

Model 2 relegates the manager to a simple property bag and leaks the scheduling abstraction.

Problem

Original source