Download to read offline
Uploaded byKhrystyna Makar
Domain Driven Design
This document provides an overview of key concepts in Domain-Driven Design (DDD) including the model, ubiquitous language, entities, value objects, services, aggregates, factories, and repositories. It defines each concept, provides examples, and references additional resources for learning more about DDD.
Domain Driven Design
- 1. www.softserve.ua Domain Driven Design Copyright ©2015 SoftServe, Inc.
- 2. www.softserve.ua Agenda 1.Model 2.Ubiquitous language 3.Entity 4.Value Object 5.Service 1.DomainService 2.Application Service 6.Aggregates 7.Factories 8.Repositories 9.Resources
- 3. www.softserve.ua Model is astart for application • The model is the backbone of a language used by all team members. • The model dictates the form of the design of the heart of the software. • The model is distilled knowledge.
- 4. www.softserve.ua The Ubiquitous Language •A language structured around the domain model and used by all team members to connect all the activities of the team with the software. • Translation plus risk of misunderstanding is too high of a cost • Changes to the language, should cause a refactoring to code • Nouns == Classes • Verbs == methods, services, etc.
- 5. www.softserve.ua Entity • An objectdefined primarily by its identity • Is mutable, only entity's identifier is immutable • Must validate itself and its children to enforce invariants • Overriding equals() and hashcode() is required • Entity values (other than the identity) can change over time, but are only changed by the Entity's interface • Can use Self-Encapsulation, create a validator class, or have a validate method • Must encapsulate business logic.
- 6.
- 7.
- 8. www.softserve.ua Value Object • Aredefined by their attributes instead of their identity • Should be immutable, so it only changes by replacement • Don’t give it any identity. • Are instantiated to represent elements of the design that we care about only for what they are, not who they are • Should use Self-Encapsulation. Have private setters that validate properties, then call the setters from the constructor to initialize.
- 9.
- 10.
- 11. www.softserve.ua An attribute shouldbe conceptually whole
- 12. www.softserve.ua Service • A SERVICEis an operation offered as an interface that stands alone in the model, without encapsulating state as ENTITIES and VALUE OBJECTS do. • Only add business logic here if it doesn't "fit" inside an Entity or Value Object. • Don't mix CQRS methods. • Domain services encapsulate domain concepts that just are not naturally modeled as things. • Application services constitute the application, or service, layer.
- 13.
- 14.
- 15. www.softserve.ua Aggregates • An AGGREGATEis a cluster of associated objects that we treat as a unit . • The root is a single specific ENTITY contained in the AGGREGATE. • The root ENTITY has global identity, and is ultimately responsible for checking invariants. • Nothing outside the AGGREGATE boundary can hold a reference to anything inside, except to the root ENTITY. • Only AGGREGATE roots can be obtained directly with database queries. All other objects must be found by traversal of associations. • When a change to any object within the AGGREGATE boundary is committed, all invariants of the whole AGGREGATE must be satisfied.
- 16.
- 17. www.softserve.ua Factories • Manages thecreation of complex objects in the domain • Requirements for a FACTORY are: – Each creation method is atomic and enforces all invariants of the created object or AGGREGATE. – A FACTORY should only be able to produce an object in a consistent state. • For an ENTITY, this means the creation of the entire AGGREGATE, with all the invariants satisfied, but probably with optional elements still to be added. • For an immutable VALUE OBJECT, this means that all attributes are initialized to their correct final state.
- 18.
- 19. www.softserve.ua Repositories • For eachclass/aggregate root setup a Repository for in-memory access • Provide add/remove methods for managing persistent objects • Manages the middle and end of an objects lifecycle • Should never contain business logic • Always produce fully initialized Entities, never partial. Except in rare cases for performance
- 20.
- 21. www.softserve.ua Resources Domain-Driven Design. EricEvans http://www-public.int-evry.fr/~gibson/Teaching/CSC7322/ReadingMaterial/Evans03.pdf Domain Driven Design Quickly http://www.infoq.com/minibooks/domain-driven-design-quickly DDD Comunity http://domaindrivendesign.org/ What is the difference between Entities and Value Objects? http://culttt.com/2014/04/30/difference-entities-value-objects/ DDD sample http://dddsample.sourceforge.net/ Service Layer. Martin Fowler http://martinfowler.com/eaaCatalog/serviceLayer.html