DomainDrivenDesign
the essence of DDD is profoundly simple: capture the domain model in domain terms, embed the model in the code, and protect it from corruption.
- Understand the business, business logic independently of the tech used
- Capture the domain model, in domain terms, through interactions with domain experts.
- Embed the domain terminology in the code.
- Protect the domain knowledge from corruption by other domains, technical subdomains, etc.
EvansClassification
https://martinfowler.com/bliki/EvansClassification.html
Entity: Objects that have a distinct identity that runs through time and different representations. You also hear these called "reference objects".
- Note: not the same as entities in ORM's
Value Object: Objects that matter only as the combination of their attributes. Two value objects with the same values for all their attributes are considered equal. I also describe value objects in P of EAA.
- Note: Only constructor and getters. Immutable !
Service: A standalone operation within the context of your domain. A Service Object collects one or more services into an object. Typically you will have only one instance of each service object type within your execution context.
- Note: business logic and business rules
One clear division between entities and values is that values override the equality method (and thus hash) while entities usually don't.
One important rule to follow is that value objects should be immutable. To change a value (such as my height) you don't change the height object, you replace it with a new one.
Service objects are often implemented by using global variables, class fields (monostates in Robert Martin's terminology) or singletons.