DDD - A Java perspective

Slide 1

Slide 1 text

FREDERIEKE SCHEPER 1 DDD in Practice A JAVA perspective

Slide 2

Slide 2 text

Introduction - Let’s meet • Java Architect & Codesmith ‣ I ❤ OSS conferences! • Contracted by a Dutch ‘Fintech’ company • Passion for ‣ Machine learning ‣ Big Data technologies ‣ Reactive programming • Contact me on (@fbascheper) 2 My shared passion ?

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Today’s talk … Today’s talk … needs a background 4

Slide 5

Slide 5 text

Today’s talk … needs a background • First and foremost : Jakarta Data ❤ DDD ‣ They actually go really well together ‣ For the domain & service layer of a ‘normal’ Java-application • But… as I was preparing this presentation ‣ I started working for another customer ‣ On a “fairly new” application (~ 1 year old) ‣ And it did not have a domain layer ‣ Because it was ‘only’ translating data from one application to another … • This changed my mind … and today’s talk ! 5

Slide 6

Slide 6 text

Slide 7

Slide 7 text

https://commons.wikimedia.org/wiki/File:Q._mark_%28no_edit%29.jpg Let me start with … 7

Slide 8

Slide 8 text

https://commons.wikimedia.org/wiki/File:Q._mark_%28no_edit%29.jpg Let me start with … one question 8 Have you ever worked on an application without a (decent) domain model? BEEN THERE … DONE THAT … 😱 🙋

Slide 9

Slide 9 text

https://www.deviantart.com/mysticrainbowstock/art/Depths-of-Hell-50889361 From the depths of hell … 9 Meet …

Slide 10

Slide 10 text

Insidious problems in development • We are a cost centre, instead of a pro fi t centre ‣ Software development is seen as a nuisance, ‣ Not a source of strategic advantage • We are wrapped up with technologies ‣ We forget concise naming of objects ‣ Wrong abstractions & over-generalisation ‣ Strongly coupled services ‣ The ‘database’ has too much priority 10

Slide 11

Slide 11 text

Slide 12

Slide 12 text

STRATEGIC DESIGN TACTICAL DESIGN Introducing … DDD-concepts 12

Slide 13

Slide 13 text

STRATEGIC DESIGN • Bounded Contexts TACTICAL DESIGN Introducing … DDD-concepts 13 • A semantic contextual boundary, where • Each component inside - Has a speci fi c meaning - And does speci fi c things

Slide 14

Slide 14 text

STRATEGIC DESIGN • Bounded Contexts • Ubiquitous Language TACTICAL DESIGN Introducing … DDD-concepts 14 • A shared language • Used by all team members - Within a bounded context • To facilitate - Collaboration - Mutual understanding

Slide 15

Slide 15 text

STRATEGIC DESIGN • Bounded Contexts • Ubiquitous Language • (Sub) domains - Core domain - Supporting domain(s) - Generic domain(s) TACTICAL DESIGN Introducing … DDD-concepts 15 • Distinct areas within a domain with its own - Business logic - Requirements. • To help organize and manage the complexity of the domain.

Slide 16

Slide 16 text

STRATEGIC DESIGN • Bounded Contexts • Ubiquitous Language • (Sub) domains - Core, supporting and generic • Context maps TACTICAL DESIGN Introducing … DDD-concepts 16 • A visual representation that illustrates - relationships & interactions between Bounded Contexts • Note: - Well-de fi ned interfaces and contracts between BC’s may change over time!

Slide 17

Slide 17 text

STRATEGIC DESIGN • Bounded Contexts • Ubiquitous Language • (Sub) domains - Core, supporting and generic • Context maps TACTICAL DESIGN • Entities and value objects Introducing … DDD-concepts 17 • An entity models an individual thing - Has a unique identity - May be mutable / have state changes • A value object models an immutable conceptual whole over time!

Slide 18

Slide 18 text

STRATEGIC DESIGN • Bounded Contexts • Ubiquitous Language • (Sub) domains - Core, supporting and generic • Context maps TACTICAL DESIGN • Entities and value objects • Aggregates and aggregate roots - Repositories Introducing … DDD-concepts 18 • Aggregates are - Composed of at least one entity - And potentially value objects • Aggregate roots own all elements clustered inside it

Slide 19

Slide 19 text

STRATEGIC DESIGN • Bounded Contexts • Ubiquitous Language • (Sub) domains - Core, supporting and generic • Context maps TACTICAL DESIGN • Entities and value objects • Aggregates and aggregate roots - Repositories • Interfaces and application services Introducing … DDD-concepts 19 • Interfaces de fi ne contracts or boundaries between different parts of the system. • Application services coordinate the use cases and business logic - Act as intermediary between domain layer & user interface

Slide 20

Slide 20 text

STRATEGIC DESIGN • Bounded Contexts • Ubiquitous Language • (Sub) domains - Core, supporting and generic • Context maps TACTICAL DESIGN • Entities and value objects • Aggregates and aggregate roots - Repositories • Interfaces and application services • Domain Events Introducing … DDD-concepts 20 • A domain event is a - Record of a business signi fi cant occurrence in a bounded context • Different origins - Often caused by user command - Or time based - (...)

Slide 21

Slide 21 text

Slide 22

Slide 22 text

How to apply DDD? STRATEGIC DESIGN TACTICAL DESIGN 22 Bounded Context Problem Space Solution Space

Slide 23

Slide 23 text

Steps in Strategic Design 23 1. Understand the Domain and Engage with Domain Experts 2. De fi ne the Core and Supporting Domains 3. Perform Event Storming 4. Identify Bounded Contexts

Slide 24

Slide 24 text

Steps in Strategic Design 24 1. Understand the Domain and Engage with Domain Experts 2. De fi ne the Core and Supporting Domains 3. Perform Event Storming 4. Identify Bounded Contexts

Slide 25

Slide 25 text

https://commons.wikimedia.org/wiki/File:South_facade_of_the_Rijksmuseum_Amsterdam_%28DSCF0528%29.jpg Understanding the domain 25 A museum ! BECAUSE WE ’RE SICK OF PET SHOPS , ETC .. 🙇

Slide 26

Slide 26 text

https://nl.wikipedia.org/wiki/Drents_Museum#/media/Bestand:6J5A0353.jpg Understanding the domain 26

Slide 27

Slide 27 text

https://nl.wikipedia.org/wiki/Drents_Museum#/media/Bestand:6J5A0353.jpg Understanding the domain 27

Slide 28

Slide 28 text

Steps in Strategic Design 28 1. Understand the Domain and Engage with Domain Experts 2. De fi ne the Core and Supporting Domains 3. Perform Event Storming 4. Identify Bounded Contexts

Slide 29

Slide 29 text

Understanding the domain (“museum”) 29 • Entrance • Halls • Corridors • Shop • Cafe • Artworks • Paintings • Sculptures • Drawings • Etches • Potteries • Relics • Coins • On display • Being repaired • In storage • Missing • Stolen Shelves Display cases Vitrines Free-standing Default route Child route ‘See everything’ route • Orders • Order lines • Product • Shopping cart • Payment

Slide 30

Slide 30 text

Understanding the domain (“museum”) 30 What exactly distinguishes a drawing from a sketch 🤔 ⁉

Slide 31

Slide 31 text

Understanding the domain (“museum”) 31 What exactly distinguishes a drawing from a sketch 🤔 ⁉ Or a vitrine from a display case ? 🤔 ⁉

Slide 32

Slide 32 text

Understanding the domain (“museum”) 32 Watch out for homonyms & synonyms ! ⚠

Slide 33

Slide 33 text

Understanding the domain (“museum”) 33

Slide 34

Slide 34 text

Steps in Strategic Design 34 1. Understand the Domain and Engage with Domain Experts 2. De fi ne the Core and Supporting Domains 3. Perform Event Storming 4. Identify Bounded Contexts

Slide 35

Slide 35 text

• Entrance • Halls • Corridors • Shop • Cafe Default route Child route ‘See everything’ route Shelves Display cases Vitrines Free-standing Define core and supporting domains 35 • Artworks • Paintings • Sculptures • Drawings • Etches • Potteries • Relics • Coins • On display • Being repaired • In storage • Missing • Stolen • Orders • Order lines • Product • Shopping cart • Payment

Slide 36

Slide 36 text

• Entrance • Halls • Corridors • Shop • Cafe Default route Child route ‘See everything’ route Shelves Display cases Vitrines Free-standing Define core and supporting domains 36 • Artworks • Paintings • Sculptures • Drawings • Etches • Potteries • Relics • Coins • On display • Being repaired • In storage • Missing • Stolen • Orders • Order lines • Product • Shopping cart • Payment CORE DOMAIN

Slide 37

Slide 37 text

• Entrance • Halls • Corridors • Shop • Cafe Default route Child route ‘See everything’ route Shelves Display cases Vitrines Free-standing Define core and supporting domains 37 • Artworks • Paintings • Sculptures • Drawings • Etches • Potteries • Relics • Coins • On display • Being repaired • In storage • Missing • Stolen • Orders • Order lines • Product • Shopping cart • Payment CORE DOMAIN

Slide 38

Slide 38 text

• Entrance • Halls • Corridors • Shop • Cafe Shelves Display cases Vitrines Free-standing Define core and supporting domains 38 • Artworks • Paintings • Sculptures • Drawings • Etches • Potteries • Relics • Coins • On display • Being repaired • In storage • Missing • Stolen • Orders • Order lines • Product • Shopping cart • Payment CORE DOMAIN GENERIC DOMAIN SUPPORTING DOMAIN Default route Child route ‘See everything’ route SUPPORTING DOMAIN

Slide 39

Slide 39 text

Steps in Strategic Design 39 1. Understand the Domain and Engage with Domain Experts 2. De fi ne the Core and Supporting Domains 3. Perform Event Storming 4. Identify Bounded Contexts

Slide 40

Slide 40 text

https://github.com/ddd-crew/eventstorming-glossary-cheat-sheet/blob/master/_resources/domain-event.png Perform Event Storming 40

Slide 41

Slide 41 text

Perform Event Storming 41 Exhibition Created Exhibition Opened to Public Artwork Moved to Exhibition space Visitor Attended Exhibition Artwork Sent for Restoration Artwork Cataloged Artwork Acquired Artwork Assigned to Exhibition Artwork Appraised Exhibition Closed Artwork Authenticated Visitor Checked In Guided Tour Booked Visitor Left Feedback Visitor Ticket Purchased

Slide 42

Slide 42 text

https://github.com/ddd-crew/eventstorming-glossary-cheat-sheet/blob/master/_resources/process-modelling.PNG https://github.com/ddd-crew/eventstorming-glossary-cheat-sheet/blob/master/_resources/big-picture-tools.jpg Perform Event Storming 42

Slide 43

Slide 43 text

https://github.com/ddd-crew/eventstorming-glossary-cheat-sheet/blob/master/_resources/Software-picture.jpg Perform Event Storming 43 THE SOFTWARE DESIGN PICTURE THAT EXPLAINS “ALMOST” EVERYTHING …

Slide 44

Slide 44 text

https://github.com/ddd-crew/eventstorming-glossary-cheat-sheet/blob/master/_resources/pivotal-events.PNG Perform Event Storming 44 ➡ BOUNDED CONTEXTS !

Slide 45

Slide 45 text

Steps in Strategic Design 45 1. Understand the Domain and Engage with Domain Experts 2. De fi ne the Core and Supporting Domains 3. Perform Event Storming 4. Identify Bounded Contexts

Slide 46

Slide 46 text

Artwork Management Context Artwork Acquired Artwork Appraised Artwork Cataloged Artwork Sent for Restoration Artwork Authenticated Identify Bounded Contexts 46 Purpose: manages the lifecycle and metadata of artworks Pivotal event Marks a transition from acquisition to being part of the managed collection

Slide 47

Slide 47 text

Artwork Management Context Artwork Acquired Artwork Appraised Artwork Cataloged Artwork Sent for Restoration Artwork Authenticated Identify Bounded Contexts 47 Exhibition Management Context Exhibition Created Exhibition Closed Artwork Assigned to Exhibition Artwork Moved to Exhibition Exhibition Opened to Public Handles the creation, scheduling, and logistics of exhibitions Pivotal event Transition from internal planning to public-facing operations.

Slide 48

Slide 48 text

Visitor Experience Context Visitor Attended Exhibition Visitor Left Feedback Guided Tour Booked Visitor Checked In Visitor Ticket Purchased Artwork Management Context Artwork Acquired Artwork Appraised Artwork Cataloged Artwork Sent for Restoration Artwork Authenticated Identify Bounded Contexts 48 Exhibition Management Context Exhibition Created Exhibition Closed Artwork Assigned to Exhibition Artwork Moved to Exhibition Exhibition Opened to Public Purpose: Manages visitor interactions, bookings, and feedback Pivotal event Initiates the visitor journey

Slide 49

Slide 49 text

Visitor Experience Context Visitor Attended Exhibition Visitor Left Feedback Guided Tour Booked Visitor Checked In Visitor Ticket Purchased Artwork Management Context Artwork Acquired Artwork Appraised Artwork Cataloged Artwork Sent for Restoration Artwork Authenticated Identify Bounded Contexts 49 Exhibition Management Context Exhibition Created Exhibition Closed Artwork Assigned to Exhibition Artwork Moved to Exhibition Exhibition Opened to Public High Cohesion & Low Coupling WHERE EVERY BOUNDED CONTEXT HAS ITS OWN SHARED LANGUAGE

Slide 50

Slide 50 text

Visitor Experience Context Visitor Attended Exhibition Visitor Left Feedback Guided Tour Booked Visitor Checked In Visitor Ticket Purchased Artwork Management Context Artwork Acquired Artwork Appraised Artwork Cataloged Artwork Sent for Restoration Artwork Authenticated Identify Bounded Contexts 50 Exhibition Management Context Exhibition Created Exhibition Closed Artwork Assigned to Exhibition Artwork Moved to Exhibition Exhibition Opened to Public

Slide 51

Slide 51 text

STRATEGIC DESIGN TACTICAL DESIGN Solution Space Solution Space Step up to solution space 51 Bounded Contexts Problem Space

Slide 52

Slide 52 text

Bounded Contexts as Micro Services • This is where we’re heading … 52 VISITOR EXPERIENCE EXHIBITION MANAGEMENT ARTWORK MANAGEMENT { } BACK-END

Slide 53

Slide 53 text

Bounded Contexts as Micro Services • This is where we’re heading … 53 ARTWORK MANAGEMENT EXHIBITION MANAGEMENT VISITOR EXPERIENCE VISITOR EXPERIENCE EXHIBITION MANAGEMENT ARTWORK MANAGEMENT { { } } FRONT-END BACK-END

Slide 54

Slide 54 text

Bounded Contexts as Micro Services • Martin Fowler on Micro Frontends: ‣ “An architectural style where independently deliverable frontend applications are composed into a greater whole.” 54 ARTWORK MANAGEMENT EXHIBITION MANAGEMENT VISITOR EXPERIENCE VISITOR EXPERIENCE EXHIBITION MANAGEMENT ARTWORK MANAGEMENT { { } } FRONT-END BACK-END

Slide 55

Slide 55 text

DDD - The Java perspective • We are a cost centre, instead of a pro fi t centre ‣ Software development is seen as a nuisance, ‣ Not a source of strategic advantage • We are wrapped up with technologies ‣ We forget concise naming of objects ‣ Wrong abstractions & over-generalisation ‣ Strongly coupled services ‣ The ‘database’ has too much priority 55 We were doing things wrong !

Slide 56

Slide 56 text

Slide 57

Slide 57 text

https://www. fl ickr.com/photos/8058098@N07/2718571627 57 AND NOW WE’RE READY TO DIVE INTO THE CODE! JAKARTA DATA

Slide 58

Slide 58 text

Jakarta Data and DDD ?! • The new Jakarta Data speci fi cations introduce ‣ A new, type-safe programming model for persistence in Java. ‣ Following a Domain-Centric Approach ‣ Instead of the Entity-Centric model from JPA • So, how to leverage the core concepts of tactical DDD-patterns? ‣ Aggregates and Aggregate roots ‣ Bounded Contexts ‣ Anti-Corruption Layer 58

Slide 59

Slide 59 text

Jakarta Data goals • A uni fi ed programming model ‣ Persistence agnostic ‣ Suitable for use with - RDBMS - Non-relational databases • Using a Domain-Centric Approach ‣ Not ‘Entity’ centric (JPA) • Pluggable and Extensible 59

Slide 60

Slide 60 text

Domain centric approach ?! • Remember JPA & traditional Hibernate? ‣ JPA is `Entity` centric ‣ Using EntityManager’s methods: persist(), merge(), remove() • Whereas Jakarta Data’s `Domain centric` approach ‣ Using the Repository pattern - Closely tied to business-entities - Which may be modeled as Aggregates with a Root entity 60

Slide 61

Slide 61 text

Repository characteristics • A ‘repository’ is de fi ned in two potential ways ‣ Either by extending / implementing a built-in supertype ‣ Or by annotating methods of a class - that does not implement Jakarta Data’s built-in supertype • A ‘repository’ is Stateless • A ‘repository’ may support Pagination 61

Slide 62

Slide 62 text

Repository built-in supertypes • The DataRepository interface ‣ The root of all other built-in repository supertype interfaces. ‣ Does not de fi ne any methods by itself • The BasicRepository interface inherits from DataRepository ‣ includes the most common operations applying to a single entity ‣ including save(), delete(), and fi ndById(). • The CrudRepository interface inherits from BasicRepository, ‣ adding insert() and update() methods ‣ corresponding to the Create and Update of the CRUD pattern 62

Slide 63

Slide 63 text

Jakarta Data annotations • (Re)uses various JPA Annotations ‣ @Entity, @Id, @Embedded, (…) • Has a minimal set of its own Annotations ‣ @Repository - @Insert / @Delete / @Update - @Save - @Find ✓@By ✓@OrderBy 63 USED TO DEFINE A REPOSITORY WITHOUT USING THE BUILT-IN SUPERTYPES

Slide 64

Slide 64 text

Jakarta Data pagination • Either Offset-based pagination ‣ Using a fi xed page size ‣ Retrieves date using page number and size • Or Cursor-based pagination ‣ Relies on unique key(s) for an entity ‣ Relative to which it determines the next / prev page 64 NOTE : UNRELATED TO PL/SQL CURSORS (!)

Slide 65

Slide 65 text

https://gist.github.com/yueliu1999/76b3b349da656e5acb1ff3145fd7012e# fi le-show-me-the-code-jpeg 65 Sure thing, because I ❤ it.

Slide 66

Slide 66 text

package com.github.fbascheper.museum.artworkmgmt.domain; import jakarta.persistence.*; import jakarta.validation.constraints.*; @Entity public class Artwork { @Id @Positive(message = "ID Number must be a non-negative integer!") public long id; @Embedded @Valid public Artist artist; @Embedded @Valid public MonetaryAmount value; Using pojo’s as Entities, … 66

Slide 67

Slide 67 text

package com.github.fbascheper.museum.artworkmgmt.domain; import jakarta.persistence.*; import jakarta.validation.constraints.*; import lombok.Builder; import com.github.fbascheper.museum.artworkmgmt.constraints.AcceptedCurrencies; @Builder(toBuilder = true) @Embeddable public record MonetaryAmount( @NotNull @AcceptedCurrencies(allowedValues = { Currency.EUR }) public Currency currency, public BigDecimal amount ) implements Comparable { /* methods omitted */ } } … with records as value types, … 67

Slide 68

Slide 68 text

@Repository public interface Artworks extends DataRepository { @Save Artwork save(@Valid Artwork artwork); List findByArtist(Artist artist); Page findByMonetaryAmount(MonetaryAmount amount, PageRequest pageRequest, Sort... sorts); @Find List sorted(Sort... sorts); @OrderBy(“value") Stream findAll(); void deleteById(long id); } … and a basic repository 68

Slide 69

Slide 69 text

https://sketchplanations.com/if-this-isnt-nice-i-dont-know-what-is 69

Slide 70

Slide 70 text

Wrap-up and take-aways • It’s imperative to take your time for strategic design ‣ Mind the morass of technologies ‣ Be wary of over-abstraction & generalisation • A concise and complete ubiquitous language is elementary ‣ Homonyms should go into different Bounded Contexts ‣ Synonyms should be avoided (use a glossary !) • Involve your domain experts ! • Jakarta Data is awesome 🤩 ‣ But just a technology (!) 70

Slide 71

Slide 71 text

Mind the ‘checklist’ ✔ Q: HOW MANY PEOPLE UNDERSTAND YOUR SYSTEM? • Nobody ? ‣ You’re probably screwed … 😳 • Only one person ? ‣ You’re probably even more screwed … 😱 ‣ (but it’s harder to admit) • A few people are reasonably competent on the whole ‣ ➡ Safer ! • Everybody knows the whole story ‣ ➡ Just Lovely !! 71 😍

Slide 72

Slide 72 text

And my “Call to Action” 72 And become a pro fi t centre ! 💰 Claim one whole day, start Event Storming (with an expert) For everyone involved …

Slide 73

Slide 73 text

http://www.thebluediamondgallery.com/handwriting/q/questions.html 73 @fbascheper.bsky.social

Slide 74

Slide 74 text

https://commons.wikimedia.org/wiki/File:Thank-you-word-cloud.jpg 74