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 Dirven Design
based on simple Systemic principles
helps developing high value Software for Domain Experts
3
Software for Domain Experts (SFDE)
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
Software for Domain Experts (SFDE)
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 ITSpecific 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 AgilityNeed for rapid response to market change
Monolithic and ERP systems are not change-friendly
5
Software for Domain Experts (SFDE)
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
Software for Domain Experts (SFDE)
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
Software for Domain Experts (SFDE)
Ubiquitous
Language
Model-Driven
Design
Bounded
Context
Model gives
structure to
Define model within
Names enter
Domain Driven Design :: Overview *
* Eric Evans, Domain-Driven Design Reference - Definitions and Pattern Summaries (2015)
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
Software for Domain Experts (SFDE)
Domain Driven Design :: Model Driven Design
* Eric Evans, Domain-Driven Design Reference - Definitions and Pattern Summaries (2015)
*
9
Software for Domain Experts (SFDE)
Domain Driven Design :: Bounded Context
* Eric Evans, Domain-Driven Design Reference - Definitions and Pattern Summaries (2015)
*
10
Software for Domain Experts (SFDE)
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.
*
* Eric Evans, Domain-Driven Design Reference - Definitions and Pattern Summaries (2015)
11
Software for Domain Experts (SFDE)
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
Software for Domain Experts (SFDE)
Domain Driven Design :: Sharing Knowledge
Ba as shared context in motion (Nonaka and Konno, 1998)
Domain ExpertS/W Expert
Models Models
Models
13
Software for Domain Experts (SFDE)
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
Software for Domain Experts (SFDE)
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
Software for Domain Experts (SFDE)
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
Software for Domain Experts (SFDE)
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
Software for Domain Experts (SFDE)
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
Software for Domain Experts (SFDE)
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
Software for Domain Experts (SFDE)
What we try to avoid
businessballs.com Original drawing: J Oakland, 1989
20
Software for Domain Experts (SFDE)
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