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

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 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.

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

Solve Problems Understand Client Needs Build Software Write Code

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

It’s all about the Domain

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

Purchase Materials Engineering Sales Accounting Marketing Manage Employees

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

Software implementation a Communication Development Process Modeling

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

Software implementation E NTITIES a A GGREGATES M ODEL - V ALUE D RIVEN O BJECTS D ESIGN Communication U BIQUITOUS L ANGUAGE B OUNDED C ONTEXT Modeling A NTI - C ORRUPTION L AYER

bit.ly/PS-DDD

2013 2006 2003 2014

D is for DOMAIN

Domain Experts are your Partners from start to finish of project

Domain Modeling

But Where Is the Database? But Where Is the Database?

Da Data Storage is not the Bu Business Problem

Cross-Cutting Concerns

DDD Thinking: Divide and Conquer

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

Anti-Corruption Layers Creative Commons http://commons.wikimedia.org/wiki/File:Cosplay_of_superheroes.jpg

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

ACLs Between Bounded Contexts, Too

Translate between foreign systems’ models & our own using Design patterns, e.g. : Façade, Adapter or custom translation classes or services

Even when the other system is well designed, it is not based on the same model as the client. And often the other system is not well designed. — Eric Evans Domain-Driven Design

The structure of an Anti-Corruption Layer Source: Evans, Domain-Driven Design, p. 367

Bounded Context public class Customer{ “Customer” “Customer Registers” private Customer (string Name, Date regDate){} public static Register (string Name, Date regDate){ return new Customer(name,regDate); }

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

Recognize that a change in the ubiquitous language is a change in the model. — Eric Evans

Domain-Driven Design Thinking

UI Can “Link" Different Bounded Contexts

Aggregates Product Aggregate Product 1 N Component

Ag Aggregates in in the Na Navigation Map A GGREGATES Evans, Domain-Driven Design, p. 65

FOCUS ON 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

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?

Rich Domain Anemic Models Domain Models

Rich Domain Models over Anemic Types Anemic for CRUD Rich for DDD private private

Entities in the Navigation Map E NTITIES Evans, Domain-Driven Design, p. 65

Entities in the Appointment Scheduling Context

Relationships

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

Start with One-Way Relationships

Uni-Directional Associations Doctor Patient Appointment Client Patient Client

V ALUE O BJECTS

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

String: Our Favorite Value Object S C A R T “Boots” lives with Pluralsight author, Lars Klint

? 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 Company (Entity) ID (guid): 9F63CE8D-9F1E-45E0-85AB-C098CC15F8E6 Worth { Worth (Value Object) Monetary Unit (string) “Canadian Dollar” Amount (decimal): 50000000 Source:http://fit.c2.com/wiki.cgi?WholeValue(Ward Cunningham)

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 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; } … }

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

Our DateTimeRange Value Object

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

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