Tohuwabohu excorcism

This is an old revision of the document!

Domain Driven Design

Bounded Context
Ubiquitous language
Value objects	Stores some logic from the domain. Like validation of @ in a ValueObject “Email”
Entity	Will be persisted as row in a database table. Its like the JPA Entity.
Modules (packages or namespaces)	Way to implement conceptual contours. Helps to separate areas of domain.
Aggregate Root	https://martinfowler.com/bliki/DDD_Aggregate.html. a cluster of domain objects that can be treated as a single unit. An example may be an order and its line-items. PlayList. Clinic Visits.
A repository	is an abstraction over the persistence store
services	In Services we implement cross cutting functionality.
Domain services	Implement communication between different entities, which is not directly associated with one concrete entity. E.g. Transaction from one account to another. Domain service can both call or be called by a domain entity
Application services	Application services use domain services, but not vice versa. Application layer service handle cross cutting concerns: security, packaging requests, receiving requests.

DDD is mainly about the Domain Layer. THe whole logic should be implemented in this layer. But DDD expects the other layers to exist.

Presentaion Layer	UI. The presentation layer generally deals with serializable representations of a domain object
Application Layer	Holds the security logic, request packaging, unpackaging.
Domain Layer	The Domain logic.
Infrastructure Layer	The persistence logic.

Here is the scope hierarchy within DDD.

value < entity < aggregate < module < bounded context

Entities - are objects with own identifier.
Value Objects - are identified by their values. Like Address might be one. And re-created rather than copied.

Aggregate - The purpose of an aggregate is to model transactional invariants. Things in the real world have complex webs of relationships.