domain-driven design (artur trosin product stream)
TRANSCRIPT
Domain-Driven Design (DDD)effective collaboration
Artur Trosin
Presentation for: Lviv IT Arena, 2015
Before we start
Why DDD nowadays?
• Automation of various business domains
• High competition for a market place
• Growing business complexity
• Many roles and teams involved in a business process
• Higher standards & new features
• Continuous Delivery:
Time to Market
Complexity becomes inevitable
Domain – a sphere of knowledge or
activity
Domain Model - is a rigorously
organized and selective abstraction
of the (Business) Domain
knowledge.
Ubiquitous Language - language
structured around the domain
model and used by all team
members to connect all the
activities of the team with the
software.
Main DDD premises
1. Primary focus should be on the domain
and domain logic
2. Complex domain designs should be
based on a model
Domain Model and modelling
• Modelling and design are the quickest way
to actual goal
Eric Evans
Modelling the Domain
Atom Models Evolution
Why models?
Even Music has a Model
Keep in mind
• Multiple Models
• Do not stop just on one even it meets the
requirements
• Free form sketches or UML
• Prefer diagram simplicity over UML syntax
correctness
• Do NOT FIT TOO MUCH
Bounded context
Source: http://martinfowler.com/bliki/BoundedContext.html
Ubiquitous Language
Ubiquitous Language
Technical aspects
of design
Technical terms
Technical design
patterns
S.O.L.I.D design
principles
Domain Model
Terms
DDD Patterns
Bounded Contexts
Business terms
developers don’t
understand
Business terms
everyone uses that
don’t appear in design
Candidates to fold into model
Ubiquitous, but Not Universal
• One Ubiquitous Language per Bounded
Context
• Speak the Ubiquitous Language of the
isolated domain model within the explicit
Bounded Context.
• If you try to apply a single Ubiquitous
Language to an entire enterprise system
you will fail.
Effective Collaboration & SDLC
Iteration 0 Iteration 1 Iteration 2 Iteration 3
Domain Experts
And Business Analysts
UML
Developers
Iteration N?
Model evolves, bug
fixes, found issues
with analysis model,...
Initially the
code model
matches
analysis model
No Feedback loop,
descriptive domain lost,
Code model no longer
reflects analysis model
Source: Patterns, Principles, and Practices of Domain-Driven Design, By Scott Millett, Nick
Tune
Requirements Specification in
DDD• Start first with benefits and goals
• Working backwards
• Exercise the ubiquitous language in
Stories\Use-Cases
• Look for key business examples in
Stories\Use-Cases to source as core
scenarios for modeling
BA role in DDD
• Flash out initial ideas of the product from business experts
• Actively participate in domain modelling process
• Continuous focus on UL and its correct usage within the team
• To facilitate discussion between developers and business experts
• Do not remove direct communication between developers and domain experts
How models are created
• walk with domain expert through core scenarios
• Creative collaboration with a business experts
• Refinement of ubiquitous language and therefore the model
• sketch (informal) UML diagrams on whiteboard explaining how the model supports them
• Sequence diagrams can be very helpful for understanding the application flow from the UI, API, or context boundary down to the domain model
• Challenge your assumptions
Architecture• Architecture is largely orthogonal, but
supportive, for DDD
• 4+1 views architecture for SAD are still relevant
• Focus on core domain business capabilities and context map
• Facilitate collaboration when multiple teams are involved for wider system view
• Anticipate and provide more architectural views where and when it is needed
Classic Layering
UI
Business Entities
Data Access
DB
Record Sets or
Data Sets or
POCO or
POJO
No Clear Business layer isolation
DDD recommended-Layering
Presentation
Application
Domain
Infrastructure
During development:
Analysis Model and Code Model are in sync
UML
In synergy with
code model
UML Evolve
Sync Back
Source: Patterns, Principles, and Practices of Domain-Driven Design, By Scott Millett, Nick
Tune
(Continuous) Collaboration in
DDD
Business
Domain
(business
experts)
Domain Model
&
Ubiquitous Language
Software
Development
(development team)
Software
Pro
duce
Based
on
Ubiquitous Language
Reflected
in
Direct mapping between business
domain concepts and software
artifacts
Conclusions
What is DDD?
• NOT a standard, framework or technology
• Is discovered and NOT invented
• Technology agnostic
• Set of principles, patterns and practices
• DDD enforce Object Oriented principles
• It is a learning process not a goal
• Etc..
When to apply
• When solutions seem more complex than
problems
• When communication with team members
and business experts deteriorates
• When velocity slows due to ineffective
collaboration…
• Applied in both, green field and legacy
projects
When could it be harmful?
• Data oriented and\or CRUD Projects
• Use DDD to model a complex domain in
the simplest possible way. Never use DDD
to make your solution more complex.
• Very few business operations (<30)
• Client imposes its way of developing
products
DDD benefits?
• Reduced complexity
• Continuous collaboration and feedback
• Translations are reduced to minimum
• Higher maintainability and transparency
• Clearer requirements
• Etc…
How to apply
1. Evaluate if makes sense to apply DDD in
your case
2. Shift your focus to business domain
3. Start from Ubiquitous Language
4. Start having modeling brainstorming
within the team and domain experts
5. Learn and consider DDD principles and
patterns in ALL team’s activities
References
• Domain-Driven Design: Tackling Complexity in the Heart of Software
• Domain Driven Design Quickly
• Applying Domain-Driven Design and Patterns: With Examples in C# and .NET
• Patterns of Enterprise Application Architecture
• .NET Domain-Driven Design with C#: Problem - Design – Solution
• Cargo DDD Application Sample – C# implementation/ Java implementation
• My e-mail [email protected]
Finally {
Thank you;
Questions?;
}