Domain Driven Design9d1ddba3041f47f786ee-4c6a0a54e56273f47aeed2714873ec3c.r48.cf1.rackcd… ·...

Domain Driven Design

Panagiotis Papaioannou

[email protected]

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 Dirven 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 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


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

[email protected]

Domain Driven Design9d1ddba3041f47f786ee-4c6a0a54e56273f47aeed2714873ec3c.r48.cf1.rackcd… ·...

Documents

Transcript of Domain Driven Design9d1ddba3041f47f786ee-4c6a0a54e56273f47aeed2714873ec3c.r48.cf1.rackcd… ·...