Domain-Driven Design Community

Domain Driven Design Final Session
Chapter 16 + Chapter 17
February 3, 2004
Guest author: Eric Evans

Russ: p. 442, "large-scale structure can save a project?"

Eric: Yes, but the read the rest of the sentence -- "... an ill-fitting structure can severely hamper a project." Throughout this chapter I express skepticism about the large-scale structure, and point out how it's less important than some of the other concepts in this book. Say the model context issues in Chapter 14. And you desperately need to distill out the part of the system that gives you the most value. And refactoring toward deeper insight, those things in Part III, that's what really rewards your use of a model. And you really need to bind the application and model together using the techniques of Part II. ANd you need to cultivate a ubiquitous language. So now we come to Chapter 16, and large-scale structure. And it is less important than any of those things.

Eric: It's better to have no large-scale structure than one that doesn't fit.

Azad: I came into a project rather late. There were clear layers in place, and there wasn't much to be done about the large-scale structure at that point. If you have 100 people working on it, there's not much scope for change.

Eric: 100 people can certainly decide to stop honoring the layers, the software structure.

Dave: But getting consensus for change is very, very, hard.

Eric: If you can't get the key people in a room, you shouldn't be doing trying to pull off strategic design.

Scott: Is the workflow of an application, the overall business process... is that a large-scale structure? I worked on some applications where that became a constraint on the design.

Eric: Yes, I guess that would be. I haven't seen that, but I could believe it as a large-scale structure. Did it help?

Scott: No, it hurt.

David: Often you need a pretty serious crisis to break out of an existing large-scale structure.

Sam: Isn't it easier to start from some large-scale structure and refactor the solution to better meet the needs of a business?

Eric: I do find it easier to move from one structure to another, that's true.

Russ: Sam has an important point here. Is it always true that having some large-scale structure is better starting point for getting to a good structure than having none?

Eric: But clinging to a bad structure...that's not a good idea. When I say it's easier to transform one structure to another, I don't mean just any structure. If it was a structure that was valuable in the past.

Russ: And minimal.

Eric: And minimal. If it was based on a valuable structure, then it provides some useful organization to base a new structure on. If something is unstructured, or badly structured, forced into an unnatural shape, it provides you no guidance, or worse, is misleading.

John B: If you're having large-scale structure problems, those are good problems to have. It means your system has grown to the point where it has a large-scale.

Scott: I had an insight when I was reading this. We were trying to layer our applications -- architecture and infrastructure. On our web server application, the layering was fine. The web application server. Now I can see different ways to structure the domain layer.

Eric: Because you have a distinct domain layer, you can consider developing a strategic design for that part of the system. And probably the web service is a newer system than the others, it's less of a mess.

Russ: In response to Robert's question...how small a system would these issues, large-scale structure -- at what point of smallness would it be meaningless?

Eric: At some level this would degenerate down to a point where there was no distinction between the domain objects and the large-scale structure. Let's think about the XP concept of a System Metaphor. That's a large-scale structure aimed at relatively small systems.

John B: What forces drive you toward a large-scale structure?

Eric: "Developers cannot see the forest for the trees". If you can look at a small system, maybe look at the 10 objects of the system and understand the whole thing, you may not need any other structure. But with 500 objects, it helps having a structure to describe the significant relationships of groups of objects. But if you group things wrongly, it's worse than no structure.

Eric: Nobody seemed to complain about my discussion of the System Metaphor as part of large-scale structure. I was expecting more criticism.

Russ: We had some heated discussions on this in an earlier draft.

Jeff: I'm not convinced that "Firewall" is a developer's metaphor. It doesn't describe the structure and components of what goes into it. Maybe it's a marketecture metaphor, or a network administrator's metaphor.

John B: There was a certain point in the development of firewalls at which the metaphor hit a wall. It used to be that you'd "punch a hole" for port 80, for port 25. Active firewalls no longer match this metaphor of holes, in the same sense. They have to understand the context of a network conversation to allow protocols like File Transfer Protocol to operate.

Russ: I'm trying to learn something about System Metaphor. For the C3 project, it helped them decide how to structure and name their domain objects and methods. Your firewall example does not exactly match up with this usage.

John B: It's not a system metaphor in the XP sense. Maybe a system metaphor for a system of machines on a network.

Eric: When I asked Ward Cunningham about it, this was the example that really gave me that 'aha'. And since its development, the structure of the security products available has been shaped by the metaphor of the firewall.

John B: I've heard Ward use "Raincoat" as an alternate metaphor. I like "Doorman", because it implies some understanding of context.

Scott: The fact that you can have this discussion proves the effectiveness of the metaphor. But I don't understand the applicability to actual application development.

John B: When someone asks me what "System Metaphor", I tell them to forget what they've learned, point them to Eric's book and say, "read Domain-Driven Design".

Russ: The POSA architectural structures are examples of large-scale structure?

Eric: Yes, Pipes and Filters especially.

John B: One of the things that the firewall metaphor implied was "inside" and "outside". "Outside" was dangerous, exposed. "Inside" was protected.

John C: So to get inside, there were Trojan horses.

John B: And since not so much has been done about (nodding to John C) capability-based security, once something bad gets in, it has a free hand.

Eric: (Layers) I'm talking about just the domain layer, as opposed to architectural layering. Organizing the domain layer in terms of broad responsibilities. All of the usual layering rules apply.

Scott: I don't know if you intended this... you went from Responsibility Layering to Knowledge Levels to Pluggable Component Framework. I'm not sure how you would get to a Pluggable Component Framework without perhaps putting the interfaces at the boundaries of Responsibility Layers.

Eric: I don't define a navigation between these distinct large-scale structures.

Scott: But as I was reading your examples... say the Policy layer in Responsibility Layering... I could see how you'd decouple that through an interface and make that a pluggable component.

Eric: In Chapter 17, say Figure 17.3 or 17.4 p. 487, there's a picture of combining these structures with bounded contexts, some of which might span layers. Maybe that is relevant to some of what you're talking about.

Russ: Configuration of a pluggable component -- actually realizing an instance of an application -- is a difficult part of the story. There are a lot of ways to put these things together.

Eric: I wanted to give a picture of how bounded contexts might align with development teams, with layers and components. If you were to take it another step from this point (layers and contexts), you might make it pluggable.

Scott: Figure 16.8, one of the things I find compelling as a developer, is that the layers of objects would be apt to change independently. I appreciate your name of "Responsibility Layers", making that distinction in the summary.

Eric: I do, actually, mean to maintain all the rules of layering, of references only in one direction. I don't want to create any confusion. The concept of layers is simple and valuable in many contexts. Perhaps you mean where I am talking about Knowledge Levels -- they aren't layers. There are references in both directions in Knowledge Levels.

John B: Where did "Cargo Repository" come from and why?

Eric: It replaced a bidirectional association between Customer and Cargo, to support the layering. For a customer to say "I have these cargoes" is to violate the layering.

John B: And why is this a good idea?

Russ: Customers don't really need to know about cargoes, in terms of their responsibilities.

Eric: In this case, what I'm trying to say is that when you impose a large-scale structure, that it will affect how you make detailed design decisions. It helps people understand the system, and causes them to make decisions that will conform to the structure (for better or for worse).

Scott: Either having the line with the layers shown, or carrying that drawing to the next... put a line in 16.5 . When you explain it, it's clear, but I had to think harder when I was studying the diagrams by myself.

John B: Why is the layering between Operations and Capability important?

Eric: It's something you learn from experience as the project goes along. If you are working on a larger system, maybe 500 objects rather than 5, you may find a natural stratification of concepts that give you layers which are useful for design. It can help you make sense of a system you can't otherwise absorb at a glance.

Sam: I kept the 7 +/- 2 rule in my head in the time, as I was working on a growing system. When I started hitting the limit, I applied some organization, by putting in organizing principles to structure the system.

Eric: Yes, you get pressed into these things. You don't seek large-scale structure in a 6-object model. But when you have a 600-object model, you desperately need ways of understanding it as a whole. All the strategic design techniques help with this problem, but the large-scale structure directly addresses it.

Robert: Or when you have the need to distribute the system? Then large-scale application structure can be very important.

Eric: That's a different motivation than what I describe. What I'm talking about here is conceptual organization, being able to understand the domain objects of the application.

Russ: How did the "Knowledge Levels" discussion come across to people?

Sam: That turned out to be the exact pattern I was looking for. I could relate to it, the dead-on solution for what I needed.

Eric: Who's read Analysis Patterns?

(Russ, Tracy have)

Russ: A long time ago. I recall it was more likely to be composition rather than inheritance.

Eric: That is a mistake in the diagrams, those are intended to be object references rather than type derivations. [An aside, urging people to report errata here when they find it.]

Sam: The interaction diagrams really helped make sense of it.

Eric: More trouble than I intended to put people to, to understand. This pattern, and especially this example, was rather late to go into the book. So not as many people looked at the diagram before it went to press.

[...]

Eric: Russ, as you said, minimalism...less is more is a good principle to apply in large-scale structure. If you try to be too comprehensive, it'll just be a dead, suffocating blanket over the whole project.

Russ: p. 481, for a second printing, if you could reword the first paragraph in the refactoring section. It seems to claim that if you have a good understanding of your domain, you could impose the structure in advance.

Eric: If you really understand it in depth, and in the context of your system.

Russ: I was worried that a banking analyst writing a banking system would mistakenly conclude that their deep domain knowledge would let them go ahead and do detailed design up front.

Eric: But if you're on your fourth banking system, you could probably get away with it. I don't think it's so important a point. The point is really, don't do it up front! Don't do it up front! Don't do it up front!

Sam: So, someone who has written 3 systems... I beg to differ. If they were 3 procedural systems. Or 3...

Eric: OK. I'll just repeat "Don't do it up front!"

Eric: Chapter 17 is short, but it's quite important.

Robert: You make the case for not doing these things up front. It all makes sense. But what do you say to managers who need some predictability.

Eric: When I first encountered XP, XP's honesty was refreshing. "We can promise you a date, but not a feature set, though we will promise you that it will do something useful." People need to face facts, to recognize unknowns. You make a plan, you make a prediction perhaps, but your business plan needs to be able to deal with disappointments. What's more, you haven't set up a process in your company that prevents you from taking advantage of opportunities. You can't eliminate all downside risk, but software development projects frequently use methodologies which completely eliminate the upside potential. How's that for a business plan?

John C: Although "lucky accidents" -- features which are easy to develop, by surprise -- sometimes raise issues with the cost to document, train, test, and maintain.

(discussion of diagram on p. 487, related to "anticorruption layer" in Figure 17.4).

John B: So if you have a legacy system straddling two layers, like in 17.4, is that a motivation for the anticorruption layer?

Eric: It adds to the badness [that the legacy system doesn't conform to the large-scale system you want to apply]. It probably wouldn't be the only motivation for the anticorruption layer.

John B: Is 17.6 an example of a HIGHLIGHTED CORE?

Eric: It's actually more a SEGREGATED CORE. I've moved the core code into its own packages. A HIGHLIGHTED CORE might have core classes scattered among a number of packages.

Russ: So there are BOUNDED CONTEXTS and there are RESPONSIBLITY LAYERS. The BOUNDED CONTEXTS are areas between which you need to limit their references and contacts, because you are speaking different languages in these different contexts, and need to negotiate the common terms.

Eric: Yes, these are two orthogonal concepts.

Russ: I'm a little surprised you talk about tight integration within a BOUNDED CONTEXT. What would you call a tightly cohesive group of classes within a context?

Eric: If the clustering is really close, I'd call it a MODULE.

Russ: I really appreciate having the vocabulary for BOUNDED CONTEXT. We did this before we had the terms, and we really had to fumble around, we would say, "let's draw a line around this set of classes here, and this set here."

Eric: I think BOUNDED CONTEXT is my really original contribution in this book. It's something that I think successful teams have worked effectively with for some time, but didn't have a word for. Probably the existing word was "scope", but this is such an overloaded term, and it most often is used at a much smaller scale/finer grain.

Patrick: That'll be your middle name, Eric "BOUNDED CONTEXT" Evans.

(Six Essentials for Strategic Design Decision Making)

Russ: What will you do... what can you do if you have a team that doesn't necessarily feel ready to be generalists, to operate in all the roles you describe?

Eric: All of these are essentials, each of them based on observed lacks in projects in my experience. If you are missing any of these essentials, you can go ahead and develop and produce software, but you will not have effective strategic design.

Scott: (describes a problem with a bi-located development group)

John Brewer: This sounds like a team problem, not really a design problem.

Eric: I agree with John basically. Strategic design does give you some options to help deal with it. The pure design solution would be to separate the two teams' parts of the domain, to create separate BOUNDED CONTEXTS which are related via customer-supplier or other relationships.

Russ: Or sharply defining what's inside and outside the SHARED KERNEL.

Eric: Do you have a UBIQUITOUS LANGUAGE that everyone uses to communicate changes during your daily phone calls? To introduce new terms if necessary? But that requires conversations.

Scott: We capture some of that via code, some via conversation. We have a Wiki, but it's less useful than we'd hoped.

Eric: You may wish to look at p. 37-38 on what makes a design document useful.

Dave: We've effectively used a digital snapshot dropped as a picture onto the project Wiki to keep design documents up to date with little effort.

Russ: Are there cubes? Offices? Shared workspace?

Scott: Both. Mostly people work in the shared space.

John B: Maybe you should spring for two Polycom speaker phones and keep an open phone connection throughout the day, to keep communication going..

Eric: So, for the case of technical framework development, I added one more principle, which I wanted to emphasize: "Don't write frameworks for dummies!"

Russ: Anything you'd like to leave us with?

Eric: from the conclusion, the section called "Looking Forward" [short reading from page 505]. I want to point out that working in the domain layer has significant, interesting technical challenges. There are a hundred little tricks of the trade, and if you master them, you can move into new areas, and you have these tools in hand, you can rapidly learn the new area and create supple, useful models. Domain-driven development is a specific skill that has value, and a discipline that people can learn to be better at. And people should be selecting and hiring for it.

Russ: Then we can bring in some infrastructure geeks...

Eric: Yes, and some electricians to make sure there is good lighting in the workspace.

Eric: The core, the heart of the system is that domain layer. People who know how to create that stuff should be the most valuable people on the project.

John B: I think it's the third big O-O book, after Design Patterns and Refactoring.

Charlie: Maybe the second.

John B: Chronologically speaking.

Eric: I'm curious, I almost wanted to ask for a secret ballot... sometimes when I go to a discussion group, I've had a chance to read the material, sometimes I haven't. To satisfy my curiousity, perhaps if people could write down a percentage of how much of the book they've read.

(Tracy carries Jeff's hat around collecting scraps of paper for Eric to count and satisfy his curiosity on this point)

John B: I wanted to say some good things about p. 479, the AIDS Quilt example. It's a large-scale structure where you're really strict about a few things and very lax about others. It enables the whole thing to work well.

???: But quilt pieces can be anything. I don't see any large-scale design.

Eric: Each piece has to be a precise size, it has to be edged a certain way, and it has to be foldable. It is a minimal set of rules that makes it possible to take all those independently created quilt pieces and fit them together in any arrangement.

<!-- InstanceEndEditable --> <!-- InstanceBeginEditable name="SideBar" -->

Attending:

John Corbett
John Brewer
Dave Smith
Azad Bolour
Darlene Wallach
Ken Scott-Hlebek
Robert Benson
Tim Huske
Wayne Vucenic
Russ Rufer
Charlie Toland
Tracy Bialik
Carol Thistlethwaite
Jeff Miller
Patrick Manion
Walter Vannini
Sam
Scott
Kevin