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