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