For full text search please use the '?' prefix. e.g. ? Onboarding

Domain Driven Development

Concept

https://www.youtube.com/watch?v=UEtmOW8uZZY

Value

  • 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.
  • One important rule to follow is that value objects should be immutable

Entity

  • Entity: Objects that have a distinct identity that runs through time and different representations. You also hear these called "reference objects".

Aggregrate

  • Aggregate is a pattern in Domain-Driven Design. A DDD aggregate is a cluster of domain objects that can be treated as a single unit. An example may be an order and its line-items, these will be separate objects, but it's useful to treat the order (together with its line items) as a single aggregate.

An aggregate will have one of its component objects be the aggregate root. Any references from outside the aggregate should only go to the aggregate root. The root can thus ensure the integrity of the aggregate as a whole.

Aggregates are the basic element of transfer of data storage - you request to load or save whole aggregates. Transactions should not cross aggregate boundaries.

DDD Aggregates are sometimes confused with collection classes (lists, maps, etc). DDD aggregates are domain concepts (order, clinic visit, playlist), while collections are generic. An aggregate will often contain mutliple collections, together with simple fields. The term "aggregate" is a common one, and is used in various different contexts (e.g. UML), in which case it does not refer to the same concept as a DDD aggregate.

Domain Event ???

OTHER

Service

  • 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.
  • Service objects are often implemented by using global variables, class fields (monostates in Robert Martin's terminology) or singletons. Certainly they are usually singular, in that you only have one of them, but how you do that is more varied. Usually the singularity is within a processing context - so one per thread in a multi-threaded environment. In any case you should ensure that your implementation mechanism is hidden from other domain objects so you can easily change it. Eric states in his book that services should be stateless, although we've talked about that and he no longer thinks that is necessary - although it's nice if you can do it.

Tools

Refs

Amichai