Ekon23 (1) Kingdom-Driven-Design

Kingdom Driven Design
Arnaud Bouchez – Synopse / LiveMon

Arnaud Bouchez
– Delphi / FPC
• Various solutions (from Vatican to gaming industry)
• Real-time Monitoring solution (LiveMon)
– Open Source
• mORMot (SOA ORM MVC framework)
• SynPDF SynMustache SynDB SynCrypto
– Training and consultancy
• Synopse one-man company
• mORMot for Architecture and (Domain-Driven-)Design

https://LiveMon.com
 Infrastructure Monitoring
 Log Management
 Artificial Intelligence
 External Monitoring
 Industry Standard Compatible

https://LiveMon.com
Object Pascal (FPC) and mORMot
for the local agent
for the server side
and the (rich) client side via a REST binary API
JavaScript clients via a REST JSON API

https://LiveMon.com
for building MicroServices
distributed on thousands of servers
e.g. execute a regex on logs at 2TB/second
or store millions of events per second
with a fair price

https://LiveMon.com
following a cut-down Domain-Driven-Design
= introducing Kingdom-Driven-Design

• Domain Driven Design
• Return Of Experience
• Kingdom Driven Design

Domain Driven Design
is a paranoid set
of Design and Architecture rules
to isolate the Model
of a well-identified Domain code
to ease large projects maintenance
and/or explore some new territories

http://martinfowler.com/bliki/DesignStaminaHypothesis.html

The Domain
• Well-identified
• Access to Domain Experts
• Complex and/or Exploring
• Valuable

The Domain
• Model Driven Design
– Iterative modelization
– Domain code describes (complex) reality
– Several Bounded Contexts

The Domain
• Ubiquitous Language
Code naming follows reality
and is not polluted by technology

Keep your Domain code clean
• Strict Isolation
Objects, DB, API, legacy, 3rd party

Keep your Domain code clean
• Paranoid Isolation

Paranoid Objects Isolation
• Plain Old Delphi Objects (PODO)
– Value Objects
– Entities
– Aggregates
– Events

Paranoid DB Isolation
• Agnostic Persistence layer
of the PODO Aggregates
• Injected in Application Layer
• Easily mocked/stubbed
• NO logic in the database - CRUD

Paranoid API Isolation
• Never leak the Domain
– Keep Domain objects and services private
– Define adapter interfaces in Domain,
implement in separated Infrastructure layer
– Application Layer as isolation layer

Paranoid API Isolation
• Application Layer
– Workflow Orchestration via Injection
– Customized public APIs
– Below presentation Layer (rich or web client)
– Define Data Transfer Objects (DTOs)

Paranoid Legacy Isolation
• Domain code is new/first/clean
– NO copy & paste
– Test Driven Design
• Legacy code injected as Seams
– e.g. for the persistence layer
or as external services

Paranoid 3rd party Isolation
• Service Abstraction by Adapters
– interfaces defined in Domain
– class implemented outside the Domain
(may be as a SaaS client)
in the Infrastructure Layer
– injected by the Application Layer

Domain-Driven-Design

Domain-Driven-Design
Unbreakable Isolation

is FUN, isn’t?

Return Of Experience
• DDD in a DotNet project
• DDD in a Delphi project
more than 5 years of DDD code writing
and consulting

DDD in a DotNet project
• WCF, WPF, legacy DB
• Legacy Delphi & Java apps
• Verbose and not clean
• Services difficult to deploy

DDD in a DotNet project
Legacy & Hybrid Cost

DDD in a Delphi project
• IoT high performance solution
– “Things” agnostic (Domain as HAL)
– Data sharding and CQRS
– written from scratch
– mORMot as toolbox

• Following DDD rules has a cost
– higher time-to-market, skilled developpers
– users still prefer direct “Things” layer access
– business don’t care (much) about DDD

• mORMot toolbox helped but…
– persistence layer PODO to ORM mapping
– asynch DDD service to synch public API
– defining and translating a lot of DTOs

“Le mieux est le pire ennemi du bien”
Charles-Louis de Montesquieu

“Le mieux est le pire ennemi du bien”
Charles-Louis de Montesquieu
“Perfect is the worst enemy of good”

From DDD to KDD
reintroduce laziness

From DDD to KDD
reintroduce laziness
i.e. “the quality that makes you go to great effort to
reduce overall energy expenditure. It makes you write
labor-saving programs that other people will find
useful and document what you wrote so you don't
have to answer so many questions about it.”
Larry Wall

From DDD to KDD
• a pragmatic cut-down version of DDD
• focusing on SOLID principles
• leveraging the Object Pascal platform

From DDD to KDD
Kingdom isolation with no paranoia
embrace business/human/time contingency

Taxonomic
ranks

Kingdom
• Slightly closer to technology
• Disclaimer:
– DDD had nothing to do with taxonomy
– KDD is still Model-Driven-Design
– Let your Kingdom come!

The Kingdom
• Well-identified
• (Complex)
• Access to Kingdom Experts
• Per Bounded Contexts

Keep your Kingdom code clean
• Ubiquitous Language
Code naming follows reality
but could be slightly polluted by technology
(e.g. ORM or serialization class)

Keep your Kingdom code clean
• Pragmatic Isolation
• Rooted in SOLID principles
practical OOP, Injection, MicroServices
• Leverage language and libraries
RTTI, interfaces, SOA

Pragmatic Objects Isolation
• Use language/library features
– Value Objects = records or variants
– Entities = persistent classes
– Aggregates = ORM classes
– Events = records or variants

Pragmatic DB Isolation
• Agnostic Persistence layer
is what an ORM is for
 direct ORM use
 no persistence interface / service
• NO logic in the database - CRUD

Pragmatic API Isolation
• Keep the Kingdom uncoupled
– Define adapter interfaces in Kingdom,
implement in separated Infrastructure layer
– Application Layer as orchestration layer
(just like Domain-Driven-Design)

• But may leak the Kingdom
– Keep Kingdom services private
– May expose Kingdom objects
i.e. leak objects as properties (content)
not with methods (process)
e.g. JSON REST exposure

• Application Layer / public APIs
– Workflow Orchestration via Injection
Orchestrate rather than Isolate
– Define Data Transfer Objects (DTOs)
and/or expose Kingdom objects (JSON/variant)
following pragmatic arbitrations

Pragmatic Legacy Isolation
• Kingdom code
– copy & paste & adapt existing objects/DB
– uncoupling as much as possible
– introduce Test Driven Design
• Legacy code injected as Seams
– e.g. persistence layer or external services

Kingdom 3rd party Isolation
• Service Abstraction by Adapters
– interfaces defined in Kingdom
– class implemented outside the Kingdom
(may be as a SaaS client)
in the Infrastructure Layer
– injected by the Application Layer

X
Kingdom Layer
Kingdom
Model
Kingdom Services
Kingdom-Driven-Design

is Domain-Driven-Design but
• direct ORM persistence
and library (ab)use (e.g. serialization)
• (maybe) leaked objects
• SOLID principles roots

is Domain-Driven-Design but
• direct ORM persistence
tied to a given ORM/library
• (maybe) leaked objects
harden any breaking change
• SOLID principles roots
more technical code

Distributed MicroServices architecture
Monolithic
Distributed
SOLID SOA

• favors SOLID code over isolated code
• uncoupled MicroServices vs uncoupled code
• prefers convention over configuration
• small skilled team vs Conway’s Law separation
• leverages language/toolbox features
• for pragmatic Time-To-Market

mORMot as KDD Toolbox
… to be continued 

• Questions?

Ekon23 (1) Kingdom-Driven-Design

More Related Content

Similar to Ekon23 (1) Kingdom-Driven-Design

More from Arnaud Bouchez

Recently uploaded

Ekon23 (1) Kingdom-Driven-Design