2. ERNI -Innovation in Process and Technology
Página 3
What is DDD about?
The problem first
DOMAIN
PROBLEM
• The subject area for
which you are building
software.
• Sphere of knowledge,
influence or activity.
COMPLEXITY
• Tackling complexity.
• Focus on the core
problem domain.
COLLABORATION
• Technical Experts and
Business Experts must
share the same
language.
• Ubiquitous Language
3. ERNI -Innovation in Process and Technology
Página 4
What is NOT ONLY DDD about?
The technology second
ARCHITECTURE / FRAMEWORKS
• Don’t be fooled by fancy frameworks
DESIGN PATTERNS
• Object Oriented Design Patterns.
METHODOLOGY
• Apply an agile/iterative methodology
4. ERNI -Innovation in Process and Technology
Página 5
When to apply DDD
• Medium high problem domain of
high importance to the customer
business
Complex
Problem Domain
• Aligned to the vision of the project
Access to
Domain Experts
• Eager to learn about the problem
domain.
Skilled,
Motivated and
Passionate Team
5. ERNI -Innovation in Process and Technology
Página 6
When and Why apply DDD?
DevelopmentEffort
Complexity
Low complexity project High complexity project
6. ERNI -Innovation in Process and Technology
Página 10
How to apply DDD: Divide the problem domain
Product BuilderPromotion
Retention
Notification
Shipping
Loyalty
Inventory
Shopping
Fulfillment
Sales
Procurement
E-Commerce
Core Domain
Generic Domains
Supporting Domain
7. ERNI -Innovation in Process and Technology
Página 12
Ubiquitous Language: One Team, One Language
Technical
Expert
Jargon
Ubiquitous
Language
JargonBusiness
Expert
8. ERNI -Innovation in Process and Technology
Página 13
Ubiquitous Language :
Connect the analysis model with the code
UBIQUITUOUS
LANGUAGE
DOMAIN EXPERTS DEVELOPMENT TEAM
9. ERNI -Innovation in Process and Technology
Página 17
What’s next?
SERVICE ITEM
•Starting point and
basic knowledge
about DDD.
NETWORKING
•Build up a network
for sharing DDD
project experiences
EXPERTISE
•DDD Point Of
Contact in the
company.
•Provide DDD
expertise for new
projects.
11. ERNI -Innovation in Process and Technology
Página 20
www.erni-consultants.com
Editor's Notes
STARTING POINT – Why do we build software? What is the final purpose?
Solve a problem. Add business value. Provide a solution to the customer.
NOT EASY TO DELIVER REAL BUSINESS VALUE through software development.
I will provide an overview of DDD, it is a huge topic and I’d like to get across the most important ideas behind it.
I’d like at least to answer these main questions in order to you to get an impression of DDD and get which are the benefits.
What is all about?
When it can be applied?
Why should apply it?
How it can be done?
COLLABORATION FOR UNDERSTANDING THE DOMAIN PROBLEM AND COME UP WITH A SOLUTION.
HIGH COMPLEXITY => BEST FOCUS ON THE CORE OF THE BUSINESS, THE MOST VALUABLE PART OF OUR CUSTOMER BUSINESS.
“The critical complexity of most software projects is understanding the business domain itself”
Eric Evans.
Focus on the core
Provide real business value to the customer.
Put your effort where in the part of the business wich diferentiates from the competence, what makes our customer make money and being competitive in the market
Collaboration
The only way to build a software which can add real business value to the customer is through collaboration, exploration and learning from the business experts. UBIQUITUOS LANGUAGE.
It’s rather an approach or a Philosophy
Development team COMMON MISTAKES: TOO Focus on technology
It’s not easy to deliver software which adds real business value.
Development Team vs Business Experts have different points of view.
Development Team too far from the problem knowledge.
Business Experts too far from the tehcnology constraints.
Provide real business value. Software valuable for the customer. => collaboration.
It does not matter how powerful is your toolbox if you don’t understand the problem to solve.
Common mistakes (Technology first Domain last):
Eager to Overengineering
Eager to apply trendy and latest/ early adoption/ cutting edge
I don’t mind about the business domain where I’m working on.
New “developer” mindset aligned with Agile and with adding value to the business
There is no silver bullet for your problem. Don’t try to find it.
Not everything is about the latest technology … build and learn from the business you are working on. (ADD real business value)
Be always as pragmatic as you can be, don’t add extra accidental complexity to your projects.
Complex domain problems in medium large customers: automotive, government, ecommerce, insurance companies … 1minute
TEAM PROBLEM: The development team is usually more keen on learning new technologies than in learning the domain problem.
Access To Domain Experts => Much more difficult in the software factory.
Highly skilled team at erni is not a big deal.
Low complexity project : Data Entry CRUD application
High complex project: implement e commerce platform
A Lack Of Focus On The Business 1 minute
Domain-Driven Design can be thought of a development philosophy, it promotes a new domain centric way of thinking.
Any team can write a software product to meet a problem, but teams that put time and effort in the problem domain that they are working on will consistently be able to evolve the product to meet new business use cases.
Learning about your domain problem is more likely to happen at the end of the project than at the begining Continuos Refactoring
How we can have a system organized?
which can be easily evolved and aligned with the business problem, ?
can last longer than the technology itself.?
THE PROBLEM SPACE: Understanding What Is Important
Distill the problem domain
Learn about the problem: It is the learning process, not the end goal that is the greatest strength of Domain-Driven Design.
THE SOLUTION SPACE: Building a Model
The domain model: useful abstraction of the Reality
Ubiquituos Language
sub-domains which typically reflect some organizational structure.
THERE IS NEVER A UNIQUE DOMAIN MODEL FOR THE ENTIRE PROBLEM SPACE
Distillation is used to break down a large model to discover the core, supporting, and generic domains from within the mass of domain knowledge.
Focus and effort should be invested on the core domain.
• The core domain is the reason you are writing the software.
• Outsource, buy in, or put juniors on the supporting and generic domains.
One Domain Model for each context…
THERE IS NO UNIQUE DOMAIN MODEL FOR THE ENTIRE PROBLEM SPACE
Domain Models Contain Only What Is Relevant
“If you can’t explain it in simple terms, you don’t know it well enough.” Einstein
Knowledge Crunching is the art of gathering relevant information about the problem domain in order to build a useful model which can fulfil the needs of the business use cases
“Throw Away Your First Model, And Your Second Domain Model”: A model is constantly evolving and changing, you cannot effectively utilize the practices and patterns of Domain-Driven Design without embracing evolution.
Exploration and Experimentation
Challenge Your Assumptions
Modeling Is A Continuous Activity
How we build the domain model? => Collaboration
There is only one domain language, There is no developer language and business experts language. No language translations.
The language evolve with the model during the lifetime of the project.
The desing is the code and the code is the design. No more translations please!
Collaborating With Domain Experts
Evolve A Ubiquitous Language To Remove Ambiguity
Build ubiquituos language in order to write good user stories, white board discussions, build analyis and design models ….
THE MOST IMPORTANT TOOL FOR KEEPING IN SYNC … CODE AND DESIGN!
NOT ONLY THE DEVELOPERS GETS CLOSER TO BUSINESS WORLD…. THE DOMAIN EXPERTS GETS CLOSER TO DEVELOPMENT WORLD.
“Final source code is the real software design” ISOLATE YOUR DOMAIN MODEL
Implement the model in code
The mental model that was created between you and your domain expert should be reflected in code with the same terminology, language and concepts.
Programmers should speak the language of domain experts to avoid miscommunication, delays, and errors. To avoid mental translation between domain language and code, design your software to use the language of the domain. Reflect in code how users of the softwarethink and speak about their work. One powerful approach is to create a domain model.
The ubiquitous language is a living language. Domain experts influence design and code and the issues discovered while coding influence domain experts. When you discover discrepancies, it's an opportunity for conversation and joint discovery. Then update your design to reflect the results.
DISADVANTATGES
The huge investment must be justified with a real complex problem domain.
The development team must be highly proficient in object oriented design and motivated about learning the domain problem in depth.
Real access and involvement from the business experts.
ADVANTATGES
The real benefits only comes with real complex problem domains:
The ubiquitious language connecting every task of the project.
The domain model implementation helps to create business value:
Focus on the most valuable business part of the customer.
Reflects how the real business works easing the continuos evolvement.
Isolated from concrete technology.
