Applying Domain-Driven Design to craft Rich Domain Models

Powerpoint Templates

Applying Domain-Driven Design to craft

Rich Domain Models

Alexander van Trijffel6-2-2014

Agenda

• What is a domain model?• Hexagonal Architecture• Ubiquitous Language• When to use Domain-Driven Design?• Adding behavior to the domain model• Value objects

The domain modelRepresents business objects, operations and events that reflect the business processes and are meaningful to the business representatives.

Business rules

‘An Asset Value Correlation multiplier must be applied for exposures with to Financial Sector Entities with assets of at least $100 bn’

‘In case no Country of Risk is registered in UCI, the C-rating should be ‘No Rating’

Behavior

‘When an assessment is activated, a Global Facility Id is requested from UFI and assigned to the assessment’

‘When an employee states that he has outside interests, the system accepts stock positions under certain conditions’

Invariants

‘A confirmed assessment has been calculated’

‘An activated assessment has a GFID’

‘A counterparty has an Wwid’

‘A protection covers at least one debtor’

Hexagonal Architecture

The blue book

DDD on strategic level

Second Page :

"Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum."

Do we speak the same language?

Ubiquitous language

DDD on tactical level

Aren’t we doing DDD already?

We have entities…

And our managers/services/* know all about the logic…

* enter your favorite name for the application service role here

We have a separate business layer

Hello Anemic Domain Model!

System type Domain logic Complexity

Use cases DDD pays off?

CRUD, Master data, Lookup

Low Any No

Simple, Small, Utility Low < 30 NoDepartmental, Narrow scoped

Medium between 30 and 40

Could be

Innovative Unknown ? YesEnterprise System,Core system

High > 40 Yes

When to invest in developing an ubiquitous language and implementing a Rich Domain Model?

Object Oriented Software:

• Encapsulates data and operations in objects that interact with each other via the object’s interface.

• Applies information hiding; Internal representation of objects is hidden to clients

Object oriented means that an object manages its state and guarantees that it is in a legal state at any time.

By applying Object Orientation to the domain model, the model:

• can ensure that its state is correct at all times

• can hide complexity behind its public interface

Anemic Domain Model example

Applying business rules

What if we have business rules on the client Status as well?

Things get messy quickly…

Empowering the domain: Encapsulating data and operations in domain objects

Encapsulating domain logic in value objects

Value object – immutable and comparable by its attributes

Entity Value object

Unique Can have many occurences

Distinguished by identity Distinguished by attributes

Can be changed Immutable

Model object as Entity or Value Object?

Money: Entity or value object?

Value objects examples

PercentageProbability of DefaultLoss Given DefaultWorld Wide IdGlobal Facility IdRating

AddressCountryDecisionPeriodStatus

Other tactical DDD patterns to explore:

• Domain Services

• Domain Events

• Aggregates

Summary

Domain-Driven Design is a methodology that provides patterns for designing rich domains that encapsulate data and behavior.

The investment in developing an ubiquitous language and implementing a rich domain model pays off for medium to large applications that implement business rules and processes.

By applying Object Oriented principles to the domain, business logic is easier to test, understand and extend.

Thanks for your attention!

Resources

• Domain-Driven Design: Tackling Complexity in the Heart of Software (Eric Evans)

• Implementing Domain-Driven DesignVaughn Vernon

• DDD/CQRS mailing list https://groups.google.com/forum/#!forum/dddcqrs

Backup slides

Empowering the domain: Constructing objects

What does it mean to be a client in our domain?

• Does a client without a wwid make sense?• Does our domain even support clients without ratings?

Communicate the intent of a client through the API:

Empowering the domain: Encapsulated collections

Can the domain object guarantee that the Ratings collection is valid at all times?

Does it make sense to clear all ratings? Duplicate a rating?

Empowering the domain: Encapsulated collections

We provide an explicit API to manipulate the collection.