Lviv IT Arena is a conference specially designed for programmers, designers, developers, top managers, inverstors, entrepreneur and startuppers. Annually it takes place on 2-4 of October in Lviv at the Arena Lviv stadium. In 2015 conference gathered more than 1400 participants and over 100 speakers from companies like Facebook. FitBit, Mail.ru, HP, Epson and IBM. More details about conference at itarene.lviv.ua.
3. 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
5. Domain Model - is a rigorously
organized and selective abstraction
of the (Business) Domain
knowledge.
6. 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.
7. Main DDD premises
1. Primary focus should be on the domain
and domain logic
2. Complex domain designs should be
based on a model
13. 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
17. 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
18. 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.
20. Iteration 0 Iteration 1 Iteration 2 Iteration 3
Domain Experts
And BusinessAnalysts
UML
Developers
Iteration N?
Model evolves, bug
fixes, found issues
with analysismodel,...
Initially the
code model
matches
analysismodel
No Feedback loop,
descriptivedomain lost,
Code model no longer
reflectsanalysismodel
Source: Patterns, Principles, and Practices of Domain-Driven Design, By Scott Millett, Nick
Tune
21. Requirements Specification in
DDD
• Start first with benefits and goals
• Working backwards
• Exercise the ubiquitous language in
StoriesUse-Cases
• Look for key business examples in
StoriesUse-Cases to source as core
scenarios for modeling
22. 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
23. 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
24. 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
27. 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, Nic
30. 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..
31. 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
32. When could it be harmful?
• Data oriented andor 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
33. DDD benefits?
• Reduced complexity
• Continuous collaboration and feedback
• Translations are reduced to minimum
• Higher maintainability and transparency
• Clearer requirements
• Etc…
34. 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
35. 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 artur.trosin@gmail.com