Thinking in DDD Improve Your Software Without Being a Guru - - PowerPoint PPT Presentation

▶
thinking in ddd
SMART_READER_LITE
LIVE PREVIEW

Thinking in DDD Improve Your Software Without Being a Guru - - PowerPoint PPT Presentation

Apr 12, 2023 492 likes •1.09k views

Thinking in DDD Improve Your Software Without Being a Guru Domain-Driven Design is a large topic and becoming an expert is a goal that involves years of experience. But DDD provides so many wonderful and powerful ideas that you can learn

slide-1
SLIDE 1

Thinking in DDD

Improve Your Software Without Being a Guru

slide-2
SLIDE 2

Domain-Driven Design is a large topic and becoming an expert is a goal that involves years of experience. But DDD provides so many wonderful – and powerful – ideas that you can learn from and benefit from right away when designing or refactoring software. ​In this half-day workshop, based on extensive real-word experience, you will learn about some of the DDD patterns such as bounded contexts, aggregates, anti-corruption layers as well as the importance of thinking about your database persistence as a cross-cutting concern. You will also gain some insight into modeling domains and learn how to continue questioning your processes until the "aha!" moment arrives to you and your development team. ​With these important tools you can already begin to improve your software design and maintainability as well as your sanity. And with these tools in hand you can continue to explore, practice and be guided by additional techniques that come from Domain-Driven Design.

slide-3
SLIDE 3

Agenda

  • Why DDD?
  • Why wait to be a DDD guru?
  • Planning
  • Learning about the Business Domain
  • Modeling the Domain
  • Understanding where the database fits in to the process
  • Bounded Context: Breaking a big problem into small problems
  • Implementation
  • Using Rich Aggregate Roots to keep objects under control
  • Considering value objects over 1:1 relationships
slide-4
SLIDE 4

Solve Problems

Build Software

Write Code

Understand Client Needs

slide-5
SLIDE 5
slide-6
SLIDE 6

What DDD Has to Offer

History of success with complex projects Principles & patterns to solve difficult problems Clear, testable code that represents the domain Aligns with practices from that come from years of experience

slide-7
SLIDE 7

It’s all about

the

Domain

slide-8
SLIDE 8

Interaction With Domain Experts Model a single Sub-Domain at a time

slide-9
SLIDE 9

Manage Employees Marketing Accounting Purchase Materials Sales Engineering

slide-10
SLIDE 10

Interaction With Domain Experts Model a single Sub-Domain at a time Implementation

  • f

Sub-Domains

slide-11
SLIDE 11

a

Software implementation Modeling Communication Development Process

slide-12
SLIDE 12

Drawbacks of DDD

Time and Effort

Discuss & model the problem with domain expert Isolate domain logic from other parts of application

Learning curve (why you’re watching this course)

New principles New patterns New processes

Only makes sense when there is complexity in the problem

Not just CRUD or data-driven applications Not just technical complexity without business domain complexity

Team or Company Buy-In to DDD

slide-13
SLIDE 13

Software implementation

BOUNDED CONTEXT UBIQUITOUS LANGUAGE AGGREGATES

Modeling Communication

ANTI- CORRUPTION LAYER VALUE OBJECTS

MODEL- DRIVEN DESIGN

ENTITIES

a

slide-14
SLIDE 14

bit.ly/PS-DDD

slide-15
SLIDE 15

2003 2006 2013

2014

slide-16
SLIDE 16

D

is for DOMAIN

slide-17
SLIDE 17

Domain Experts

are your

Partners

from start to finish of project

slide-18
SLIDE 18

Domain Modeling

slide-19
SLIDE 19

But Where Is the Database?

But Where Is the Database?

slide-20
SLIDE 20

Da Data Storage

is not the

Bu Business Problem

slide-21
SLIDE 21

Cross-Cutting Concerns

slide-22
SLIDE 22

DDD Thinking: Divide and Conquer

slide-23
SLIDE 23

Team Exercise

Identify Bounded Contexts for software to manage this business organization What Behaviors are in these contexts?

slide-24
SLIDE 24

Anti-Corruption Layers

Creative Commons http://commons.wikimedia.org/wiki/File:Cosplay_of_superheroes.jpg

slide-25
SLIDE 25
slide-26
SLIDE 26

Bo Bounded Co Context Bo Bounded Co Context Le Legacy Ap App Insulate Bounded Contexts

slide-27
SLIDE 27

ACLs Between Bounded Contexts, Too

slide-28
SLIDE 28

Translate

between

foreign systems’ models & our own

using

Design patterns, e.g. : Façade, Adapter

  • r custom translation classes or services
slide-29
SLIDE 29

Even when the other system is well designed, it is not based on the same model as the client.

—Eric Evans

Domain-Driven Design

And often the other system is not well designed.

slide-30
SLIDE 30

The structure of an Anti-Corruption Layer

Source: Evans, Domain-Driven Design, p. 367

slide-31
SLIDE 31

Bounded Context

“Customer”

public class Customer{ }

“Customer Registers”

private Customer (string Name, Date regDate){} public static Register (string Name, Date regDate){ return new Customer(name,regDate);

slide-32
SLIDE 32

Ubiquitous Language

For a single Bounded Context Used throughout that context, from conversations to code

slide-33
SLIDE 33
slide-34
SLIDE 34

Recognize that a change in the ubiquitous language is a change in the model.

—Eric Evans

slide-35
SLIDE 35

Domain-Driven Design Thinking

slide-36
SLIDE 36

UI Can “Link" Different Bounded Contexts

slide-37
SLIDE 37

Aggregates

Product Component

Product Aggregate

N 1

slide-38
SLIDE 38

AGGREGATES

Ag Aggregates in in the Na Navigation Map

Evans, Domain-Driven Design, p. 65

slide-39
SLIDE 39
slide-40
SLIDE 40

Behaviors

Schedule an appointment for a checkup Note a pet’s weight Request lab work Notify pet owner of vaccinations due Accept a new patient Book a room

Not Attributes

Appointment.Time Pet.Name Owner.Telephone Room.Number

FOCUS ON

slide-41
SLIDE 41

Team Exercise

Select some of the bounded contexts Within that B.C. what entities belong together in an aggregate? What is the aggregate root? Why?

slide-42
SLIDE 42
slide-43
SLIDE 43

Rich

Domain Models

Anemic

Domain Models

slide-44
SLIDE 44

Rich Domain Models over Anemic Types

Rich for DDD Anemic for CRUD

private private

slide-45
SLIDE 45

ENTITIES

Entities in the Navigation Map

Evans, Domain-Driven Design, p. 65

slide-46
SLIDE 46

Entities in the Appointment Scheduling Context

slide-47
SLIDE 47

Relationships

slide-48
SLIDE 48

A bidirectional association means that both objects can be understood only together. When application requirements do not call for traversal in both directions, adding a traversal direction reduces interdependence and simplifies the design.

—Eric Evans

slide-49
SLIDE 49

Start with One-Way Relationships

slide-50
SLIDE 50

Uni-Directional Associations

Doctor Appointment Client Patient Patient Client

slide-51
SLIDE 51

VALUE OBJECTS

slide-52
SLIDE 52

Value Object

ü Measures, quantifies, or describes a thing in the domain. ü Identity is based on composition of values ü Immutable ü Compared using all values ü No side effects

slide-53
SLIDE 53

String: Our Favorite Value Object

C A R T S

“Boots” lives with Pluralsight author, Lars Klint

slide-54
SLIDE 54

Company Worth: $50,000,000

$ 50,000,000

Company (Entity) ID (guid): 9F63CE8D-9F1E-45E0-85AB-C098CC15F8E6 Worth Unit (string): “Canadian Dollar” Worth Amount (decimal): 50000000

Worth (Value Object) Monetary Unit (string) “Canadian Dollar” Amount (decimal): 50000000 Company (Entity) ID (guid): 9F63CE8D-9F1E-45E0-85AB-C098CC15F8E6 Worth{

Source:http://fit.c2.com/wiki.cgi?WholeValue(Ward Cunningham)

? ? ?

slide-55
SLIDE 55

public class DateTimeRange { public DateTimeRange(DateTime start, DateTime end) { Start=start; End=end; } public DateTime Start { get; private set; } public DateTime End { get; private set; } … }

Patient Appointment

10:00 am Jan 4, 2014 – 11:00 am Jan 4, 2014

Staff Meeting

2:00 pm Feb 1, 2014 – 3:15 pm Feb 1, 2014

slide-56
SLIDE 56

It may surprise you to learn that we should strive to model using Value Objects instead of Entities wherever possible. Even when a domain concept must be modeled as an Entity, the Entity’s design should be biased toward serving as a value container rather than a child Entity container.

—Vaughn Vernon

Implementing Domain Driven Design

slide-57
SLIDE 57

Our DateTimeRange Value Object

slide-58
SLIDE 58

Team Exercise

Pick same Bounded Context you used for aggregate root What behaviors need to happen within there Can you justify 1:1 relationships or are they better as value objects? Can you justify bi-directional relationshps or are they better as uni-directional Model some of the methods

slide-59
SLIDE 59

Resources

§ Domain-Driven Design Fundamentals on Pluralsight bit.ly/PS-DDD § All of my Pluralsight courses: pluralsight.com/author/julie-lerman § Domain-Driven Design, Eric Evans amzn.to/1kstiRg § Implementing Domain-Driven Design, Vaughn Vernon amzn.to/1dgYRY3 § Domain Modeling with Entity Framework Scorecard, Jimmy Bogard, bit.ly/1x925bu § Coding for Domain-Driven Design: Tips for Data-Focused Devs (3 Parts)

MSDN Magazine, Aug, Sept& Oct 2013 bit.ly/15xMlDL

§ CQRS Journey from MS Patterns & Practices: bit.ly/cqrsjourney § A Pattern for Sharing Data Across Domain-Driven Design Bounded Contexts (Part 1&2)

MSDN Magazine, Oct & Dec 2014: bit.ly/DataPoints_Dec2014

§ Entity Framework Model Partitioning in Domain-Driven Design Bounded Contexts

TechEd Europe 2014: bit.ly/TEE2014_EFDDD