TechEd North America 2014, Houston
How You Can Architect and Develop Enterprise Mission-Critical Applications with Domain-Driven Design and .NET – Vaughn Vernon

Day 2, 13 May 2014, 1:30PM-2:45PM (DEV-B326)

Disclaimer: This post contains my own thoughts and notes based on attending TechEd North America 2014 presentations. Some content maps directly to what was originally presented. Other content is paraphrased or represents my own thoughts and opinions and should not be construed as reflecting the opinion of either Microsoft, the presenters or the speakers.

Executive Summary—Sean’s takeaways

• Basic explanation of domain-driven design
  • Breaking model into sub-parts to reduce complexity
  • Each part in a different context, possibly using different language to talk about its elements
• Presented at a very high subjective level, typical of academic papers about domain modeling
• Nothing concrete presented
• Nothing relating to doing data or domain modeling in .NET presented

Full video

Vaughn Vernon

http://www.Idddworkshop.com

vvernon@shiftmethod.com
@VaughnVernon
http://VaughnVernon.co

Overview

• Why enterprise apps need DDD
• Mental Model – Domain experts and ubiquitous language
• Strategic Design First, Tactical Modeling Second
  • Aggregate

SCRUM-based application management

• Product, BacklogItem, Release, Sprint
• BacklogItem has Task, which has EstimationLogEntry
• Release – ScheduledBacklogItem
• Sprint – CommittedBacklogItem

Additional items in DDD application lifecycle model

• Forums, Discussions
• Calendars
• Tenants, Users
• Account info, etc.
• Team has structure, product owner, members, etc.

What are we really modeling here?

• Time management, project management?
• What is core?
• Story of architects with huge UML diagram
  • Do you really need knowledge of this in order to develop enterprise software?
• Easier way?
  • Yes, DDD
  • DDD isn’t necessarily easy
  • But DDD gives you tools to help you divide and conquer

Goal – Avoid hugely complex model

This Is DDD

• Ubiquitous Language – describing elements relationship
• Bounded Context – sets boundaries for what you model
  • How does it map to what I do every day?
  • Bounded context is just—everything you need for your application
  • Think of Visual Studio solution as the bounded context. (But avoid creating dozens of projects)
  • Think of it as – what doesn’t belong?
• Insight bounded context, we are modeling single ubiquitous language

Linking contexts

• Object in Bounded Context might be single rectangle that just references a different bounded context

The gap

• Between business analyst and developer
• Analyst has a very different idea of what the application is about

Main goal of DDD

• Unify mental models
• We use ubiquitous language to allow business analyst to talk to developer

Business Value

• Story of customer where key domain expert wouldn’t attend the meeting
• Asked the guy to just sit there for 30 minutes
• Guy has “a-ha” moment, realizing need for DDD

Is It a Language?

• Developers naturally draw boxes and lines and call it a language
• Volunteer—describe your day only using nouns
  • We could make sense of this
• But language is far more than that
• Example sentence for SCRUM, e.g. “Backlog item will be committed to a Spring”
• But quickly, we think of other constraints—who does something, etc.

Back to original drawing of Model, pick core Domain (subset of entities)

• Pick subset of domain that makes sense

DDD Rule: Use Bounded Context to separate models by language

SaaSOvation

• Fictional company, developing an agile project management product

Tenant and Multi-Tenancy

Early problem – too many connections

• User and Permission connects to everything
• Developers would say—move access management outside the bounding context
• Key—the language doesn’t match
  • E.g. For Forum, talking about Moderators, Authors – not User and Permission

Bounded Contexts

• Show original schema now broken up into bounding contexts
• Users/Roles not in core context
• Can think of having a different Visual Studio solution for each bounded contexts
• And domain model in each

Brown-field development

• Legacy system
• “It’s just a lot of brown” – what a silly thing to say
• Glimmer of hope, green is growing, next to the brown – ok, that was even sillier

Abstract and Encapsulate

• Brown is spread between the green rows
• Brown is in the barn over there, away from the green crops – yikes

Context Mapping

• How does core context get its notion of entities in other contexts
• It does “context mapping”
• Several different context mapping approaches
  • E.g. Anti-corruption layer

Architecture diagram

• Ports and adapters
• Domain model at core, Application around it
• Adapters on the outside
• Ports are interfaces to outside entities
• Adapters allow data to be brought in or out

Code snippet showing saveCustomer function and critique

• This is not object-oriented
• “This is a huge problem”

Second code snippet, more object-oriented

• Reorganized code, with separate properties
• These methods (maybe) better fit the domain logic

Aggregates

• Aggregate is a special kind of entity