domain driven design

21
w w w.softserve.ua Domain Driven Design Copyright © 2015 SoftServe, Inc.

Upload: khrystyna-makar

Post on 15-Apr-2017

169 views

Category:

Software


0 download

TRANSCRIPT

Page 1: Domain Driven Design

www.softserve.ua

Domain Driven Design

Copyright © 2015 SoftServe, Inc.

Page 2: Domain Driven Design

www.softserve.ua

Agenda1. Model2. Ubiquitous language3. Entity4. Value Object5. Service

1. Domain Service2. Application Service

6. Aggregates7. Factories8. Repositories9. Resources

Page 3: Domain Driven Design

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.

Page 4: Domain Driven Design

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.

Page 5: Domain Driven Design

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.

Page 6: Domain Driven Design

www.softserve.ua

Example

Page 8: Domain Driven Design

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.

Page 9: Domain Driven Design

www.softserve.ua

Examples2. Driving route1. Pencil

Page 10: Domain Driven Design

www.softserve.ua

Examples

voyage identity

voyage required property

Page 11: Domain Driven Design

www.softserve.ua

An attribute should be conceptually whole

Page 12: Domain Driven Design

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.

Page 15: Domain Driven Design

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.

Page 17: Domain Driven Design

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.

Page 19: Domain Driven Design

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

Page 21: Domain Driven Design

www.softserve.ua

ResourcesDomain-Driven Design. Eric Evans

http://www-public.int-evry.fr/~gibson/Teaching/CSC7322/ReadingMaterial/Evans03.pdf

Domain Driven Design Quicklyhttp://www.infoq.com/minibooks/domain-driven-design-quickly

DDD Comunityhttp://domaindrivendesign.org/

What is the difference between Entities and Value Objects?http://culttt.com/2014/04/30/difference-entities-value-objects/

DDD samplehttp://dddsample.sourceforge.net/

Service Layer. Martin Fowlerhttp://martinfowler.com/eaaCatalog/serviceLayer.html