domain driven design experience report

DOMAIN DRIVEN DESIGN: EXPERIENCE REPORT

Putting the Model at the heart of development

Who are you?

Software Developer for 18 years Worked mainly for ISVs Reuters, SunGard, Misys

Worked for a couple of MIS departments DTI, Beazley

Microsoft MVP for C# Interested in OO design

Interested in Agile methodologies and practices

No smart guys Just the guys in this room

Ian Cooper www.codebetter.com

Revelations and Misunderstandings

Distillation

Ubiquitous Language

Maintaining Model Integrity

A Model Expressed in Software


What was wanted?


Distillation Revelations

Beazley’s Goal

A new underwriting platform


Key Requirements

Manage the Underwriting lifecycle

High-Volume, Low Margins

Configure new products, rules and workflows


Build or Buy

Customer focused on build vs. buy



Distillation

Splitting out Domains

Domains often relate to business activities

Within a team still look for activities


Finding our Generic Domains

Document Generation

Rules Engine

Rating Engine

General Ledger

Feeds

Human Workflow


Finding Our Supporting Domains

Document Management System

Broker Database


Core Domain Vision Statement

The Domain Model will represent the life cycle of a risk such that the key decision points required to process risk may be audit trailed.

The model should also represent the notion of an account with whom Beazley do business, to allow key events on the account to be easily identified.

The view of accounts and their associated risks must be sufficiently detailed to support underwriting decisions.

The model should support the addition of new products by configuration instead of changes to the model.


What was wanted?


Requirements Misunderstandings

Segregate the Core

Do not stop distilling at component boundary

An application has generic and sub-domains

The core is smaller than you think!


Cohesive Mechanisms


Cohesive mechanisms an important way to ease the burden of using the model

It get hard to see the model if you have too much CS noise

Some cohesive domains seem to emerge from the domain as complexity increases

Some we know about from discussing the model

State and Rules Engines

A risk proceeds through states in response to events

We execute rules at key life-cycle points


‘What’ from ‘How’

Want to define rules that run at a transition, not how rules are run

Want rules to be point of extension that users can use to add rules too


Specifications and Rules Engines

A specification is a predicate, an abstraction for a rule

A rules engine can be used to provide a DSL to allow user extension

Confusion from two mechanisms


Hiding Complexity

User Defined Rules are implemented by the rules engine

But we abstract them as part of the same rules engine at state transition that executes all specifications

So we hide the complexity behind a cohesive mechanism


Exploring the language of the domain


Ubiquitous Language - Revelations

The Ubiquitous Language

Some concepts hidden without this

No real notion of Account for example

Ubiquitous language reduces re-work

Sharing model flushes out concepts


Exploring the language of the domain


Ubiquitous Language - Misunderstandings

Beware Context Shifts

Sometimes it sounds like people are talking about the same thing, because they use the same terms

Beware you may be in different contexts without realizing it

Recognize that the ubiquitous language describes a model


Confusion

Sometimes its not a context shift

People can be inexact in terminology

Try two ‘domain experts’ who don’t work together

Remember the model may not be real



Maintaining Model Integrity

Context Mapping


Identified multiple Bounded Contexts (BC)

Our BCs came from different teams

All had different views of shared concepts

In some cases multiple BCs with one development team, in other cases across teams

A First Vision


Emerging Reality


Where we are heading



A Model Expressed In Software


Modeling - Revelations

Aggregates have great power

Help prevent anemic domain models

They simplify

Reduces complexity of the graph

Are forces for cohesion

Keep infrastructure from domain

(Aggregates look to play nice with NoSQL)


Entities and Value Types

A lot of objects are not entities

Comparison by state more common than by Id

Allows us to use immutability

(Still hard to get developers to see value types)

(Still too many primitives not decently clothed in value types)


Events are a natural part of the model

‘Risk’ lifecycle is a series of events

State is sum of all events that have happened

A lot of MI is ‘what happened when’

What events occurred on the risk

Events may be ‘out-of-sequence’

Traditionally a thorny problem for MTAs

Event sourcing is a powerful tool for this

Also solves problem of ‘view on date’ etc.



Modeling - Misunderstandings

References between aggregates

Holding a reference to an aggregate root encourages use of one aggregate within methods on another.

Also leads to one root composing other roots

Use Domain Events to Update across aggregates


Repositories of Queries

Queries crust over Repositories like barnacles on the hull of a ship

Breaks the ‘collection’ paradigm

Introduces Infrastructure concerns like lazy loading

At best buries domain logic, at worst is not a domain concern

Query Object can help…

But separating commands and queries better



One thing to remember

The Key to Success

“One way or another, creating distinctive software comes back to a stable team accumulating specialized knowledge and crunching it into a rich model. No shortcuts. No magic bullets.”

Domain Driven Design – Evans


Q&A


domain driven design experience report

Technology

core domain model

roomian cooper

workflowsian cooper

softwareian cooper

buyian cooper

new fields

distillation process

processspecialist rules