DDD is often misinterpreted in so many ways. Many teams focus only on the tactical patterns, or even consider repositories as mere glorified DAO's and forget about all the other concepts that really matter: the focus on the business domain, modeling in code, and the concept of Bounded Contexts. In this talk for junior and senior developers alike, we'll clarify the few most important building blocks of DDD. We will also illustrate how practicing DDD actually looks like. This talk is the perfect opportunity to get started on DDD on solid grounds!
31. DDD Essentials
Curious about the domain
Talking the Domain Language
Focus on Core Domain
Modeling == Code
Strategic Design
(+ techniques to achieve that)
31
42. Ubiquitous Language
• Naming
•Searchable
•Easy to pronounce
•No abbreviation
• Definitions
•Shared definition
•Understand, not just a vocabulary
h#p://www.visualdicDonaryonline.com/house/structure-house/stairs.php
50. null
DDD style of code?
• No technical pollu5on
• Spring, Hibernate, logger
• javax.*
• SQL
51. [Object Calisthenics]
1. Wrap all primitives and strings
2. Use only one dot per line
3. Don’t abbreviate
4. Keep all classes small
5. Don’t use any classes with more
than two instance variables
6. Use first-class collections
7. Don’t use any getters/setters/
properties
114. Bounded Contexts
Explicitly define the context within which a model
applies. Explicitly set boundaries in terms of team
organization, usage within specific parts of the
application, and physical manifestations such as code
bases and database schemas. Keep the model strictly
consistent within these bounds, but don’t be distracted
or confused by issues outside.
115. Bounded Contexts
Explicitly define the context within which a model
applies. Explicitly set boundaries in terms of team
organization, usage within specific parts of the
application, and physical manifestations such as code
bases and database schemas. Keep the model strictly
consistent within these bounds, but don’t be distracted
or confused by issues outside.
Example
PLZ!
156. What is a book at Amazon?
•Catalog: Picture, title, authors, rating, format
(ebook or paper), category
•Recommandation: List of books often bought
together with it
•Shipping: Dimensions, weight, international
restrictions due to content
•Shopping cart: Price, discount eligible
•Customer review: List of (rating, review,
review rating)
•Book Search: title, isbn, authors
•Search Inside!: full-text content, copyright-
dealing policy
162. Team organization
•Catalog: Team 1
•Recommandation: Team 2
•Shipping: Team 3
•Shopping cart: Team 4
•Customer review: Team 5
•Book Search: Team 6
•Search Inside!: Team 7
184. WHY microservices?
INDEPENDENT Work Streams
GRANULAR Independent Deployments
Plus recent history has proven we don’t
have the DECOUPLING discipline
FAULT-isolation
188. Microservices in practice
Each microservice has its own private logical ”database”:
CREATE DATABASE microservicename;
Microservices expose API’s and consume other services
http / REST / Json
Most microservices are built on a Microservice Chassis
Spring Boot / Spring Cloud Suite
191. Production-ready Microservices
Each service exposes health checks & metrics
/health
/metrics
/info
(built-in Spring Boot Actuator)
Each service produces semlogs used by monitoring
ELK + Worker
Each service is instrumented for distributed tracing
ZIPKIN (Sleuth)
194. WHY Event-Driven
Architecture?
DISTRIBUTE data across services for fast
Eventual Consistency
TEMPORAL Decoupling between services
(reduced failure area)
Events Senders and Receivers DON’T
KNOW each other (Decoupling)
195. Event-Driven Architecture in practice
One event bus with one shared topic
RabbitMQ
Everyone Broadcasts to Everyone
Exchange type: Fanout (or Headers)
Choreography over Orchestration
No central coordinator, control is
decentralized
199. Event Sourcing: a
persistence style
(events as private schema)
Event-Driven Architecture:
an integration style
(events as published contracts)
Can change whenever I want
Can never change once used
200. Contracts are forever!
Robustness rules
• MUST_IGNORE events & fields
you don’t know
• NEVER_REMOVE an existing
field or event
• ALWAYS_ADD new fields for
changes
protobuf, avro Consumer-Driven
Contracts
201. Which language in the events?
B
ACL
B
Events
A
Events
See: DDD /Context Mapping