Download - Domain Driven Design Experience Report
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
Ian Cooper www.codebetter.com
Key Requirements
Manage the Underwriting lifecycle
High-Volume, Low Margins
Configure new products, rules and workflows
Ian Cooper www.codebetter.com
Splitting out Domains
Domains often relate to business activities
Within a team still look for activities
Ian Cooper www.codebetter.com
Finding our Generic Domains
Document Generation
Rules Engine
Rating Engine
General Ledger
Feeds
Human Workflow
Ian Cooper www.codebetter.com
Finding Our Supporting Domains
Document Management System
Broker Database
Ian Cooper www.codebetter.com
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.
Ian Cooper www.codebetter.com
Segregate the Core
Do not stop distilling at component boundary
An application has generic and sub-domains
The core is smaller than you think!
Ian Cooper www.codebetter.com
Cohesive Mechanisms
Ian Cooper www.codebetter.com
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
Ian Cooper www.codebetter.com
‘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
Ian Cooper www.codebetter.com
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
Ian Cooper www.codebetter.com
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
Ian Cooper www.codebetter.com
Exploring the language of the domain
Ian Cooper www.codebetter.com
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
Ian Cooper www.codebetter.com
Exploring the language of the domain
Ian Cooper www.codebetter.com
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
Ian Cooper www.codebetter.com
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
Ian Cooper www.codebetter.com
Context Mapping
Ian Cooper www.codebetter.com
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
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)
Ian Cooper www.codebetter.com
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)
Ian Cooper www.codebetter.com
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.
Ian Cooper www.codebetter.com
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
Ian Cooper www.codebetter.com
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
Ian Cooper www.codebetter.com
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
Ian Cooper www.codebetter.com