Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
Fundamental Domain-Driven Design for Microservices
Search
Oliver Drotbohm
September 30, 2016
Programming
630
2
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
Fundamental Domain-Driven Design for Microservices
Slides of the talk I gave at JUG Saxony Day 2016.
@springcentral
Oliver Drotbohm
September 30, 2016
More Decks by Oliver Drotbohm
See All by Oliver Drotbohm
What's new in Spring Modulith?
olivergierke
1
370
Domain-centric? Why Hexagonal and Onion Architecture Are Answers to the Wrong Question
olivergierke
4
2.2k
It Takes Two to Tango – Designing Module Interactions in Modulithic Spring Applications
olivergierke
5
860
Bottom-Up Architecture – Bridging the Achitecture Code Gap
olivergierke
4
1.1k
Spring Modulith – A Deep Dive
olivergierke
9
6k
Spring for the Architecturally Curious Developer
olivergierke
5
2k
Spring Boot 3 & Spring Framework 6
olivergierke
4
2.2k
Architecturally-evident Java Applications with jMolecules
olivergierke
9
3.2k
A Deep Dive into Spring Application Events
olivergierke
12
3.6k
Other Decks in Programming
See All in Programming
Compiling a real-world CLI tool to native with Static Hermes
tmikov2023
0
100
ジョジョの世界をXRで再現する
mofurune
0
140
golang-bob.pdf
iwatsukayura
0
110
setup-vp GitLab対応の裏側
naokihaba
0
160
APNsからLive Activityを開始する話
yumnumm
0
160
WebRTC映像をAirPlayに対応させる挑戦.pdf
monolithic_adam
0
350
When benchmarks go bad - what I learned from measuring performance wrong
hollycummins
0
190
設計次第でAIコードの読む量は減らせる / designing-for-code-reading
minodriven
34
16k
CodeRabbitの効果検証と過ごしてみた3ヶ月
armondando
0
200
コードで差別化できない時代の ソフトウェアエンジニアリング / Software Engineering in an Era Where Code Doesn’t Differentiate
kishida
2
130
Augmenting AI with the Power of Jakarta EE
ivargrimstad
0
590
GitHubハンズオン講座 — 実務レベルのチーム開発のフローを身につけよう
junhat6
0
130
Featured
See All Featured
The SEO identity crisis: Don't let AI make you average
varn
0
580
How to Talk to Developers About Accessibility
jct
2
570
The Power of CSS Pseudo Elements
geoffreycrofte
82
6.6k
The AI Search Optimization Roadmap by Aleyda Solis
aleyda
2
6.3k
The AI Revolution Will Not Be Monopolized: How open-source beats economies of scale, even for LLMs
inesmontani
PRO
3
3.8k
Designing for Timeless Needs
cassininazir
1
520
Speed Design
sergeychernyshev
33
2.1k
Conquering PDFs: document understanding beyond plain text
inesmontani
PRO
4
3.2k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
254
22k
Building a Modern Day E-commerce SEO Strategy
aleyda
45
9.2k
New Earth Scene 8
popppiees
4
2.7k
Typedesign – Prime Four
hannesfritz
42
3.2k
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
5
Implementing Domain-Driven Design 6
Value objects 7
Stringly typed code 8 public class Customer { private Long
id; private String firstname, lastname, email; … }
Stringly typed code 9 public class SomeService { public void
createUser(String firstname, String lastname, String email) { … } }
10 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.
11
Still, they’re worth it. 12 See „Power Use of Value
Objects in DDD“ by Dan Bergh Johnsson.
Lombok — putting the spice back into Java. 13
14 @Value public class Customer { UUID id = UUID.randomUUID();
Firstname firstname; Lastname lastname; EmailAddress email; @Value static class EmailAddress { String value; } }
Entities & Aggregates 16
17 Order LineItem Product Invoice Customer Payment Address Email
17 Order LineItem Product Invoice Customer Payment Address Email
Persistence technology VS. Domain model 18
Aggregate = Entity + Repository 19
20 Order LineItem Product Invoice Customer Payment Address Email
Bounded Context 21
Order LineItem Product Invoice Customer Payment Address
23 Shipping Accounting Catalog Orders User Registration
23 Shipping Accounting Catalog Orders User Registration Accounting Payment information
Billing Address Shipping Shipping address Customer Product
Domain-Driven Design & Monoliths 24
Avoid technologies that get in your way. 25
How to enforce context boundaries? 26
What about consistency? 27
References between Bounded Contexts? 28
Domain Events 29
30 Level 0: No events at all
30 Level 0: No events at all Level 1: Explicit
operations
If you’re calling two setters in a row, you’re missing
a concept. 31
32 Level 0: No events at all Level 1: Explicit
operations Level 2: Some operations as events
State transitions become domain events. 33
34 Level 0: No events at all Level 1: Explicit
operations Level 2: Some operations as events Level 3: Event Sourcing
Domain-Driven Design & Microservices 35
Bounded contexts define system boundaries. 36
37 Shipping Accounting Catalog Orders User Registration Accounting Payment information
Billing Address Shipping Shipping address Customer Product
38 Shipping Accounting Catalog Orders User Registration Accounting Shipping
39 Shipping Accounting Catalog Orders User Registration Accounting Shipping HTTP
Messaging
Architecture is less likely to deteriorate as it’s harder to
violate boundaries. 40
Restructuring service boundaries is much harder. 41
Inter-Context communication becomes remote communication. 42
Accept and embrace eventual consistency between services. 43
Domain Events 44
REST & Messaging 45
Domain events become state transitions. 46
Hypermedia for state transition and explicit events. 47
Thanks! 48