New Domain-Driven Design (DDD) Article in The Architecture Journal

26. March 2010

Architecture_Journal_LogoThe  article that Brandon Satrom and I cowrote for The Architecture Journal, Issue 23  has finally been released to the wild. Our article is titled: “Keeping Architectures Relevant: Using Domain-Driven Design and Emergent Architecture to Manage Complexity and Enable Change.”

The overall issue is titled Architecture Modeling and Processes, and also includes articles on topics such as “Modeling in an Agile Context”, “Software Architecture in the Agile Life Cycle” and “UML or DSL: Which Bear is Best?"

Architecture Journal CoverOne thing I should mention is that Figure 2 in our article is intended to be descriptive, rather than prescriptive. This is possibly not clear from the context in the article, and something we realized only after the article was well past the point of making changes in the editorial process.  In some situations there may be several Bounded Contexts within a single Ubiquitous Language, and in others the Ubiquitous Language may be contained within the Bounded Context. This becomes more important as you consider Context Mapping, so I wanted to make sure this is clear.

Brandon and I are very interested in feedback on from our readers, so please post any comments about the article here or on Brandon’s blog. I want to thank Brandon for making writing the article such an enjoyable learning experience.

From the introduction to our article:

Keeping Architectures Relevant: Using Domain-Driven Design and Emergent Architecture to Manage Complexity and Enable Change

Brandon Satrom
Thought Ascent, Inc.

Paul Rayner
Virtual Genius, LLC.

March 2010

Summary: Sustainable and successful software development is all about managing complexity and enabling change. Successful software architects create designs that clearly address both concerns. For businesses that have complex domains, designing with evolution in mind and using techniques from Domain-Driven Design will result in systems whose architectures deliver a strong, sustainable competitive advantage.



The Architecture Journal, Issue 23.

PDF version of Issue 23.

Keeping Architectures Relevant: Using Domain-Driven Design and Emergent Architecture to Manage Complexity and Enable Change.


What is Acceptance Test-Driven Development?

16. March 2010

Acceptance Test-Driven Development (ATDD) employs the approach of specification by example. ATDD is also known as Storytesting or Behavior-Driven Development (BDD).

Instead of talking in abstract terms about what the system will do, the team collaborates to create specific examples that specify what the system should do from the user's perspective. These executable specifications function as acceptance criteria for the user stories the team is developing. The team specifies as concretely as possible what the specification is, and then the developers code enough of the system to make the test pass to satisfy the acceptance criteria for that specification.

Frameworks such as Fit and Cucumber provide the means to embed this kind of collaboration into the development process. As Mugridge and Cunningham point out:

“[ATDD]…tests are a natural way to help develop this ubiquitous language. Such tests provide a comprehensive bridge between discussions of business need and software design. Writing concrete examples as tests explores ways in which to use and evolve the ubiquitous language for expressing business objects, constraints and rules.”

Fit for Developing Software: Framework for Integrated Tests, by Rick Mugridge and Ward Cunningham. (p. 336)

cucumber_logo Cucumber, for example, is such an amazing ATDD tool because it’s so good at mapping stories and acceptance criteria to automated functional tests. Product Owners and BA's write acceptance criteria in natural language. Developers and testers unobtrusively automate tests for them. Anyone on the team can run the tests and see the current state of the system.

Those wanting to learn more about using Cucumber for ATDD can schedule a private training course, or attend our next public course in Denver.

Additional resources on ATDD:


Domain-Driven Design (DDD) Interviews with Eric Evans

10. March 2010


Vladimir Gitlevich is the organizer of the DDD-NYC SIG , and is the site editor and webmaster for DDD Community. What I discovered during my time in NYC two weeks ago is that he is also an accomplished videographer and video producer (it was Vlad that recorded and produced the videos that are part of the course on Day 2). 

056So at the end of Day 3, on Thursday night, I went with Kristian and Eric to Vlad’s apartment where he had a room set up as a video recording studio. We then proceeded to record a series of interviews with Eric about DDD. 054

Firstly, Kristian interviewed me for a little while about what it was like to attend the course as a student. Then he and Eric discussed – among other things – new and interesting developments in the DDD space.

It was then my turn to interview Eric and learn more about the development of the course content over the years and chat with him about some of the things that had impressed and helped me, many of which I have written about in my DDD Immersion blog series. _MG_6693

My hope is that some of what I learnt will benefit others that are working their way through the big blue book, and I have every confidence that Vlad can turn our late-night discussions into tightly-edited video material that both informs and is interesting to watch!

_MG_6686This was a fun diversion. Particularly being right in the middle of a big winter storm with a foot or more of snow having fallen at this time. The slippery taxi ride through the slick, snowy streets back to the hotel is not something I will forget in a hurry (and I’m used to Colorado blizzards).

Look to the DDD community site in the coming weeks and months for announcements.

To Name is to Know and Remember

5. March 2010

Something Anye (one of the other students in our DDD Immersion course) said last week made a big impression on me:

One of the things I've really got hold of here is naming a pattern. It's hard to define it without having a name for it, or having concrete examples.

I think this is a great insight, and I see this idea applying not only to patterns but also to Ubiquitous Language as well. When we are grappling with a complex domain, a creative collaboration with domain experts in defining that Ubiquitous Language requires a careful attention to language and concrete examples, and perhaps a certain playfulness as well.

Try this fun game with someone today, for example, to see how hard this attentiveness to language can be, and to see the power of changing one word in your speech:

Carry on a whole conversation with someone where you try to never use the word “but” – instead try to phrase it every time so you use the word “and.”  As an additional variation, have the other person try to use “but” as much as possible.

It amazes me how this simple exercise can turn negatives into positives (and vice-versa!). One word can make an amazing difference. Language matters.

How many legs does a dog have if you call the tail a leg? Four. Calling a tail a leg doesn't make it a leg. – Abraham Lincoln

What we name a thing matters. How we use words in our daily speech – and especially in our modeling and coding - matters. I am reminded here of a beautiful poem called Words by Dana Gioia:


The world does not need words. It articulates itself
in sunlight, leaves, and shadows. The stones on the path
are no less real for lying uncatalogued and uncounted.
The fluent leaves speak only the dialect of pure being.
The kiss is still fully itself though no words were spoken.

And one word transforms it into something less or other—
illicit, chaste, perfunctory, conjugal, covert.
Even calling it a kiss betrays the fluster of hands
glancing the skin or gripping a shoulder, the slow
arching of neck or knee, the silent touching of tongues.

Yet the stones remain less real to those who cannot
name them, or read the mute syllables graven in silica.
To see a red stone is less than seeing it as jasper—
metamorphic quartz, cousin to the flint the Kiowa
carved as arrowheads. To name is to know and remember.

The sunlight needs no praise piercing the rainclouds,
painting the rocks and leaves with light, then dissolving
each lucent droplet back into the clouds that engendered it.
The daylight needs no praise, and so we praise it always—
greater than ourselves and all the airy words we summon.

from Interrogations at Noon
© 2001 Dana Gioia

Thanks to my friend Ian Colle for making me aware of this poem last year in our Writing for Publication graduate class.

Domain-Driven Design (DDD) Immersion Course – Part #7 (Final)

5. March 2010

This is the end of my DDD Immersion course blog  series. I want again to thank Eric and Kristian for being such wonderful instructors, and the other course attendees (Anye, Francisco and John) for helping make it such a fun experience.   For example, here are Eric and Anye hamming it up in imitation of the many obviously-posed posters of classrooms that were  on display throughout Learning Tree International and in our classroom (like the one below that shows unnaturally happy people with the caption “Participants troubleshooting PC’s”). A big thanks to both of them for being such good sports and not taking themselves too seriously.

Eric and AnyeDue to client commitments, right up until the last minute I wasn’t sure if I would even be able to attend, but was really glad I was able to eventually clear my schedule and make it happen. Not only that, but having my return flight cancelled(!) on Friday evening 016meant I was able to attend much more of the last day’s class than I had thought (Eric & Kristian were very patient with me sitting in class with a headphone trailing out of one ear while I waited on hold for the airline to answer). It was worth the milk-run flight through Milwaukee the next day, plus I got an extra night at The Jane hotel and a sleep in on Saturday morning.

To make it even easier for future NYC-based course, Eric mentioned that Domain Language is adding some accomodation and training venue information to the training page on their website. For those of us not familiar with NYC – without first-hand, local knowledge of subway schedules and rates etc - it sure helps  to have some recommended hotels for the course. Getting to the venue by subway is the way to go - so long as you keep downtown and uptown straight!

One observation on New Yorkers: don’t expect anyone to return a smile…except when they are shovelling snow after a winter storm, then somehow everyone gets a little friendlier.

DDD Immersion Course - Blog Series Summary

Here are links to the entire series.

  • Part One – Introduction. What is DDD? Ubiquituous language? a Model?
  • Part Two – Building-Block patterns (eg. Aggregate. Domain Event. Creative Collaboration etc)
  • Part Three – Strategic design – Bounded Context and context mapping.
  • Part Four – Strategic design (continued) – Core Domain
  • Part Five – More on supple design (Specification pattern). Implementation concerns. Discussion.
  • Part Six – Design and agile.
  • Part Seven – Final. Course takeaways and other thoughts.

Add links in each entry to the next one, and the whole series in the first and last? Put Next [link] at the bottom of each.

Who Should Attend?

Here are some of my thoughts on the people who are likely to get the most out of the course:

  • Developers with a good understanding of OO development, but new to domain modeling. (those who have taken something like ASDE). Developers that have read the DDD book and want to learn from an expert instructor with their peers in a classroom environment.
  • Application/Software/Solution Architects seeking to provide more value as strategic designers.
  • People wanting to know how to do design on an agile project.
  • Those who have perhaps been DDD practitioners for a while, and want to catch up with the latest in DDD (there are a number of new patterns in the course that are not covered in the book) and bring it together into a cohesive whole. Or perhaps need a refresher on core concepts.

Final Takeaways

The centrality of VO’s in the building-block patterns.

  • This emphasis was not obvious to me in the DDD book (I’m sure that’s despite Eric’s best efforts), but it became very clear in the training.  As Eric put it on the course: “Building blocks are not the central emphasis in DDD, but Value Objects are the thing to focus on in the building blocks.”
  • Avoiding getters and setters on Value Objects.
  • Be biased towards making things Value Objects, at least as a default choice.
  • The general lack of language support for immutability.

Supple design.

  • The power of techniques such as closure of operations, and enforcing and testing for immutability in Value Objects, as means of writing safer code and obtaining a more supple design.
  • “You can’t stop a developer from violating the original intention, but make it harder to not respect the original intention/design.” - Eric

Effective DDD strategic techniques for dealing with legacy systems.

  • Creating a “bubble” within an existing Legacy system that functions as a Bounded Context for some quality design work, realizing that it will likely be absorbed back into the Big Ball of Mud at some later point.
  • Anti-corruption layer – I have used this approach with great success in the past, but need to heed Eric’s warnings more about paying attention to only having translation logic in this layer.

Applying context mapping as a starting exercise in my client engagements

  • In laying out a system and understanding what the contexts are and how they relate to each other.
  • In determining how to organize teams, reducing bugs and in finding and enriching the Core Domain.

Greater emphasis in my consulting on strategic design, and become more familiar with the DDD strategic design patterns

  • So I can identify them when I encounter them, and
  • Know how best to work with my clients in improving their design effectiveness.

A better understanding of what a Core Domain is and how to identify it.

  • I also understand the need for a tight boundary around the Core Domain now, and how best to accomplish this based on the strategic design patterns.

The notion that the Core Domain will – and should be – changing over time, and how to deal with this situation.

  • I expect this will be a key concern of mine in future consulting engagements.
  • Up until now it has been more intuitive (plus what I have learnt from other practitioners). However, now I have a much better grasp of how to do about doing design on agile projects.

Agile and design

  • My opinion is that much of what Eric shared here is closely related to the lean idea of fast-flexible-flow.
    • He described an approach in which design ideas are pulled as necessary (JIT) and iterated on.
    • This means allowing time for creative design work to be done in the Core Domain, so that it can be iteratively and incrementally distilled as an intrinsic part of the agile process.

Making mistakes

  • I am currently reading Managing the Design Factory; a lot of what Eric suggested lines up nicely with Reinertson’s description of information theory. 
  • Innovation can only happen when the designers are pushing the boundaries enough for many small mistakes to be found and corrected.

I see more than ever that there need to be more opportunities for DDD practitioners to connect and network.

  • I will try to start up a DDD meetup group in Denver this year
    • This can only happen if I can clear some other commitments off my list.
    • We have some serious DDD practitioners such as Vaughn Vernon and Randy Stafford based here – it would be great to start sharing this knowledge around the community in a more focused way.
  • I’m going to suggest that the next IASA ITARC conference in NYC (in Oct?) have a DDD track.
    • We certainly had enough DDD practitioners there last year, including Eric and Srini.
    • I know things like this have happened in Europe in the past, having a USA-based space for it this year would be great.
  • What about a Denver-based DDD open-space conference in 2011?

I want to help increase the visibility of DDD Immersion course.

  • As I mentioned to Eric, up until I met him at the IASA ITARC conference in NYC last October, I had no idea that this course even existed .
    • I imagine that I am not the only one.
    • It is the best-kept-secret in the DDD community, and more practitioners and novices need to start taking it.
  • This blog series should at least give a window into what attendees can expect on the course.
  • There are currently several certified instructors world-wide, with classes being offered regularly in London, Paris, Stockholm, Oslo, and New York City.
    • The next USA-based course is in NYC during the first week of May.
    • People interested in taking the course can go to the Domain Language training page.
  • I want to bring Eric to Denver later in the year to deliver the course.
    • If you are interested in seeing this happen then please let me know.
    • I am sure that if we can get enough support for a Denver-based session then I can convince Eric to come.

Further Reading:

  • Managers Guided Tour from Domain Language.
  • The DDD patterns summary book (copies given out in the course) from Domain Language. Go to the DDD Community books page for other resources.
  • I have an Architecture Journal article which introduces some ideas from DDD coming out this month. I’ll update this link once it is published

Go back to Part Six – Design and agile.

Domain-Driven Design (DDD) Immersion Course – Part #6

4. March 2010

This section of the course on day 4 covers how to incorporate DDD into agile , which raises the common question of just how should design be done in iterative and incremental development.

DDD Immersion Course - Blog Series Summary

Here are links to the entire series.

  • Part One – Introduction. What is DDD? Ubiquituous language? a Model?
  • Part Two – Building-Block patterns (eg. Aggregate. Domain Event. Creative Collaboration etc)
  • Part Three – Strategic design – Bounded Context and context mapping.
  • Part Four – Strategic design (continued) – Core Domain
  • Part Five – More on supple design (Specification pattern). Implementation concerns. Discussion.
  • Part Six – Design and agile.
  • Part Seven – Final. Course takeaways and other thoughts.

Some (Somewhat lame) Comments Eric Often Hears About Design and Agile:

We should do a nice design, but we just don't have time

This is just a poorly formed thought. It just doesn't make sense.

Modeling and design take extra time, but they pay off in the long run.

Used to believe this, but now rejects it.

Modeling and design is often the quickest path to the goal. But what is your goal?

  • Implement this user story?

    • If this is your goal, design is not going to help you. Design and modeling are hardly ever the path to this goal.

  • Complete a releasable set up stories with an acceptable level of bugs?

  • Deliver a release that the team can continue to extend in the next release?

    • With each successive release you get less and less value, for projects with this kind of goal modeling and design can help and get you to it faster.

  • Deliver a clear and cohesive user experience?

    • If you look at really successful products they usually have a very clear and coherent user experience.

  • Deliver something that advances the business strategy?

    • Some of the choices around ordering the backlog in agile address this, and DDD helps with this goal.

Good goal: Drive a design from a model.

Unfortunately, people often relate this goal to an upfront analysis phase. 

Models are distilled knowledge. At the beginning of a project, you are as ignorant as you can be. Don't lock in that ignorance.074

Favorite Modeling Tools

  • Whiteboard

  • (x)Unit

  • Our mouths and ears

DDD can be undramatic. People perceive modeling as this big thing. Or big tools with UML. DDD is woven in, and is very undramatic. And can fit in easily with the agile cycle.

  • Walking through concrete reference scenarios.

  • Creative collaboration with domain practitioner

  • Refinement of the UL and therefore the model

In agile all too often, and in TDD, we get so focused on the answer, we don't take notice of the things that don't make sense. Typical scrum projects get into trouble because they don't pay attention to modeling.

At this point pay attention to the model so you don't slow down over the next few days. Not months, not releases. But days.

Challenge your assumptions.

Although DDD is very agnostic about process, in practice Eric uses a very particular process with his clients. It starts with knowing when to model. You don't need to model all the time. That type of fine-tuning of the model happens day-in-and-day-out, and doesnt' really challenge any of the assumptions.

Have a model, then challenge that model with a new scenario. In parallel with refining the scenario, we create model ideas. This is also an exploratory process. Not trying to produce production code, but explore design options and risk. Try to find a scenario that really explains the flaw you found, and work through the process again.

Pull useful bits into whatever kinds of documents you might want to create (mine and refine).

This may go for an hour, or you may come back to it days in succession. But you would not typically spend a whole week on it. Maybe if you need to explore a new subdomain or area and kick off some new ideas.

Continue on to  Part Seven – Final. Course takeaways and other thoughts.

Go back to Part Five – More on supple design (Specification pattern). Implementation concerns. Discussion.

Domain-Driven Design (DDD) Immersion Course – Part #5

3. March 2010

On the final day of the course, we reviewed what we had learnt and discussed how best to apply it in our situations. This included detailed discussions around how to deal with common issues such as legacy systems, organizational culture, data persistence, frameworks and tools, and organizational strategy.

DDD Immersion Course - Blog Series Summary

Here are links to the entire series.

  • Part One – Introduction. What is DDD? Ubiquituous language? a Model?
  • Part Two – Building-Block patterns (eg. Aggregate. Domain Event. Creative Collaboration etc)
  • Part Three – Strategic design – Bounded Context and context mapping.
  • Part Four – Strategic design (continued) – Core Domain
  • Part Five – More on supple design (Specification pattern). Implementation concerns. Discussion.
  • Part Six – Design and agile.
  • Part Seven – Final. Course takeaways and other thoughts.

This final review was one of the most valuable parts of the course.

Ubiquitous Language - did not exist before the creative collaboration. It's a product of this collaboration. It is not just what the domain experts speak, though it will resemble that. It's ubiqituous because it is present everywhere in the system.

We were reminded that it’s not a good idea to infer context within software. Therefore, we want to mak069 e the context completely explicit. In the rest of life, the context of things is usually easier to discern. So we don't normally need to do this activity of making context explicit, but in software we have to do this.

What kinds of things mark off the boundary of a bounded context?

  • Physical structure of the software. Usually some demarcation of the subsystem. Some "chunk" of the software designate using that particlar conventions the project uses.
  • Organizational boundaries.The kind of unified context we are talking about where there is one model and one Ubiquitous Language is usually known by one, single team.

When there are uncoordinated people working on the same piece of software things get very expedient and inconsistent. It comes to the point where the state of the software reinforces this. Often by the time they bring in the process and get things worked out, the state of the system is so bad that these principles cannot be applied.

In dealing with a Big Ball of Mud, be mindful of trying to apply DDD.

  • Creating a “bubble” is a possibility. Acknowledge that it won't last long. Build a lightweight Anti-Corruption Layer, but don't build it to last.

  • Maybe a strategy that may have a lasting impact: create a new context separated by an ACL. It's not that much different than the bubble-approach, but by establishing such a strong context and strong organizational support there is an intention there to make this the new development context of that team and have it last a while. You can accomplish a lot in 2 years with a productive team.

3 main elements in DDD

1. Creative collaboration between domain experts and developers

2. Ubiquitous Language

3. Distilling the core domain

  • It's the part of the domain where they want to excel
  • They may not know because no-one knows (not even the CIO)
  • Premised on the assumption that the upper management has formulated a strategy.
  • DDD about how to make good software, and make software that is aligned with the business strategy
  • Tactical DDD needs a clear bounded context, which requires the strategic design.

Two Questions on Whether to Do DDD or Not:

1. Is it worth it?

  • Core Domain
  • Intricacy in the domain in the problem area you are trying to address
  • Need to bring clarity
  • Business is exploring (not software is exploring). If they know what their goal is, but they don't know quite how to accomplish it. Need software development that can explore with them.

Don't have to have all of these things, but have to have at least one or two.

2. Do you have what it takes to make it work? Can you make it work?

  • Clean bounded context
  • Access to domain experts
  • Skilled team
    • You want your internal team focused on the Core Domain because that is where the most valuable, specialized knowledge. You want that core team wading around in that pool of specialized, valuable knowledge.
    • If you outsource, you may get a good piece of software but not that accumulated knowledge.
    • Eric is increasingly comfortable where there are moments where there is high-productivity software, and then that moment passes. Something between 3 months and 3 years is pretty much what you are going to get anyway.

Should have most, if not all, of these things. Some things you do not have to have at the start. For example, a skilled team can work together to make a clean bounded context. And if you have a skilled team and access to domain experts you can introduce an iterative process.

You would never get asked "how do you do DDD without computers?" - but I get asked all the time: "how do you do DDD without access to the domain experts?"

You must obtain access to domain experts, and then establish a real relationship - a collaborative collaboration.


You can't iterate well without a clean bounded context. You are always dealing with the sprawl. When you iterate over something then you can refactor it. – Anye (DDD class student)

Scrum as it is factored pretty much assumes a BBOM. It does not address design. If you are in a BBOM it should be very task-focused. What is the feature you are tyring to create and what is the most expedient way of sticking it on tho the BBOM.

Need to be aware that iteration is not the same as incremental. Realize that a conceptual model is being created. New scenarios are challenging the model, that require changing the design to address the model neatly.

Use symmetry as principle of Supple Design.

A translator should not have business rules in it, any more than a UN translator would avoid translating every dumb thing that the delegate says.

Align technical dependency with conceptual dependency.

Ubiquitous Language Improves a Service Contract

  • Higher-level language to describe and discuss the contract in speech or writing.

  • Higher-level language for code in assertions and tests.

  • Rules defined explicitly in code, rather than implicitly in procedures.

Ubiquitous Language Makes Design More Supple

  • Higher-level language for code in assertions and tests

  • Makes it possible to use rules in more than one place

  • Rules defined explicitly in code and in just one place.

Explicit Rules through Richer Ubiquitous Language

  • Tighter Service Contracts

  • Invariants in Objects and Aggregates

  • Defined states for Entities and Aggregates

Evidence of supple design. All of this flows with the Ubiquitous Language and that is supple. Come up with a scenario that challenges the invariant, can lead to deeper insight. Part of what defines a context is a team. If you don't have that, then you don't have a clean bounded context.

Continue to Part Six – Design and agile.

Go back to Part Four – Strategic design (continued) – Core Domain.

Domain-Driven Design Immersion Course – Part #4

2. March 2010

Ol Core Domain WhiskeyAlong with Context Mapping, the section on distilling the Core Domain on Day 3 was very helpful. So what is this distillation process? And what do we mean by Core Domain. These are questions that got answered in depth in this section of the course.

DDD Immersion Course - Blog Series Summary

Here are links to the entire series.

  • Part One – Introduction. What is DDD? Ubiquituous language? a Model?
  • Part Two – Building-Block patterns (eg. Aggregate. Domain Event. Creative Collaboration etc)
  • Part Three – Strategic design – Bounded Context and context mapping.
  • Part Four – Strategic design (continued) – Core Domain
  • Part Five – More on supple design (Specification pattern). Implementation concerns. Discussion.
  • Part Six – Design and agile.
  • Part Seven – Final. Course takeaways and other thoughts.

Remember in my first course posting I stated that DDD is firstly a set of driving principles and listed the three driving principles of DDD? Here’s a reminder:

DDD - a set of driving principles.

  1. Focus on the core domain.
  2. Explore models in a creative collaboration between domain practitioners and software practitioners.
  3. Speak a Ubiquitous Language with an Explicitly Bounded Context.

This part of the course really helped me understand how to identify the Core Domain for a business, and made me realize how few organizations have actually identified their Core Domain.

Start by asking the following types of questions:

  • What makes your system worth writing?

  • Why not buy it off the shelf?

  • Why not outsource it?

Eric pointed out that this is not just core features , but rather Core Domain. The Core Domain is the company’s competitive advantage. It may be the company’s specialization, or just what the company does better than anyone else. Iit answers the following critical question:

What makes us special?

DDD lays out several strategies for the Core Domain:

  • Put here the best available internal developers/modelers

  • Keep it isolated in a clean, bounded context

This is not the same as the Scrum backlog (which is based on features), but identifying the strategic subdomain.

We are going to really care about design here. We are putting our best people here.This approach leads to a virtuous cycle. Even in the short-term, leads to good results.

Design is never the fastest way to get the story checked off. But that is not your goal, it's to get a set of features that are cohesive and support the businesses goals.

Doing this enables the developers to innovate in this one area, so we can (in the middle-term) find new ways to do this that are better than our competitors. This requires the time to step back from the design and come up with creative ways of improving it, of breaking out of the current design through deeper insights into the model and refining it.

As soon as we frame it as "this pays off in the long run" we have lost. We are not talking about the long run here, we are talking about the ability to innovate.

Make the core as narrow as we can make it.

So the Core Domain:

  • Requires the ability to innovate and optimize. Cannot innovate in a conformist relationship.

  • Changes over time.

This notion of the Core Domain changing over time was something of an epiphany to me. I’m sure it’s in the DDD book (I was too embarressed to ask Eric if it is), but 040somehow I had missed this. In fact, if the Core Domain is not changing over time, then that is a sure sign that the business is not staying competitive in its market and is resting on its laurels instead - which is a strong indicator that the business will not be around for too much longer! The market is too discerning to let such companies survive.

So, depending on the speed of innovation within the company and it’s primary market, the Core Domain last decade, or last year (or last quarter) may not be the same as today’s, which will likely be different a year from now. And this is a good thing. It’s a sign that the business is growing and adapting, trying to innovate and stay competitive – it’s trying to maintain it’s strategic advatange in the marketplace. This is the area of the system where we need to have the most experienced and productive designers, modelers and developers. It just makes sense.

I have never been much of a technophile. I didn’t get into software because I loved (at the time) FORTRAN or C, or even writing code. It was the problem solving and solution design that grabbed me right from the start, and has sustained me over the times when I was sick to death of it all, and tired of trying to keep up with the technology, or fed up with poor management decision-making. Sure, I like learning new things, so I learn C#, NHibernate, NUnit, CC.NET and Ruby, refactoring, and design patterns etc. But all these to me are merely a means to an end. Eric said:

If there is no vision there it is partly our fault. The best developers need to grow up a little and focus on what is important to the business.

This really hit home. How often do we gravitate towards the cool parts of the system and the new, shiney tools and frameworks – at the expense of what the business really needs, which is for us to be innovating on the Core Domain for the success of the business. We must move beyond Resume-Driven Development, and learn our business domains. Tools and coding chops are critically important, but they are not enough.

As we were working through this section, I was thinking about the book Talent is Overrated. The author talks about the kind of environment that fosters creativity and innovation, where people are encouraged to take design risks and (therefore to make mistakes and get it wrong) because that is the way that creativity is loosed and innovation happens. Not only that, but for a development team this requires the organization providing an environment where there is enough “slack time” (time away from the day-to-day feature-delivery, bug fixing,  and regular coding activities etc) to allow this kind of creative process to occur when appropriate.

If you’re fighting fires all the time, it doesn’t leave time to make the Fire Truck faster and more effective at putting fires out, let alone improving the building codes, construction materials and architectures that cause the fires in the first place. Let’s help our organizations succeed by freeing up the best and brightest people to work on the things that will make the most difference both for now and the future.

When you are under constant pressure to deliver, expediency tends to override strategy. And even the best people start making the wrong choices. We plow through bad code, hating ourselves for doing it, when we know there is a better way. We need the freedom to step back, notice the shifts in assumptions that are destroying our model, and invest the time necessary to innovate our way towards a modeling and design breakthrough in the Core Domain for the good of the company.

In terms of Non-Core Strategies, here are some possible options:

  • Generic? Why not buy it off the shelf?

  • Supporting? Why not outsource it?

  • Not intrinsically complex? why not build it with <insert easy tech here>?

The benefits of distilling the core domain is that it allows us to:

  • Focus effort

  • See the forest for the trees

Context Mapping is particularly critical here, because:

Context boundaries are the key to keeping it all well-designed.

Continue to Part Five – More on supple design (Specification pattern). Implementation.

Go back to Part Three – Strategic design – Bounded Context and context mapping.

Domain-Driven Design Immersion Course – Part #3

1. March 2010

By far the most neglected aspect of DDD is Strategic Design. I have found that most people who read the DDD book are captivated by the first section on design and modeling, but start getting bogged down in the details of the building block patterns in the second section. Many people never even making it to the strategic design section of the book in part 4. For this reason, I always encourage people to read the parts in the sequence: 1, 4, 2, 3 – I think the building-block patterns, being tactical in focus, make much more sense in light of the strategic patterns in part 4.

I should reiterate that I’m not going to try to cover everything we talked about in the class, and not even most of it. I am simply mentioning highlights and reflecting on what I experienced and learnt, and how I see these things helping me in future. The quotes below are typically from Eric or the course notes as we worked through the day.

DDD Immersion Course - Blog Series Summary

Here are links to the entire series:

  • Part One – Introduction. What is DDD? Ubiquituous language? a Model?
  • Part Two – Building-Block patterns (eg. Aggregate. Domain Event. Creative Collaboration etc)
  • Part Three – Strategic design – Bounded Context and context mapping.
  • Part Four – Strategic design (continued) – Core Domain
  • Part Five – More on supple design (Specification pattern). Implementation concerns. Discussion.
  • Part Six – Design and agile.
  • Part Seven – Final. Course takeaways and other thoughts.

Day 3 – Strategic Design

The third, penultimate, day was all about strategic design in DDD. Strategic design ultimately provides the vision, context and direction for tactical design (which – as I mentioned - includes the building-block patterns and refactoring the deeper insight sections of the DDD book in part 2 & 3). Without paying attention to strategic design patterns such as Core Domain, Bounded Context, and Context Mapping, a team new to DDD is likely to spend a great deal of effort doing modeling and design poorly and – more importantly - in the wrong places. Doing good work solving the wrong problem is just as much a problem as doing bad work.

051Eric talked about how strategic design is all about aligning the design effort with the business direction and vision, making sure that the most-experienced and most-capable people are working on the areas that are most critical to the competitive advantage, and thus success, of the business. As a class, we discussed how it is natural for developers to gravitate towards the latest technology or framework or tool, but that these are very much secondary concerns compared to making the design of the system best where it is most likely to positively impact the business both now and beyond.

This part of the class showed me how much more effort I need to put into strategic design. I realize now that a number of the struggles I have faced in my past DDD work is exactly because I did not give this area the attention that it deserves. And I think this is understandable, as I mentioned above, because of the sheer volume of new ideas, mindset changes, patterns and skills that have to be developed just to master the tactical aspects of DDD such as the building block patterns and Ubiquitous Language. I spent some time yesterday reflecting on a recent architectural review I did with a client, and decided that I need to perform a context mapping exercise for that system in order to better understand the system and busienss contexts. I see now the value in improving my skills in this area, because of the value that context mapping brings to the design area.

If you look at the Wikipedia entry for Domain-Driven Design, the Strategic Domain-Driven Design section is mentioned first (the diagram there, taken from the book, is very helpful in seeing the bigger picture). I should mention that it is the NYC DDD meetup group that has primarily been the ones working on improving the Wikipedia entry for DDD.

A DDD Play: The Mystery of Peerless Shipping

050Much of day 3 is structured within the framework of a play. A roleplay. With scripts and characters to act out. A mystery play. We really got into the acting and the characters and had a lot of fun with it. If you take the course, I would encourage you to have fun with the roleplay – you will get a lot more out of it (and learn a lot more in the process). 

It wasn’t hard to relate to the situations that the characters found themselves in. What was hard, though, was seeing a way to understand their situations and how DDD might help as we worked through each Act in the play and acted out the parts. We struggled to understand how to get the characters out of the difficult design and organizational situations in which they found themselves. But this is where the discussion with the instructors after each Act really drove the point home.

Eric and Kristian guided us through each of the major strategic design patterns, showed how they applied to each aspect of the system and organization, and enabled us to see the way forward in each 048case. By the time we were done, I felt like I finally had a coherent structure and language for describing and understanding the variety of team and design situations/arrangements, and a proven approach for making improvements where they are likely to do the most good.

Patterns such as Conformist, Anti-Corruption Layer, Customer/Supplier, Share Kernel and (a new one) Partnership enabled us to see where the issues were and know how best to address them. I was familiar with these from reading the DDD book a few times, but it wasn’t until I took the course this week and went through the roleplay with the other students that it finally “clicked” for me. I realize I need to really grok these patterns, and learn to apply them in every client engagement.

We are IT people. We love to abstract and we love to unify. But there are always multiple models.

053One of the tendencies we all have – which is often reflected in the vain pursuit of Enterprise Data Models - is to try to represent all the complex and variagated concepts and data within our organizations as one abstraction. In doing so we reduce the concepts to the lowest common denominator, stripping them of their meaning, significance, and power in the process.  They become emaciated, anemic models that don’t help anyone.

Alternatively, we ignore – at our peril – the many diverse contexts in the business, and thus the different meaning of things between systems and tend to miscommunicate and make subtle, costly and difficult-to-find mistakes when we try to intergrate them. This leads to the type of situation where you request a certain thing from another system expecting one thing, and get smoething with the same name that means something completely different. Which is why Eric says:

In software integration there are no happy surprises.

Language is made up of words, words that represent concepts, and concepts only have a meaning within a specific context. This is where Bounded Context and Context Mapping come in.

In business you will find that there are lots of contexts, and everything is working fine. Whenever shipping people are talking to marketing people about a customer, everyone understands that there are different contexts.

In software we have to make this completely explicit.

Eric said that when he gets involved with a new client, one of the first things he does is draw a context map. This describes what models are being used, and what are the boundaries. Each of these boundaries will typically be a subsystem boundary, or a boundary that a team is particularly working on. He strongly stated that we should not try to invent anything new in the Context Map:

The purpose of a Context Map is to try to reflect the way things are right now.

"Map what is" - we need to constantly be reminding ourselves of this. it feels unnatural to do this, we are problem solvers by nature.








Another important idea here for me was the notion of Upstream/Downstream. We typically use these words to denote data flow, or technical dependencies. But DDD uses them in a very specific way, related more to organizational dependencies, one that helps make sense of the various strategic design patterns in DDD:



Upstream-Downstream (p. 34) - A relationship between 2 groups in which the "upstream" group's actions affect the downstream group, but the actions of the downstream do not affect the upstream (e.g, If 2 cities are along the same river, the upstream city's pollution primarily affects the downstream city)

Continue to Part Four – Strategic design (continued) – Core Domain.

Go back to Part Two – Building-Block patterns (eg. Aggregate. Domain Event. Creative Collaboration etc).

Domain-Driven Design Immersion – Part #2

27. February 2010

New York City has been a great place to do this training course. The training facility is located downtown on the 31st floor 044of a building overlooking Battery Park, Ellis Island and Lady Liberty.

I felt a little intimidated coming all the way to a huge city like NYC, but there really is no good reason for feeling that way. In terms of accomodation, hotels are plentiful, and there are ones catering to every taste and budget.

Transport-wise, it has been fun riding the subway each day from the West Village to 1 Water St (a 7 minute walk from the Jane to the Subway, and then a 15 minute train-ride which drops me right outside the building).

DDD Immersion Course - Blog Series Summary

Here are links to the entire series:

  • Part One – Introduction. What is DDD? Ubiquituous language? a Model?
  • Part Two – Building-Block patterns (eg. Aggregate. Domain Event. Creative Collaboration etc)
  • Part Three – Strategic design – Bounded Context and context mapping.
  • Part Four – Strategic design (continued) – Core Domain
  • Part Five – More on supple design (Specification pattern). Implementation concerns. Discussion.
  • Part Six – Design and agile.
  • Part Seven – Final. Course takeaways and other thoughts.

Day 1 (cont.) & Day 2

On Day 1 and 2 we focused primarily on tactical design considerations, whereas days 3 is concerned with strategic design.

We worked through the regular DDD building-block patterns such as Entity, Value Object, Aggregate and Repository. This was done through a series of case studies, group brainstorming sessions (at flipcharts), and pair coding exercises. The exercises were in Java, but working with the code and using Eclipse and JUnit were not an issue for me and the other .NET developer. These coding exercises were particularly significant for me in terms of understanding Value Object immutability and supple design techniques such as closure of operations.045


  • Transaction boundaries

  • Distribution boundaries

  • Concurrency boundaries

Aggregates are consistency boundaries, and are always internally consistent. Invariants apply at every transaction commit. They may be inconsistent at varies times amongst each other.

Guidelines to 1st-pass aggregate boundaries

  • Meaningful whole

  • "Delete" rule of thumb - similar to the idea of a cascading delete (point out that we generally never actually delete anything - this is just a thought-experiment, helps to clarify it conceptually)

Note that finding Aggregates is not just a technical issue, it also relates to finding meaningful conceptual groupings. Object instance diagrams (as opposed to class diagrams) can be especially helpful in seeing these conceptual groupings.

047 Eric commented that generally the technical people have taught the business people the need for transactional consistency, and that it’s not bad to unlearn this when it comes to inconsistencies across Aggregate boundaries. So we define consistency boundaries (i.e., around each Aggregate), then have some mechanism for updating them asyncronously. However, as the notes above say, things within the boundary must be 100% consistent. This leads to the conclusion that all of an aggregate must be on one node of a network. And, optionally, different aggregates can potentially be on different nodes of the network.

You can't hold a reference to an object in the aggregate root, only to the root. However, the important thing about aggregates is consistency, not so much access. The rules about access are not the fundamental thing.

034The requirement for internal consistency means that we must validate the entire Aggregate at the commit time. Here are some things I thought were really interesting and helpful to me:

Sometimes it may be appropriate to create a separate object to represent an Aggregate. It may have properties such as total and validate. You may need to allow it to have the kind of access that repositories can have (allow database queries). In this case the Aggregate root does not have to have responsibilty to calculate it, but can delegate to a repository to retrieve it instead.

Repository is about an Aggregate, not about an object. This is an important distinction between repositories and DAO's.

Sometimes we tend to underspecify our models. Eg. draw a class diagram and leave it there. Or, alteratively, we may tend to overspecify our models too – where our descriptions of models are actually descriptions of implementations.

 052We really care that the integrity of the aggregate is enforced, and the properties we care about. If you really need to put it somewhere else then at least keep it in the domain. None of the existing frameworks or languages support this very well.

We also covered the Domain Event pattern, which is a newer building-block DDD pattern that Eric has added to DDD since the DDD book was published.

What do we do with domain events?

  • Clearer, more expressive models

  • Architectural options

    • Representing the state of entities

    • Decoupling subsystems with event streams

    • Enabling high-performance system (Greg Young style)

I know I’m neglecting to mention a lot of things here, but you’ll just have to bear with me (oh, and attend the course to fill in the gaps!).

On Day 2 we watched a series of professionally-produced videos of interactions between a domain expert and developers to illustrate various aspects of what it takes to have a creative collaboration between domain experts and the development team. I could really relate to the situations depicted in the videos, and learnt a lot from the discussions.

Continue to Part Three – Strategic design – Bounded Context and context mapping.

Go back to Part One – Introduction. What is DDD? Ubiquituous language? a Model?