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 mak 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.