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.

1. Domain-Driven Design (DDD)
effective collaboration
Artur Trosin
Presentation for: Lviv IT Arena, 2015

2. Before we start

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

4. Domain – a sphere of knowledge or
activity

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

8. Domain Model and modelling

9. • Modelling and design are the quickest way
to actual goal
Eric Evans
Modelling the Domain

10. Atom Models Evolution
Why models?

11. Even Music has 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

14. Bounded context
Source: http://martinfowler.com/bliki/BoundedContext.html

15. Ubiquitous Language

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.

19. Effective Collaboration & SDLC

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

25. Classic Layering
UI
Business Entities
Data Access
DB
Record Sets or
Data Sets or
POCO or
POJO
No Clear Business layer isolation

26. DDD recommended-Layering
Presentation
Application
Domain
Infrastructure

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

28. (Continuous) Collaboration in
DDD
Business
Domain
(business
experts)
Domain Model
&
Ubiquitous Language
Software
Development
(development team)
Software
Produce
Based
on
Ubiquitous Language
Reflected
in
Direct mapping between business
domain concepts and software
artifacts

29. Conclusions

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 

36. Finally {
Thank you;
Questions?;
}