Principles, Patterns and Practices of Domain-Driven Design
Free!
With Membership
$7.99
Minimum paid price

Principles, Patterns and Practices of Domain-Driven Design

Practical advice for teams implementing the development philosophy of Domain-Driven Design. With code examples in C# .NET.

About the Book

Inspired by the seminal works of Eric Evans (Domain-Driven design) and Greg Young (Events) along with the ground breaking work by software craftsmen such as Martin Fowler, Udi Dahan (NServiceBus) and Ayende (Hibernating Rhinos) you will learn how to leverage the design philosophy Domain-Driven Design. Following hands on, real world practical advice you will see how to apply the principles, practices and patterns of DDD.

Part I The Principles and Practices of Domain-Driven Design

Part I of this book is an introduction to the principles and practices of Domain-Driven Design. It's heavy on the prose and light on the code samples. If you already have a good grounding in the philosophy then you can skip this part and go straight to the code in part II.

  • Chapter 1: The opening section of the book introduces you to the philosophy of DDD. You will learn why DDD is needed when dealing with the creation of large complex systems and how it can help you to avoid an unmanageable code base. Introduction to the philosophy of Domain-Driven Design. The problem of blurred responsibilities in code resulting in the Big Ball of Mud. What Domain-Driven Design is and how it can be used to simplify the development of complex business systems.

  • Chapter 2: Distilling the problem space to reveal what is core. Understanding the importance of identifying the Core, Supporting and Generic Domains in your business.

  • Chapter 3: The importance of the collaboration with Domain Experts to gain domain knowledge is discussed next. Domain knowledge will enable you to understand the most important areas of the application you are creating and where to spend the most time and effort. Collaborating with Domain Experts to gain domain knowledge. Driving development of complex Core Domains with Model Driven Design.

  • Chapter 4: The benefit of creating a shared Ubiquitous Language is then explored. The idea of a shared language is core to DDD and underpins the philosophy.  A language describing the terms and concepts of the domain, which is created by both the development team and the business experts, is vital to aid communication on complex systems. The benefit of creating a shared Ubiquitous Language in order to describe the terms and concepts in the domain.

  • Chapter 5: The Domain Model.

  • Chapter 6: Context. Strategic coding patterns designed to protect the integrity of core parts of the domain are presented after knowledge of the domain is gained along with patterns to aid team working. Protecting the integrity of core parts of the domain.

  • Chapter 7: Context Mapping. Understanding the relationships between different contexts in an application.

  • Chapter 8: Application Architecture. Learn that architectural design patterns such as CQRS, Layered Design, CRUD and Transaction Script should be applied only within a Bounded Context and not holistically to a system.

  • Chapter 9: Common problems. The last section of part I describes when not to use Domain-Driven Design, and why it's just as important as knowing how to implement it. Simple systems require straight forward solutions. The end of this part looks at why applying DDD to simple problems can lead to overdesigned systems and needless complexity. When not to use Domain-Driven Design. 
  • Chapter 10: Getting Started with Domain-Driven Design.

This book is a working draft copy of the Wrox Book Principles, Patterns and Practices of Domain-Driven Design by Scott Millett. Parts II and III are available in the full text.

Part II Strategic Patterns of Domain-Driven Design:  Bounded Context Integration

Part II shows you how to integrate bounded contexts. Details on the options open for architecting Bounded Contexts. Code examples detailing how to integrate with legacy applications. Techniques for communicating across Bounded Contexts.   

  • Chapter 11: Application Composition: Integrating Bounded Contexts
  • Chapter 12: Integrating Via Messaging
  • Chapter 13: Integrating Via An Open Host
  • Chapter 14: Integrating with legacy Contexts

Part II is available in the Wrox Book Principles, Patterns and Practices of Domain-Driven Design by Scott Millett.

Part III  Tactical Patterns of Domain-Driven Design: Building Effective Domain Models

Part III focuses on the implementation of the tactical patterns of Domain-Driven Design and how to create an effective domain model. I show you implementations of the patterns contained within Eric's book along with some best practices to aid you with Model-Driven Design.

  • Chapter 15: Introducing the Domain Model Building Blocks
  • Chapter 16: Entities
  • Chapter 17: Value Objects
  • Chapter 18: Domain Services
  • Chapter 19: Aggregates
  • Chapter 20: Domain Events
  • Chapter 21: Factories
  • Chapter 22: Repositories
  • Chapter 23: Event Sourcing 

Part III is available in the Wrox Book Principles, Patterns and Practices of Domain-Driven Design by Scott Millett.

Part IV  Design Patterns For Effective Applications

Part IV focuses on how to architect bounded contexts from an application view.

  • Chapter 24: Composing Applications
  • Chapter 25: CQRS An Architecture of A Bounded Context
  • Chapter 26: Commands: Application Service Patterns for processing Business Use Cases
  • Chapter 27: Queries: Domain Reporting

Part IV is available in the Wrox Book Principles, Patterns and Practices of Domain-Driven Design by Scott Millett. 

About the Author

Scott Millett
Scott Millett

Scott Millett is an enterprise software architect working in London for Wiggle.co.uk, an e-commerce company specializing in cycle and tri athlete sports. I have been working with .NET since version 1.0 and was awarded the ASP.NET MVP in 2010 and again in 2011. My books:

Table of Contents

    • About The Author
    • Introduction
      • Why You Should Read This Book
      • Who Should Read This Book
      • Domain-Driven Design In A Nutshell
      • The Main Focus
        • The Problem Space
        • The Solution Space
      • How This Book Is Structured
        • The Principles and Practices of Domain-Driven Design
        • Strategic Patterns: Communicating Between Bounded Contexts
        • Tactical Patterns: For Effective Domain Models
      • Other Books On Domain-Driven Design
  • The Principles and Practices of Domain-Driven Design
    • Chapter 1: What is Domain-Driven Design?
      • The Value Of Domain-Driven Design
        • A Focus On Collaboration
        • A Focus On Language
        • A Focus On Building A Model For Core Domains
        • A Focus On Context
        • A Focus On Organization
        • A Focus On The Bigger Picture
        • A Focus On What Is Important
      • A Philosophy
        • Not A Pattern Language
        • Not A Framework
        • Not All About The Code
        • Not A Methodology
      • The Challenges Of Writing Large-Scale Complex Business Software
        • Code without a Common Language
        • No Organization
        • The Ball Of Mud Pattern Stifles Development
        • A Lack Of Focus On The Business
        • Get Me Out Of This Big Ball Of Mud
      • How Domain-Driven Design Can Help?
        • Revealing What Is Important
        • Isolate And Organize Code
        • Model What Is Core
        • System Maintainability
      • A Solution Space Vs A Problem Space
      • The Salient Points
    • Chapter 2: Problem Space: Understanding What Is Important
      • Capturing The Essence Of The Problem
      • Understanding Intent
        • Capturing Requirements With Behaviour-Driven Development
        • Powerful Questions
      • Not All Parts of A Problem Are Equal
      • Dividing Large Problems Into Subdomains
        • Decomposing the domain
        • Seeing the Woods in Spite of the Trees
      • Core Domains
        • Domain Vision Can Reveal What Is Core
        • The Core Domain Doesn’t Always Have to Be Perfect the First Time
        • Consider Your Core Domain A Product Rather Than A Project
      • Generic Domains
      • Supporting Domains
      • Build Subdomains For Replacement Rather Than Reuse
      • Subdomains Exist in the Problem Space
      • The Salient Points
    • Chapter 3: Solution Space: Building A Model through Collaboration, Exploration And Learning
      • What is a Domain Model?
        • The Domain Vs The Domain Model
        • A Domain Model Is A Useful Abstraction on Reality
        • Domain Models Contain Only What Is Relevant
        • Domain Models Are Temporally Useful
      • When To Model
      • How To Model
        • Implement The Model In Code Early And Often
        • Only Model What You Need
      • Knowledge Crunching
      • Collaborating With Domain Experts
        • Domain Experts Vs Stakeholders
        • The Challenges Of Design Without Collaboration
        • Gaining Domain Knowledge Through Collaboration
      • Deeper Understanding For The Business
      • Engaging with Your Domain Experts
      • Patterns For Effective Knowledge Crunching
        • Capture Use Cases of the System
        • Using BDD To Capture Important Domain Scenarios
        • Sketching
        • Class Responsibility Collaboration Cards
        • Defer the Naming of Concepts in Your Model
        • Rapid Prototyping
        • Look at Paper Based Systems
        • Look For Existing Models
        • Event Storming
      • Don’t Stop At The First Good Idea
        • Experiment
      • Challenge Your Model
      • The Salient Points
    • Chapter 4: Solution Space: A Ubiquitous Language To Express The Model
      • Expressing The Model In A Ubiquitous Manner
      • The Importance Of A Ubiquitous Language
        • A Language Will Out Live Your Software
        • The Language Of The Domain Expert
        • Translation Between The Developers and The Domain Expert
      • Collaborating On An Ubiquitous Language
        • Carving Out A Language By Working with Concrete Examples
        • Teach Your Domain Experts to Focus on the Problem and Not Jump to a Solution
        • Patterns For Shaping The Language
      • Focus On The Core Domain
      • BDD and the Ubiquitous Language
      • The Role Of Business Analysts
      • The Salient Points
    • Chapter 5: Solution Space: Patterns To Represent The Domain Model
      • The Domain Layer
      • Domain Model Implementation Patterns
        • The Domain Model Pattern
          • Persistence Ignorance
          • When To Use The Domain Model Pattern
          • When Not To Use The Domain Model Pattern
        • Transaction Script
        • Table Module
        • Active Record
        • Anemic Domain Model
        • Domain Pattern Implementation Matrix
      • Model-Driven Design
        • The Analysis Model
        • The Code Model
        • The Code Model Is The Primary Expression Of The Domain Model
      • The Salient Points
    • Chapter 6: Solution Space: Putting A Model Into A Context
      • Multiple Models At Play
        • Bounded Contexts
        • A Language Tied to a Context
        • A Language Defines The Boundary Of Model
        • Model Boundaries Can Be Based Around Teams
        • A Ubiquitous Language For Each Context
        • Context Game
        • A User Interface Context
      • The Misalignment Between Business Capabilities And Software Contexts
      • Retaining the Integrity of Models Using Bounded Contexts
        • The Challenges of Maintaining a Single Model: Blurred Responsibility
        • The Delimited Applicability Of A Model
        • Isolating A Model
        • Isolating Teams Working On Different Models
        • The Difference Between a Subdomain and a Bounded Context
      • Implementing Bounded Contexts
        • A Bounded Context Can Cover More Than One Subdomain
        • Managing The Size of A Bounded Context
        • Teams and Context
        • Physical Boundaries For Bounded Contexts
        • A Bounded Context Should be Technically Consistent
        • Single Team Should Own A Bounded Context
        • A Bounded Context Can Have More Than One Physical Deployment
        • More Than One Bounded Contexts Can Exist In The Same Physical Deployment
      • Architectural Patterns Apply to Bounded Contexts, Not Systems
      • The Salient Points
    • Chapter 7: Solution Space: Understanding The Relationships Between Models Using Context Mapping
      • A Reality Map
        • The Technical Reality
        • The Organizational Reality
        • Mapping A Relevant Reality
        • X Marks The Spot Of The Core Domain
      • The Strategic Importance Of Context Maps
        • Retaining Integrity
        • The Basis for a Plan Of Action
        • Understanding Ownership and Responsibility
        • Revealing Areas of Confusion In Business Work Flow
        • Identifying Non Technical Obstacles
      • Bounded Contexts Collaborate To Form Products
      • Patterns to Map the Relationships Between Contexts
        • Anti-Corruption Layer
        • Introducing Bounded Contexts into Legacy Code
        • Shared Kernel
        • Open Host Service
        • Publish-Subscribe
        • Published Language
        • Big Ball Of Mud
      • Bounded Context Relationships
        • Customer-Supplier (Upstream/Downstream)
        • Conformist
        • Partnership
        • Separate Ways
      • The Salient Points
    • Chapter 8: Solution Space: Application Architectures To Utilise The Model
      • Application Architecture
        • Separating The Concerns Of Your Application
        • Abstraction From The Complexities Of The Domain
        • A Layered Architecture
        • Dependency Injection
        • The Domain Layer
        • The Application Service Layer
        • The Infrastructural Layers
        • Communication Across Layers
        • Testing In Isolation
        • Don’t Share Data Schema Between Bounded Contexts
        • Application Architectures vs Architectures for Bounded Contexts
      • Application Services
        • Application Logic Vs Domain Logic
        • Defining And Exposing Capabilities
        • Business Use Case Coordination
        • Application Services Represent Use Cases Not CRUD
        • Domain Layer As An Implementation Detail
        • Domain Reporting
        • Read Models Vs Transactional Models
      • Application Clients
      • The Salient Points
    • Chapter 9: Common Problems For Teams Starting Out With Domain-Driven Design
      • Overemphasizing the Importance of Tactical Patterns
        • Using The Same Architecture For All Bounded Contexts
        • Striving For Tactical Pattern Perfection
        • Mistaking The Building Blocks For The Value Of DDD
        • Focusing On Code Rather Than The Principles Of DDD
      • Missing The Real Value Of DDD: Collaboration, Communication and Context
        • Producing A Big Ball Of Mud Due To Underestimating the Importance Of Context
        • Causing Ambiguity And Misinterpretations By Failing To Create A Ubiquitous Language
        • Designing Technical Focused Solutions Due To A Lack Of Collaboration
      • Spending Too Much Time On What’s Not Important
      • Making Simple Problems Complex
        • Applying DDD Principles To A Trivial Domain With little Business Expectation
        • Disregarding CRUD As An Anti-Pattern
        • Creating a Model Devoid of Behaviour
        • Using The Domain Model Pattern For Every Bounded Context
        • Ask Yourself: Is It Worth This Extra Complexity?
      • Underestimating The Cost Of Applying DDD
        • Trying To Succeed Without A Motivated And Focused Team
        • Attempting Collaboration When A Domain Expert Is Not Behind The Project
        • Learning In A Non Iterative Development Methodology
        • Applying DDD To Every Problem
      • Sacrificing Pragmatism For Needless Purity
        • Wasted Effort By Seeking Validation
        • Always Striving For Beautiful Code
        • Domain-Driven Design is About Providing Value
      • The Salient Points
    • Chapter 10: Getting Started
      • Selling Domain-Driven Design
        • Educating Your Team
        • Speaking To Your Business
      • Applying The Principles Of Domain-Driven Design
        • Understand the Vision
        • Capture the Behaviours
          • Decompose The Problem Space
          • Focus On What Is Important
        • Understand The Reality of the Landscape
        • Modeling A Solution
          • All Problems Are Not Created Equal
          • Engaging With An Expert
          • Select a Behavior and Model Around Concrete Scenario
          • Collaborate With The Domain Expert On The Most Interesting Parts
          • Evolve A Ubiquitous Language To Remove Ambiguity
          • Throw Away Your First Model, And Your Second
          • Implement the Model in Code
          • Creating A Domain Model
          • Keep The Solution Simple
          • Carve Out An Area Of Safety
          • Integrate The Model Early and Often
          • Non Technical Refactoring
        • Decompose Your Solution Space
        • Rinse And Repeat
      • Exploration and Experimentation
        • Challenge Your Assumptions
        • Modeling Is A Continuous Activity
        • There Are No Wrong Models
        • Supple Code Aids Discovery
      • Making The Implicit Explicit
        • Tackle Ambiguity
        • Give Things A Name
      • A Problem Solver First, A Technologist Second
        • Don’t Solve All The Problems
      • How Do I Know That I Am Doing It Right?
        • Good Is Good Enough
        • How do you get to carnage hall?
      • The Salient Points
  • Strategic Patterns: Communication Between Bounded Contexts
  • Tactical Patterns For Creating Effective Domain Models

The Leanpub 60 Day 100% Happiness Guarantee

Within 60 days of purchase you can get a 100% refund on any Leanpub purchase, in two clicks.

Now, this is technically risky for us, since you'll have the book or course files either way. But we're so confident in our products and services, and in our authors and readers, that we're happy to offer a full money back guarantee for everything we sell.

You can only find out how good something is by trying it, and because of our 100% money back guarantee there's literally no risk to do so!

So, there's no reason not to click the Add to Cart button, is there?

See full terms...

Earn $8 on a $10 Purchase, and $16 on a $20 Purchase

We pay 80% royalties on purchases of $7.99 or more, and 80% royalties minus a 50 cent flat fee on purchases between $0.99 and $7.98. You earn $8 on a $10 sale, and $16 on a $20 sale. So, if we sell 5000 non-refunded copies of your book for $20, you'll earn $80,000.

(Yes, some authors have already earned much more than that on Leanpub.)

In fact, authors have earnedover $13 millionwriting, publishing and selling on Leanpub.

Learn more about writing on Leanpub

Free Updates. DRM Free.

If you buy a Leanpub book, you get free updates for as long as the author updates the book! Many authors use Leanpub to publish their books in-progress, while they are writing them. All readers get free updates, regardless of when they bought the book or how much they paid (including free).

Most Leanpub books are available in PDF (for computers) and EPUB (for phones, tablets and Kindle). The formats that a book includes are shown at the top right corner of this page.

Finally, Leanpub books don't have any DRM copy-protection nonsense, so you can easily read them on any supported device.

Learn more about Leanpub's ebook formats and where to read them

Write and Publish on Leanpub

You can use Leanpub to easily write, publish and sell in-progress and completed ebooks and online courses!

Leanpub is a powerful platform for serious authors, combining a simple, elegant writing and publishing workflow with a store focused on selling in-progress ebooks.

Leanpub is a magical typewriter for authors: just write in plain text, and to publish your ebook, just click a button. (Or, if you are producing your ebook your own way, you can even upload your own PDF and/or EPUB files and then publish with one click!) It really is that easy.

Learn more about writing on Leanpub

Publish Early, Publish Often

  • Path
  • There are many paths, but the one you're on right now on Leanpub is...
  • › Practicing-ddd

*   *   *

Leanpub is copyright © 2010-2024 Ruboss Technology Corp.
All rights reserved.

This site is protected by reCAPTCHA
and the Google Privacy Policy and Terms of Service apply.