fasadplaza.blogg.se - Domain driven design ubiquitous language

Prefer to put the behavior on value objects rather than on entities because value objects are immutable and do not have side effects (like changing their state or changing the state of any entity).You can combine other value types that usually go together into a new value object type, like address (city, street, country, postal code) or.Can be used to measure or describe things (name, description, amount, height, date, time, range, address, etc.).Are only identified by their values, not by their ids (for example money is a value object as long as we are not tracking individual banknotes, if we need to track individual banknotes then it should be a banknote entity).If a business transaction needs a reference to other entities in relation, aggregates should be used instead (aggregates can hold a reference to other aggregate roots, which are entity classes by definition).Entity relations should not hold a reference to another entity class, it can only keep the id of another entity.Entity relations should not reflect the complete set of DB foreign key relationships, should be bare down to the minimum for performing the behavior inside the bounded context.Entities should not have bidirectional relations (depending on the bounded context, either an egg can have a chicken or a chicken can have eggs, but not both).

Entity class should not have public property setters, setting a property should be a behavior method.

Behavior in an entity mostly orchestrates value objects for a use case.

Have entity semantics (equality and GetHashCode() defined by class name + id).

Have an id (preferably a GUID rather than a DB generated int because business transactions do not rely on persistence, can be persisted after other operations carried out in model's behavior).

Live longer than the application, should endure restarts, and are persisted and read from data sources (DB, file system, network, etc.).

Infrastructure layer (persistence, file system, network, mail, logging, etc.).

UI/Application layer (UI and application service facade with messaging, JSON, XML capabilities, session, etc.).

Core domain layer is surrounded by the UI/Application layer and Infrastructure layer.

Core domain layer (domain services, entities, value objects, aggregates and domain events).

Domain services sit in the core domain layer along with entities, value objects, aggregates and domain events, and expose domain models in their interfaces.

Domain services have very little behavior and only which does not fit cohesively in any domain model.

Domain services should not hold state (application services are not domain services, they are on the outer layer close to the UI layer, and can hold application/task state).

Thin domain service working on rich domain models:

Model methods can also delegate the task to domain services by raising domain eventsģ.

Due to single responsibility principle (a class or method should have only one reason to change), non-cohesive behavior should be delegated to other classes (or even handled inside domain services) when necessary.

Models (entities, value objects, aggregates) with rich behavior are preferred over anemic domain models (entities without behavior, which only keep data and represent the DB tables).Bounded context helps in single responsibility for domain models.Entities with the same name in a different context can have different behavior and data.Language and terms agreed upon by both business users and developers, within a bounded context.Thin domain service working on rich domain models