Main concepts of DDD

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.Domain Service
2.Application Service
6.Aggregates
7.Factories
8.Repositories
9.Resources

3. www.softserve.ua
Model is a start 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 object defined 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. www.softserve.ua
Example

7. www.softserve.ua
Example

8. www.softserve.ua
Value Object
• Are defined 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. www.softserve.ua
Examples
2. Driving route1. Pencil

10. www.softserve.ua
Examples
voyage identity
voyage required property

11. www.softserve.ua
An attribute should be
conceptually whole

12. www.softserve.ua
Service
• A SERVICE is 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. www.softserve.ua
Example. Domain Service

14. www.softserve.ua
Example. Application Service

15. www.softserve.ua
Aggregates
• An AGGREGATE is 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. www.softserve.ua
Example

17. www.softserve.ua
Factories
• Manages the creation 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. www.softserve.ua
Example

19. www.softserve.ua
Repositories
• For each class/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. www.softserve.ua
Example

21. www.softserve.ua
Resources
Domain-Driven Design. Eric Evans
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