Scribd
Upload
177 views38 pages

Domain-Driven Design and Event-Driven Microservices Matt Stine (@mstine)

This document discusses domain-driven design and event-driven microservices. It notes common problems with microservice architectures like building the wrong services, too many services, or not needing services. It emphasizes the importance of designing around domains and seams. The document also discusses different decomposition strategies like functional decomposition and capability decomposition, noting that capability decomposition better isolates changes and supports independent development. Finally, it discusses how the fundamental principles of effective module decomposition have not changed in decades, focusing on designing modules around problem domains and likely areas of change rather than execution flow.

Uploaded by

kasusr
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
177 views38 pages

Domain-Driven Design and Event-Driven Microservices Matt Stine (@mstine)

This document discusses domain-driven design and event-driven microservices. It notes common problems with microservice architectures like building the wrong services, too many services, or not needing services. It emphasizes the importance of designing around domains and seams. The document also discusses different decomposition strategies like functional decomposition and capability decomposition, noting that capability decomposition better isolates changes and supports independent development. Finally, it discusses how the fundamental principles of effective module decomposition have not changed in decades, focusing on designing modules around problem domains and likely areas of change rather than execution flow.

Uploaded by

kasusr
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 38

Why DDD?

Domain-Driven Design and Event-Driven Microservices


Matt Stine (@mstine)
http://mattstine.com
[email protected]
What is the
State of Microservices
in 2021?
We built the WRONG microservices!
We built TOO MANY microservices!
We DIDN’T REALLY NEED microservices!
We created the SAME OLD ARCHITECTURE with
microservices!
what we’ve got
here is failure to

DESIGN
WHERE ARE THE

SEAMS?
https://builttoadapt.io/whats-your-decomposition-strategy-e19b8e72ac8f
This paper discusses modularization as a
mechanism for improving the flexibility and
comprehensibility of a system while allowing
the shortening of its development time. The
effectiveness of a "modularization” is
dependent upon the criteria used in dividing
the system into modules.
The major progress in the area of modular
programming has been the development of
coding techniques and assemblers which (1)
allow one module to be written with little
knowledge of the code used in another
module and, (2) allow modules to be
reassembled and replaced without
reassembly of the whole system.
Decomposition Techniques

Let’s build an online store!


Product
Orders Inventory Payment Notifications Fulfillment Shipping
Catalog
UI

Services

Data
UI

Domain Model
Services

Data
UI

Domain Model
Services

Data
UI

Services

Domain Model
Services

Data
UI

Services

Domain Model
Services

Data
UI

MVC Controllers / Views

Services

Domain Model
Services

Data
UI

MVC Controllers / Views

Services

Domain Model
Services

Data
UI

MVC Controllers / Views

Services

Domain Model
Services

Data
UI

MVC Controllers / Views

Services

Domain Model
Services

Data
Functional Decomposition

Changes Independent Comprehensibility


Development
Struggles with Dependent on shared You need to know
knowledge spread data formats and something about how
across all modules, so schema. Must be all of the modules work
often each module has jointly defined and to understand the
to change in response agreed upon across whole system.
to a desired functional multiple groups.
change.
Decomposition Techniques

Let’s Refactor to a
Capability Decomposition
Capability Decomposition

Changes Independent Comprehensibility


Development
Usually isolates a Has abstract interfaces You can understand
change to a single that encapsulate the modules independently.
module. work to be done..
We have tried to demonstrate…it is almost always incorrect to
begin the decomposition of a system into modules on the basis
of a flowchart…instead that one begins with a list of difficult
design decisions or design decisions which are likely to change.
Each module is then designed to hide such a decision from the
others. Since, in most cases, design decisions transcend time of
execution, modules will not correspond to steps in the
processing…we must abandon the assumption that a module is
one or more subroutines, and instead allow subroutines and
programs to be assembled collections of code from various
modules.
Decomposition Techniques

The fundamental ways in which we design


modules effectively has not changed in the
last 50 years.
DOMAIN
MODEL

TECHNICAL
ARCHITECTURE
DOMAIN
DRIVEN
DESIGN

MICROSERVICES
thank you!
Domain-Driven Design and Event-Driven Microservices
Matt Stine (@mstine)
http://mattstine.com
[email protected]

You might also like