Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Fundamental Domain-Driven Design For Microservices
Search
Oliver Drotbohm
July 07, 2016
Programming
4
680
Fundamental Domain-Driven Design For Microservices
Slides of the talk I gave at Java Forum Stuttgart 2016.
#jfs2016 @springcentral
Oliver Drotbohm
July 07, 2016
Tweet
Share
More Decks by Oliver Drotbohm
See All by Oliver Drotbohm
It Takes Two to Tango – Designing Module Interactions in Modulithic Spring Applications
olivergierke
5
670
Bottom-Up Architecture – Bridging the Achitecture Code Gap
olivergierke
4
910
Spring Modulith – A Deep Dive
olivergierke
8
4.3k
Spring for the Architecturally Curious Developer
olivergierke
5
1.8k
Spring Boot 3 & Spring Framework 6
olivergierke
4
2k
Architecturally-evident Java Applications with jMolecules
olivergierke
9
2.9k
A Deep Dive into Spring Application Events
olivergierke
12
3.3k
Building Better Monoliths – Modulithic Applications with Spring Boot
olivergierke
4
950
Spring HATEOAS – Hypermedia APIs with Spring
olivergierke
1
740
Other Decks in Programming
See All in Programming
Webからモバイルへ Vue.js × Capacitor 活用事例
naokihaba
0
740
AIエージェントはこう育てる - GitHub Copilot Agentとチームの共進化サイクル
koboriakira
0
220
git worktree × Claude Code × MCP ~生成AI時代の並列開発フロー~
hisuzuya
0
230
Perplexity Slack Botを作ってAI活用を進めた話 / AI Engineering Summit プレイベント
n3xem
0
670
「Cursor/Devin全社導入の理想と現実」のその後
saitoryc
0
110
FormFlow - Build Stunning Multistep Forms
yceruto
1
190
今ならAmazon ECSのサービス間通信をどう選ぶか / Selection of ECS Interservice Communication 2025
tkikuc
12
2.9k
ASP.NETアプリケーションのモダナイズ インフラ編
tomokusaba
1
390
Effect の双対、Coeffect
yukikurage
5
1.4k
複数アプリケーションを育てていくための共通化戦略
irof
10
4k
生成AIコーディングとの向き合い方、AIと共創するという考え方 / How to deal with generative AI coding and the concept of co-creating with AI
seike460
PRO
1
320
Datadog RUM 本番導入までの道
shinter61
1
310
Featured
See All Featured
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
Writing Fast Ruby
sferik
628
61k
Rebuilding a faster, lazier Slack
samanthasiow
81
9k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
161
15k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
46
9.6k
Build your cross-platform service in a week with App Engine
jlugia
231
18k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
48
2.8k
[RailsConf 2023] Rails as a piece of cake
palkan
55
5.6k
How to train your dragon (web standard)
notwaldorf
92
6.1k
Bash Introduction
62gerente
614
210k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
PRO
181
53k
Code Review Best Practice
trishagee
68
18k
Transcript
© 2014 SpringOne 2GX. All rights reserved. Do not distribute
without permission. DOMAIN-DRIVEN DESIGN / OLIVERGIERKE ƻ
[email protected]
FUNDAMENTAL FOR MICROSERVICES
2
None
4 http://www.infoq.com/minibooks/domain-driven-design-quickly
Microservices ♥ Domain-Driven Design 5 11:10 — Beethoven Saal
6
6
Implementing Domain-Driven Design 7
Value objects 8
Stringly typed code 9 public class Customer { private Long
id; private String firstname, lastname, email; … }
Stringly typed code 10 public class SomeService { public void
createUser(String firstname, String lastname, String email) { … } }
11 public class Customer { private Long id; private Firstname
firstname; private Lastname lastname; private EmailAddress emailAddress; … }
Value Objects are a PITA to build in some languages.
12
Still, they’re worth it. 13 See „Power Use of Value
Objects in DDD“ by Dan Bergh Johnsson.
Lombok — putting the spice back into Java. 14
15 @Value public class Customer { UUID id = UUID.randomUUID();
Firstname firstname; Lastname lastname; EmailAddress email; @Value static class EmailAddress { String value; } }
AutoValue 16 Project website on GitHub.
Entities & Aggregates 17
18 Order LineItem Product Invoice Customer Payment Address Email
18 Order LineItem Product Invoice Customer Payment Address Email
Persistence technology VS. Domain model 19
Aggregate = Entity + Repository 20
21 Order LineItem Product Invoice Customer Payment Address Email
Bounded Context 22
Order LineItem Product Invoice Customer Payment Address
24 Shipping Accounting Catalog Orders User Registration
24 Shipping Accounting Catalog Orders User Registration Accounting Payment information
Billing Address Shipping Shipping address Customer Product
Domain-Driven Design & Monoliths 25
Avoid technologies that get in your way. 26
How to enforce context boundaries? 27
What about consistency? 28
References between Bounded Contexts? 29
Domain Events 30
31 Level 0: No events at all
31 Level 0: No events at all Level 1: Explicit
operations
If you’re calling two setters in a row, you’re missing
a concept. 32
33 Level 0: No events at all Level 1: Explicit
operations Level 2: Some operations as events
State transitions become domain events. 34
35 Level 0: No events at all Level 1: Explicit
operations Level 2: Some operations as events Level 3: Event Sourcing
Domain-Driven Design & Microservices 36
Bounded contexts define system boundaries. 37
38 Shipping Accounting Catalog Orders User Registration Accounting Payment information
Billing Address Shipping Shipping address Customer Product
39 Shipping Accounting Catalog Orders User Registration Accounting Shipping
40 Shipping Accounting Catalog Orders User Registration Accounting Shipping HTTP
Messaging
Architecture is less likely to deteriorate as it’s harder to
violate boundaries. 41
Restructuring service boundaries is much harder. 42
Inter-Service communication becomes remote communication. 43
Accept and embrace eventual consistency between services. 44
Domain Events 45
REST & Messaging 46
Domain events become state transitions. 47
Hypermedia for state transition and explicit events. 48
Thanks! 49