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?

Stuck in NYC Tonight – No Design/Architecture BOF Trifecta Session Tomorrow

26. February 2010

Due to the snow, my flight tonight was cancelled. After much wrangling, the earliest flight I could get back to Denver is tomorrow night. So I will not be be back in time for tomorrow morning’s session. Disappointing, but nothing I can do.

If you are interested in seeing this session come to light at some other time then please let me know and I will try to make it happen via some other venue.

Domain-Driven Design Immersion Course – Part #1

26. February 2010

Today is the last day of our 4 day DDD Immersion course here in NYC with Eric Evans, the author of the DDD book, and Kristian Nordal, a DDD practitioner and training from Oslo, Norway. A full listing of all upcoming classes is available at Domain Language.

Due to the weather, the class has been small, but this has been – hands down – the best training experience I’ve had. I’m going to be inserting some of my notes, along with a little commentary here and there.

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

The first day was all about introducing the concepts and – like the second day – digging into primarily tactical concerns. We started out by reviewing some basics:

What is Domain-Driven Design?

DDD - a set of driving principles.

  1. Focus on the core domain.
    1. Put here the most effort and the best programmers.
    2. Technology and all else is supporting, used as needed.
    3. Put the supporting things in perspective, realize primary focus is somewhere else.
  2. Explore models in a creative collaboration between domain practitioners and software practitioners.
  3. Speak a Ubiquitous Language with an Explicitly Bounded Context.

It turns out that these principles are really hard to pull off.

DDD - a pattern language.

  • A set of interrelated patterns that have helped teams realize the principles.
  • A vocabulary and conceptual framework for discussing domain modeling and design.

We then talked through a typical system design, discussing the communication and design challenges we typically encounter when the development team does not take modeling, language and the business domain as seriously as they should.

What is a Model?

A system of abstractions that describes selected aspects of a domain and can be used to solve problems related to that domain.

  • System of abstractions - excludes everything that you are not interested in.

  • Selected - such as Mecator projection being useful for deriving compass headings.

  • Used - most important

A model serves a particular use.

  • Not "as realistic as possible"
  • Useful relative to specific domain scenarios

One key insight at this point was Eric’s discussion around specific domain scenarios, and the importance of collecting these early in the process. These domain scenarios use real business data and describe concrete scenarios that are important to the business. They form a good foundation for discussions with the domain experts about how they understand the business to work and what they needexpect the system to do for them.

I saw a lot of parallels here between ATDD/Storytesting and the specific domain scenarios. More on that later though.

What is Ubiqituous Language ?

A language structured around the domain model and used by all team members to connect all the activities of the team with the software.

Not the one language that describes everything.

Context - the setting in which a word or statement appears that determines its meaning.

Much of this is recap from the book, but it still helped crystallize many of these concepts even clearer for me. I could also see that the course materials reflected Eric’s additional 7 years or so of experience in the trenches applying DDD to newer problems and situations.

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

Jane Hotel NYC– A Cosy, Affordable Place to Stay in the West Village

26. February 2010

photo (2)This week, while attending the DDD Immersion course in NYC, I have been staying at The Jane Hotel in the West Village. It would not be for everyone, but it sure suits me just fine.

As this NY Times article points out:

The original 1908 red brick structure was built as a lodging house for seamen, and its residents included some men rescued from the Titanic. Now, having been renovated by the developers Sean MacPherson and Eric Goode, it is one of New York’s most unusual, and economical, lodgings.

photo (1)The rooms are tiny but very cosy, and you share a common bathroom. But at under $100/night with free WiFi, flat-screen TV and a quite street in the West Village, it was just right for me. Here is what the room looks like. Notice the giant mirror on one wall.

The doors to the stairs and corridors have portholes(!). And the corridor reminds me of what you would typically find on a yacht or cruiseliner, not a hotel.

As the NY Times article continues:

…a guest gets the same rooms that the seamen got, a bunk on one side, some storage on the other, and barely enough space to turn around. However, they are fitted out like yacht cabins, with polished wood, as well as flat-screen TVs, WiFi and iPod docking stations. The bath is where it always was: down the hall.







The West Village is very picturesque in places, with beautiful streets that ovoke nostalgic images of horses and carriages and late 19th century life (minus the plastic bag and Jaguar of course). So if you are looking for somewhere a little different that is only a 5 minute walk from the 14th and 8th st subway, in a historic part of town, I can highly recommend it.


Come to my Design/Architecture BOF Session at the Tech Trifecta this Saturday!

25. February 2010

This Saturday is the Rocky Mountain Tech Trifecta. Over 500 [Updated: Julie Yack just informed me we have 630 registered as of this AM!] people are registered for this free (yes, free!) event. Why aren’t you?

If you are attending, then drag yourself out of bed a little earlier and come to my Design/Software Architecture birds of a feather (BOF) session at 7:30am (yes, 7:30am!!!) in room 1535

To sweeten the deal, I will have also have some awesome prizes to give away (books, a JetBrains license, and an Infragistics license)!!!

No excuses here, I will be fresh as a daisy after my late night flight back from NYC tomorrow night. I expect everyone else to be raring to go. Or, at least, to have had enough coffee to get their heart rate up.

If you are interested in agile design and testing, or on an agile project and struggling with how to go about it, then this BOF session is for you. The main focus will be on the different types of testing, how they integrate with our design efforts, and how we get better at making them “play nicely together.” Here is the session information:

Testing the Architecture: Getting design and testing to play nicely together

If we cannot test our systems, then we cannot validate that they function as they should: testability is crucial for the systems we create. We now have a huge variety of options in terms of testing tools and frameworks - ranging from unit test frameworks such as MSTest, NUnit, xUnit and MBUnit, to Automated Test-Driven Development (ATDD) frameworks such as Cucumber and FitNesse. But good design and writing tests are often the first thing to go when the pressure is on. In this session we will discuss the different types of software testing that can be done, the relationship between testing and design, and what types of testing approaches might be appropriate for your situation. Come prepared to share your testing experiences and challenges, and to gain insights on how to build quality in every day.

I will be sharing some of what I have learnt, but this  is primarily a hands-on, interactive session with lots of peer-discussion about your questions and struggles around doing architecture, design and testing in an incremental and iterative process. I hope to see you there!

Free iPad? Caveat Emptor

22. February 2010

Like Joe Hewitt , I am optimistic about the potential for the iPad. And with my interest in iPhone development in .NET, I am looking forward to playing around with iPad-optimized applications later this year.

ipadad-dopey I just got an invitation to obtain a free iPad by becoming a fan of the Apple iPad Research Team on Facebook. Given that the iPad is not publicly available yet and the relentless manner in which scams are propogated, you might want to be wary of these types of offers.

Better yet, for some good laughs read Harry McCracken’s article: Oh No, the “Free iPad” Offers Are Here! (which is where the image on the right was sourced).

Clarifying the “Domain” in Domain-Driven Design (DDD)

8. February 2010

One of the things we noticed, and were quick to correct, in our Keeping Architectures Relevant presentation was some confusion around the way we were using the word “domain.” As we explained, when we use the word “domain” in Domain-Driven Design (DDD) we are referring to the business domain. By this we mean what the business knows and does to serve its customers. This use of “domain” is not unique to DDD, by the way.

The developers are trying to mine the nuggets of business knowledge that “domain experts” or “subject matter experts” (SME’s) have about the business domain. This knowledge is based on the experts’ years of experience “doing the work” of the business.

Sometimes the Product Owner (i.e., person responsible for the success of the software product under development), to use the Scrum terminology, plays the role of domain expert, but in many situations it could just as easily be the sales and marketing staff, or technical people within the business who have a long-term and intimate understanding of how the business works.

Domain experts are the people who understand the in’s and out’s of the business, and to whom the developers typically go when they need to find out what the software should do and how it fits in to what the business needs.

We ran into some problems in the presentation because we also referred to the problem domain and solution domain, right after we had carefully defined domain in the narrower sense of “business domain.” So we took a couple of minutes in the presentation to define our terminology and referred to them as areas of focus, expertise and responsibility for the problem and solution space.

We decided that we also need to revise the final draft of our Architecture Journal article early next week and refer to ‘domain’ exclusively in the more narrow sense above, and instead refer to the “problem space” and “solution space” in the article and future presentations to avoid any confusion.

See the table below for an initial attempt to break down the focus, expertise and areas of responsibility of the domain experts and developers in the problem and solution spaces:


Problem Space

Solution Space

Primary Focus
  • Building the right product
  • Business-facing
  • Building the product right
  • Technical/implementation
  • Knowledge of business capabilities, functions, processes and needs.
  • Knowledge of best way to implement
  • Modeling the domain, and embedding the UL into the domain model.
Areas of Responsibility
  • Providing the terms, usage and definitions for the UL.
  • Specifying, clarifying and verifying the domain model with the developers.
  • Refining the UL with the domain experts
  • Distilling the domain model.
  • Refactoring the domain model to deeper insight.
  • Identifying and implementing bounded contexts for domain models.

These roles are somewhat fluid though, and will vary from team to team and context to context. Is this how it works in your environment?

Keeping Architectures Relevant - ITARC Austin Presentation on Domain-Driven Design (DDD) and Emergent Architecture

6. February 2010

I was privileged to co-present on February 4th with IASA Austin chapter president, Brandon Satrom, at the first ever IASA Austin ITARC conference.  Our presentation was titled “Keeping Architectures Relevant: Using Domain-Driven Design and Emergent Architecture” and was intended to be a helpful introduction to some key ideas in each of these areas, geared particularly towards an audience of software and enterprise architects.

We had a great time, and recieved some very helpful feedback after the session. In particular, we realized that we took more time than expected to explain Ubiquitous Language. There also seemed to be more interest in StoryTesting using Cucumber than I was expecting. We found that we needed to clarify our terminology around how we use the word ‘domain’ (I will blog about this soon).

The presentation was an adaptation of many of the ideas from our forthcoming Architecture Journal article (March 2010 edition). Once the article becomes available online then I’ll post the link.

In the meantime, if you attended our session then please post your comments here. I would love to hear what you thought.