A Modern Fresher Perspective on DDD - SDD Conferencesddconf.com/brands/sdd/library/sdd_esposito_ddd.pdf · A Modern Fresher Perspective on DDD ... ADD PERSON RELATED TO THIS BOOKING

EXPOWARE SOFT - 2016

Dino Esposito

A Modern Fresher Perspective on DDD

@despos facebook.com/naa4e Press


Placing the project's primary focus on the core domain and domain logic.

Basing complex designs on a model of the domain.

Initiating a creative collaboration between technical and domain experts to iteratively

refine a conceptual model that addresses particular domain problems.

DDD – Domain-driven Design

http://en.wikipedia.org/wiki/Domain-driven_design


Where Does Complexity Come From?

1 Make sense of requirements

2 Build a (relational) data model Try

again3 Identify relevant tasks and data tables

Build a user interface4

Close to what users wanted but…5

over and over



1 Make sense of requirements

2 Build a (relational) data model Try

again3 Identify relevant tasks and data tables

Build a user interface4

Close to what users wanted but…5

over and over

PROCESSES



Relevant data tables

Relevant tasks


even more


COMPLEXITY

EFFORT

SMALL INCREASE IN

COMPLEXITY

LARGER INCREASE IN

EFFORT

CRUD

DOMAIN

MODEL

COMPLEXITY

EFFORT

CRUD

DOMAIN

MODEL

TODAY

Elaborated from PoEAA, Martin Fowler


Ever tried. Ever failed. No matter. Try again. Fail again. Fail better.

Samuel Beckett, Worstward Ho, 1983


ImplementationStrategic Design

Domain-driven Design

Ubiquitous language

Bounded contexts

Domain modelLayered

architecture

MORE


FRESHER?

DOMAIN

MODEL

What’s that?


Software Model for the Domain

PARADIGM(s)

PROCEDURALFUNCTIONALOBJECT

ORIENTED

CRITICAL POINT


Ubiquitous

language

• Shared vocabulary

• Used all the time

Bounded

context

• Has its own

language

• Has its own

implementation

Context

map

• Connections

between contexts

• Set priorities


UBIQUITOUS LANGUAGE


PURPOSE

People use different languages

■ Developers and domain experts

■ Business people from different departments

Help making sense of user requirements

■ Mitigate the risks of misunderstandings at any time

■ Avoid translation between jargons

Common terminology

■ Official language of the project; strictly business-driven


Real-world Examples of UL

ARGUABLE CHANGEPlain preference? Right of the lord? Sadistic instinct?


Real-world Examples of UL

ADD PERSON RELATED TO THIS BOOKING

REASONABLE CHANGEMight be confusing to actual users


Saved to wiki (or Excel)

- Each term fully explained, understandable to both

domain and software experts

Kept up-to-date (nothing but static)

- Evolve as new insights are gained about the domain

- Responsibility of the development team

LANGUAGE ACRONYMSMULTI-TENANT

SOFTWARE

COMMON ISSUES


■ Voucher is the domain name.

■ Synonyms like coupon or gift card not allowed.

Noun

Verb

Registered Customer

Voucher

Redeem

Order

Place

Ordered Items

Pay


Ubiquitous ≈ Used Everywhere

■ User Stories & RFC

■ Meetings

■ Emails

■ Technical Documentation

■ Schedule

■ Source code


SPEAKING OF SOURCE CODE …

DISCOVERING AND UNDERSTANDING

REAL BUSINESS PROCESSESTAKING PLACE IN THE DOMAIN


INVOICE ISSUED

EMAIL CUSTOMER

in 3 WEEKS

WHAT DOES IT MEAN???

SHOULD WE SWAP THESE?

NEEDMONITORING

CRITICAL NOTES

ALERT NOTES

ACTIONSDOMAIN EVENTS

Can’t be changed anymore

NEED GREAT UI HERE


■ VALIDATED BY INVOLVED PEOPLE

■ ROADBLOCKS IDENTIFIED

■ UX ASSESSED

Commands and events orchestrated in a saga

CHECKOUT process


BOUNDED CONTEXT


Business

domain

Bounded

context

Bounded

context

Bounded

context

Bounded

context

Business

domain

SOFTWARE MODEL


Bounded Context

Ubiquitous language

Independent

implementation

External interface

(to other contexts)


Functional areas of the application that are better treated separately

Same term meaning different things to different people

Same term used to indicate different elements

Dependency on external subsystems

Dependency on legacy code

Why Having Bounded Contexts


Theoretical View?


CONTEXT MAP


Frontend

Shopping cart

Processing logic

Accounting

Backoffice

Business rules

(discounts, configuration,

personalization)

Shipping

External

system

Persistence

Payment

External

system


FRONTEND

SHOPPING CART

Application logic

BACKOFFICE

ACCOUNTING

PAYMENT SHIPPING

BIZ RULES

PERSISTENCE

SHIPPING

gateway

PAYMENT

gateway

d

u

u

d

uu

dd

partner

supplier

supplier

conformist

supplier


• Downstream context depends on upstream context

• No negotiation possibleConformist

• Customer context depends on supplier context

• Chance to raise concerns and have them addressed in some

wayCustomer/Supplier

• Mutual dependency between the two contexts (i.e., shared

kernel)Partner

• Additional layer giving the downstream context a fixed

interface no matter what happens in the upstream context

Anti-corruption

Layer


REALISTIC

CONTEXT MAP


MONOLITHIC APPLICATION


SEGMENTED APPLICATION


from BOUNDED CONTEXT to MICROSERVICE


Microservices

Independent

vertical stacks of

logic and data

Can contain replicated data

Can access data via services

Easy to package

and deploy

Easy to assign to

development

teams

Work well with

containers

Not that well with

Visual Studio Nuget packages better way to share code than references


The user of the software won’t know what she wants until she sees the software.

Humphrey’s Law

An interactive system can never be fully specified nor can it ever be fully tested.

Wegner’s Lemma

Pluralsight courses UXDD/DDD

Documents

A Modern Fresher Perspective on DDD - SDD Conferencesddconf.com/brands/sdd/library/sdd_esposito_ddd.pdf · A Modern Fresher Perspective on DDD ... ADD PERSON RELATED TO THIS BOOKING