Michael Plöd, @bitboss Implementing with the Spring ecosystem DDD

Disclaimer Michael Plöd - innoQ
 @bitboss Most of these ideas do not come from me personally. I have to thank Eric Evans and Vaughn Vernon for all the inspiration and ideas. If you haven’t: go out and get their amazing books!

Feel free to replace developer by architect, team lead, team member or domain expert. Nothing in this talk is a silver bullet.

Bounded Context Spring Spring Core Spring Boot Spring Data Spring Cloud Spring MVC Spring Events Good OO 
 practice Aggregates Entities Value Objects Factories Services Repositories TOPICS I will talk about today

Model your Microservices along business capabilities

Bounded Context Context Map Shared Kernel Customer / 
 Supplier Conformist Anticorruption
 Layer Separate W ays Open / Host 
 Service Published 
 Language STRATEGIC DESIGN helps us with regards to business capabilities

Bounded Context Every sophisticated business (sub-) domain consists of a bunch of Bounded Contexts Each Bounded Context contains a domain model, don’t nest Bounded Contexts The Bounded Context is also a boundary for the meaning of a given model

Example - You at spring.io Reservations Event
 Management Badges spring.io
 Visitor Name Payment Details Address Company Session Registrations Lunch Preferences Name Job Description Twitter Handle

A Bounded Context is the 
 BOUNDARY 
 for the meaning of a model

Don’t Repeat Yourself INSIDE of a Bounded Context

Repeat Yourself BETWEEN several Bounded Contexts

Microservice architectures should be evolvable

Aggregates (Internal) 
 Building Blocks Entities Value Objects Factories Services Repositories TACTICAL DESIGN helps us with regards to evolvability of microservices

Building
 Blocks Entities Entities represent the core business objects of a bounded context’s model Each Entity has a constant identity Each Entity has its own lifecycle Customer Credit Application Shipment

Building
 Blocks Value Objects Value Objects derive their identity from their values Value Objects do not have their own lifecycle, they inherit it from Entities that are referencing them You should always consider value objects for your domain model Color Monetary Amount Customer

Building
 Blocks Is „Customer“ an Entity or 
 a Value Object If an object can be considered an Entity or a Value Object always depends on the (Bounded Context) it resides in. Customer Example: A customer is an entity in a CRM-like microservice but not in a microservice that prints badges, there we are just interested in name, job description and Twitter handle

Your DDD Entity is NOT your JPA Entity

Building
 Blocks Aggregates Do not underestimate the power of the Aggregate

Building
 Blocks Aggregates SelfDisclosure Address RedemptionDetail Loan Customer LoanApplicationForm Aggregates group Entities. The Root Entity is the lead in terms of access to the object graph and lifecycle.

Best Practices for Aggregates Hints Small Prefer small aggregates that usually only contain an Entity and some Value Objects. Consistency Boundaries Take a look which parts of your model must be updated in an atomically consistent manner One TX per Aggregate Aggregates should be updated in separate transations which leads to eventual consistency Reference by Identity Do not implement direct references to other Root Entities. Prefer referencing to Identity Value Objects

Implementing Aggregates

Building
 Blocks Aggregate Example Battery of an electric car Battery Cells Status Charger Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell General Information

Building
 Blocks Aggregate Example Battery of an electric car Think about good a good old OO practice: information hiding Personal opionion: In the advent of POJOs we have unlearned information hiding A blind „Genereate Getters and Setters“ in your IDE is your enemy Battery Cells Status Charger Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell General Information

Building
 Blocks Aggregate Example Battery of an electric car Do we need an external access to the cells? Stuff we want to do from the outside: - Start charging - Get current charge level - Get information about the charging Battery Cells Status Charger Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell General Information

No content

Hints Visibility Use the power of your programming language, private Attributes with public getters and setters are no information hiding. Yes, you can have classes with a package visibility level. Packages Place each aggregate in its own package and work with package level visibility References I prefer Aggregates that do not reference themselves, they are hooked together with a few shared value objects which leads to more decoupling

Applicant Address Account
 Balance Scoring
 Result Scoring Calculations Score Color AgencyResult KoCriteria Warning
 Message Financial
 Situation Incomings Outgoings PersonId Application
 Number

Root Entity directly Explicit Aggregate Class Implementation Options Aggregates

Keep your Aggregates Spring free

Adapter Adapter Adapter Adapter Adapter Adapter Adapter Adapter Web Mobile Cloud Messaging Database Document GraphDB Messaging Core
 
 
 
 Domain

The hexagonal architecture is not your only option and is not suitable for everything „The domain should be the heart of a system“ Hexagonal ➡ For bounded contexts with a lot of logic and calculations ➡ Complex ➡ Many mappings ➡ Good fit for the DDD internal building blocks CRUD ➡ For bounded contexts that just store and read data ➡ Keep it simple ➡ Spring Data Rest may be your friend Query Driven ➡ For bounded contexts that perform complex queries ➡ Mostly based on a read model ➡ Sometimes the „Q“ in distributed CQRS

Communication between Bounded Contexts

Orchestration vs Choreography Building Microservices by Sam Newman, O'Reilly Event Stream Choreography Orchestration

Choreography Credit
 Application Scoring Credit Decision Customer Credit
 Application
 Submitted Event

Credit
 Application
 Submitted Event We can use Domain Events for the communication between Bounded Contexts. This leads us to Event-driven Applications

! Model information about activity in the domain as a series of discrete events.

An event is something 
 that happened in the past t now Event Event Event Event Event

Options for Event Payload Options Full Payload The event carries complete Entitiy-Graphs or Aggregates Mix The event contains data that is usually of interest to many other contexts. For special purposes there is also a URL to a RESTful HTTP Ressource Empty The event is empty or contains only minimal data and is being used to trigger pulling from a feed (eg. Atom) REST URL The event only carries a URL to a RESTful HTTP Ressource

No content

Spring Cloud Stream Broker Very often the de-facto choice for many distributed systems. Typical choices nowadays would be Apache Kafka or RabbitMQ. High degree of decoupling. Internal 
 Event Bus Only JVM internal with synchronous and / or asynchronous options. Highly recommended for building decoupled monoliths. HTTP Feeds REST + Events = Feeds
 
 Often ignored option in which you won’t need a dedicated broker. Spring MVC + Quartz 
 + Rome Spring Application Events

Very useful!

I’m writing a book

Implementing with the Spring ecosystem Michael Plöd
 @bitboss https://github.com/mploed
 https://speakerdeck.com/mploed
 https://leanpub.com/ddd-by-example DDD