Domain Driven Design: Made Easy employing Systemic Approach

Domain Driven Design:
Panagiotis Papaioannou
p.papaioannou@gmail.com
Made Easy employing Systemic Approach

2
Software for Domain Experts (SFDE)
Purpose and Structure of the Presentation
Topics:
• Software for Domain Experts (SFDE) - Low Code development
• Domain Driven Design basics
• Systemic Approach basics
Proposition:
Domain Driven Design
based on simple Systemic principles
helps developing high value Software for Domain Experts

3
SFDE for small projects
Domain Expert
S/W Expert
Low Code Dev
A
Niche Market
Product
Domain expert: A person with special knowledge or skills in a particular area
(different than s/w development)
Software expert: A technical expert or a “Business – IT Liaison”
Low Code Dev: Developing applications with minimal coding requirement
SFDE concept can be applied to:
 External customers
 Internal customers

4
Why Software for Domain Experts
Empathetic Software
I want s/w that works the way I think
Specifics of my job are not covered by our ERP
ERP is not friendly regarding my work
Bridge the gap between
Business and IT
Specific business processes are not covered by the ERP
Business Differentiation
Competitive advantage
I do not work the same way with my competitors
I need functionality that serves my competitive advantage
Process/Business Agility
Need for rapid response to market change
Monolithic and ERP systems are not change-friendly

5
Domain Driven Design
Introduced by Eric Evans (2004) as an approach to
the development of complex software
The idea:
• Start focusing on the core domain and domain
logic
• Base the design on model(s) of the domain
• Initiate a creative collaboration between technical
and domain experts
• Iteratively refine a conceptual model of the
domain and the related problems

6
Domain Driven Design :: Key Concepts
* Eric Evans, Domain-Driven Design Reference - Definitions and Pattern Summaries (2015)
Domain A sphere of knowledge, influence, or activity. The subject area to which
the user applies a program is the domain of the software.
Model A system of abstractions that describes selected aspects of a domain and
can be used to solve problems related to that domain.
Ubiquitous
Language
A language structured around the domain model and used by all team
members within a bounded context to connect all the activities of the
team with the software.
Context The setting in which a word or statement appears that determines its
meaning. Statements about a model can only be understood in a
context.
Bounded
Context
A description of a boundary (typically a subsystem, or the work of a
particular team) within which a particular model is defined and
applicable.
*

7
Ubiquitous
Language
Model-Driven
Design
Bounded
Context
Model gives
structure to
Define model within
Names enter
Domain Driven Design :: Overview *
Express model with:
• Entities
• Value Objects
• Services
• Domain Events
Isolate Domain(s) with:
• Layered Architectures
Keep model unified with:
• Continuous Integration
Assess/Overview
Relationships with:
• Context Map

8
Domain Driven Design :: Model Driven Design
*

9
Domain Driven Design :: Bounded Context
*

10
Domain Driven Design :: Summary
1) Focus on the core domain.
2) Explore models in a creative collaboration of
domain practitioners and software practitioners.
3) Speak a ubiquitous language
within an explicitly bounded context.
*

11
Why Domain Driven Design
Is it worth for small projects?
DDD was intended for complex projects.
DDD is (said to be) too complex for a simple (CRUD) app.
BUT
• How do we know it’s a simple app, without having a domain model?
• DDD is a way of thinking - not a technology or a methodology
• Focuses on the value of the application.
• Domain driven design is all about understanding the problem that the
customer is trying to solve.
• Models – models - models
Where is the scale of the project ?

12
Domain Driven Design :: Sharing Knowledge
Ba as shared context in motion (Nonaka and Konno, 1998)
Domain ExpertS/W Expert
Models Models
Models

13
The System of the Organization
Raw Materials
Capital
Information
(…)
Inputs
Work Activities
Management Activities
Methods
(…)
Transformation
Products
Services
Financial Results
Information
(…)
Outputs
Feedback
The Organization as an Open System

14
Systemic Approach
• Organization is a system of interacting components
• There is a system-subsystem structure of the organization
• The system has boundaries that have to be defined
• A system has inputs/outputs and performs a transformation
Benefits: Understand and model the domain – Define context
Reduce complexity formulating domains - subdomains
Establish the ubiquitous language

15
Systemic Approach
• What matters is the interaction between the parts, not the parts themselves
• The whole is greater than the sum of its parts (the big picture!)
• The system (the organization) serves a purpose
Benefits: Understand the internal function of the domain
Understand what customer wants – strategic goals – satisfaction criteria
Focus on outcomes

16
Systemic Approach
There are feedback loops in the causality paths.
These feedback loops produce complex system behaviors.
Benefits: Deeply understand the domain (structure  behavior)
Dynamics of the domain (behavior  events)
Uncover the big pic of the domain

17
Systemic Approach
• What matters are reoccurring patterns
rather than individual events.
Patterns of behavior lead to structure
discovery.
• Small interventions in a part of the
organization may have effects on other
sections or on the organization as a
whole.
Benefits: Understand the domain events  behavior  structure
Intervention risks
Sustainable solutions

18
How Systemic Approach helps in Domain Driven Designing
• Understand the Domain (purpose, boundaries)
• Model the Domain (System – subsystem structure, relations)
• Uncover the big picture of the domain
• Stay focused on outcomes
• Discover dynamics that are taking place in the domain
• Explore intervention risks
• Deal with Complexity - bring Order out of chaos
• A stable background for learning
• A good way to integrate new ideas within the organization’s context
• Model the Context of the Domain and Subdomains
• Establish a common language (the ubiquitous language)
• Sustainable solutions
• Effectively management of organizational changes
Summary

19
What we try to avoid
businessballs.com Original drawing: J Oakland, 1989

20
Domain Driven Design concepts
Focus on the core domain
Explore models
Collaborate with domain practitioners
Create and use a common language
Systemic Approach principles
Model and understand the domain
and the context / Reduce complexity
Establishes the common language
Sustainable solutions
Empathetic Software
Process/Business Agility
Bridge the gap between Business and IT
Business Differentiation, Competitive advantage
SFDE

21
g{tÇ~ lÉâ
Panagiotis Papaioannou
p.papaioannou@gmail.com

Domain Driven Design: Made Easy employing Systemic Approach

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Domain Driven Design: Made Easy employing Systemic Approach

Similar to Domain Driven Design: Made Easy employing Systemic Approach (20)

More from Panagiotis Papaioannou

More from Panagiotis Papaioannou (16)

Recently uploaded

Recently uploaded (20)

Domain Driven Design: Made Easy employing Systemic Approach