Domain-Driven Design

Domain-Driven Design

Andriy Budayhttp://andriybuday.com/

Yeah… I’ve read them all…

Where is a car on the left or on the right?

Introduction

We cannot just type the code… we need to have a vision…

What is DDD? Ubiquitous Language New architecture Building blocks of Domain-Driven Design Refactoring Toward Deeper Insight Preserving Model Integrity Infrastructure Patterns and practices with Domain-Driven Design

Outline

DDD is an approach to the design Model is the heart of the DDD

Model and the design shape each other Model is language for team members Model is knowledge

Your Focus is on heart

Domain-Driven Design

Need for some common language Language and model How does it look?

Speech (a common) Diagrams Writing (not long documents) UML (not cumbersome)

UBIQUITOUS LANGUAGE

Voyage Cargo

Voyage Cargo

Voyage Cargo

How will you build your architecture with DDD?

New Architecture

Advantages Disadvantages Bottom line

The Smart UI “Anti-Pattern”

Layered architecture

Building blocks of DDD

Entities

Almost like a Entity but without Identity

Value Objects

Address for Patient could be Value Object…because it doesn’t play huge role in his treating

Address in postal service is Entity…because it is critical to know where to deliver

correspondence

Value Object or Entity? Who is asking?

Three characteristics for a good Service: Operation not natural to an Entity or Value Object Defined interface Operation is stateless

Service

When you place some classes together in a Module, you are telling the next developer who looks at your design to think about them together.

Modules

Aggregate

Car is Aggregate to Tire Root Entity

Responsibility of Factory Requirements to Factory

Atomicity Abstracted to the type desired

Reconstituting Stored Objects

Factory

Querying a Repository Implementation of Repository

Abstract the type. Take advantage of the decoupling from the client. Leave transaction control to the client.

Repositories

Factories and Repositories

Continuous Refactoring Refactoring toward deeper insight is not the same kind as

technical refactoring. We could not have patterns of doing it.

Bring Key Concepts into Light There are times when lots of small changes add very little

value to the design, and here are times when few changes make a lot of difference.

Refactoring Toward Deeper Insight

Constraint Process Specification

Bring Concepts Into Light

Customer customer = customerRepository.findCustomer(customerIdentiy);

//…

Specification customerEligibleForRefund = new Specification(

        new CustomerPaidHisDebtsInThePast(),

        new CustomerHasNoOutstandingBalances() );

if (customerEligibleForRefund.isSatisfiedBy(customer))

{

        refundService.issueRefundTo(customer);

}

Preserving Model Integrity

Each model has a context When we deal with legacy we create new model

and new context A model should be small enough to be assigned to

one team Continuous Integration Context Map (document)

Bounded Context

Shared Kernel Customer-Supplier Conformist Anticorruption Layer Separate Ways Open Host Service Distillation

Interaction between different contexts

Persistence Ignorance

Prepare your Infrastructure

How do we classify ORMs? How do they resolve issues? Requirements to them Identity Map Unit Of Work Lazy load

Infrastructure: ORM

NHibernate provides all the features required to quickly build an advanced persistence layer in code.

You work only with objects, so you understand Business model.

NHibernate

Agile techniques are good for DDD

…such as TDD…

New way of proecting

…such as SOA, AOP, IoC…

Patterns and practices with Domain-Driven Design

My article on DDD: http://andriybuday.blogspot.com/2010/01/ddd.html

DDD community: http://domaindrivendesign.org/

DDD books: Domain-Driven Design: Tackling Complexity in the Heart of

Software

Applying Domain-Driven Design and Patterns Domain-Driven Design Quickly

Links

Read blog! Follow me! Visit Lviv UG!

@andriybuday

http://andriybuday.com/

http://dotnetug-lviv.blogspot.com/

andriybuday@gmail.com