Domain-Driven Design Community

Notes 20 January 2004
Domain Driven Design (VIII)
Guest Author: Eric Evans

Russ: Let's start with Strategic Design (Part IV) -- what do we need it for? How about considering the ways to get in trouble on the extremes. How do you look at a system and understand whether we're doing what Eric's doing, or one of the bad alternatives he discussed. (p. 328, halfway down). The more systems I see, the more surprised I am by the range of systems I see. Some of it's really good, some of it's kind of scary. This was a good way of describing a large class of the problems, so I thought it was a good way of introducing tonight's topic.

(Russ referred to text in second half of second paragraph p. 328, "monolithic" vs. "ad-hoc", avoiding extremes).

Dave: Systems glued together out of lots of pieces are also often full of contradictions, an unresolved argument about the system.

John B: Like Unix command-line tools, having varying views of the world?

Russ: Is it ad-hoc components, or ad-hoc interfaces?

Mike: the alternative being an enterprise-wide bus, a common interface for things to plug into, that tries to be everything to everybody. It's hard to get systematic designs through, because you have many sponsors and many forces.

John B: And you have to actually establish the protocols, how to get things to communicate.

Mike: My company has tried for the system-wide bus, and it seems to address the needs of only a small number of the people who want software.

Russ: The author is talking about more than just the technical breakdown of the system, but about the model, the vision of the system.

Eric: Dave said an interesting thing about small pieces composed together being sort of a dialogue or debate about world views of the system. That is very much about what Chapter 14 is about.

Phil: A middle approach to bridging the extremes is to compose the pieces, then to look at what you have, and refactor the composition into the thing it needs to become.

John B: I see on p. 389, there's a discussion about refactoring to Shared Kernel from Separate Ways,

Eric: Refactoring is the *means* by which you change strategies, rather than the strategy you use.

Phil: Refactoring as using the code to change your ideas, you don't see that as well as refactoring as a mechanism?

John B: Eric has listed all the ways to evolve and change the implementation of the model that he can think of, rather than the actual change of the model as ideas.

Eric: All the ones I wanted to recommend.

Tracy: If I understand, Phil, you're talking about refactoring as a process of understanding.

Phil: Yes, learning, and eventually you get to a global view, a similar result. The code is telling you what the model has to be.

Eric: I'd like to shift rails a bit, I start from a more fundamental premise. I start from an observation that on any large project, with more than 10 people, you will have more than one conception of the domain that the system is based on. More than one conception means more than one domain model, and that will affect choices about design. You can just plunge ahead not realizing that, and not realize when one person's concept was controlling the design and when another person's different concept was. So that's where BOUNDED CONTEXT comes in. You would like to have a sense of which model applies in what part of a larger process. There is sometimes a very clear situation, where you have smaller subsystems worked on by different people, and each can be its own model, its own context. But with a large subsystem, you're more likely to end up with multiple inconsistent views. This chapter is about understanding that there are different points of view, and different ways to describe things, and that becoming aware of these different perspectives is important in dealing with larger systems. The "Blind Men and the Elephant" story would be less interesting if each blind man knew that he had a separate point of view on the same thing. And we want things to be less interesting in this case, with software development. So you want to start out by mapping out the territory as it exists, before making changes. So tactics like CONTINUOUS INTEGRATION support the decision to have a unified model within a single BOUNDED CONTEXT. This sort of CONTINUOUS INTEGRATION is the code, *plus* people consciously synchronizing their concepts with one another through exercise of the UBIQUITOUS LANGUAGE. But there are other successful ways of connecting things.

John B: System model vs. domain model? Most of these patterns, to me, seem like ways to integrate a system rather than a domain.

Eric: Usually people think of system integration as connecting a set of distinct programs. But you could create two systems based on the same domain model. Or you could create a program which was internally split between two domain models. You'd prefer to split your components along the boundary of the variant models. But I've seen components and subsystems (even classes!) with multiple models reflected in their implementation.

John B: Is Extreme Programming's continuous integration a different concept from yours?

Eric: I think it is the same thing. The XPers are exactly correct about continuous integration with a context, within a single model conception. If you need it to interoperate, you need continuous integration of the *code*, and also of the *model*.

John B: They're fumbling that direction with the System Metaphor.

Eric: And co-location.

Phil: And pairing.

Russ: I've seen a single developer with 3 different bounded contexts with name clashes in the same source file.

Eric: Three *unbounded* contexts.

Russ: Intermingled contexts.

Eric: If they had bounded those three, they would have been in good shape since they would have been separate; or more likely they would have unified them to remove the contradictions. But knowing what the practices help you achieve, knowing *why*, allows you to adjust to situations, to know where you are at. And knowing when to stop. You can't CI a whole company, you can't co-locate everyone. And at a certain scale, the overhead of continous integration in a large system becomes too much. So by making a context map, you tell yourself, your teams, where you are making CI work, where you can run XP full-out within a single bounded context, and where you want to establish a boundary.

Russ: There are two very different notions going on here. 1: You and I have different models of a system, with shared understanding of a subsystem, and no assumptions about the non-overlapping parts -- two separate but possibly overlapping models. Vs. 2, if you and I were working on things, and there was an overlap of concepts which were not part of the shared kernel, but were in conflict. It's an interesting distinction to talk about.

Eric: Yes, that's a very instructive example. So in the first case, let's say there *is* a shared set of concepts. What I call SHARED KERNEL. That's both concepts and code.

Russ: So if you were working on the dessert and I were working on the floor wax, we wouldn't have to interact on those distinct parts of the system.

Chris: Until someone comes up with a product which is both dessert and floor wax.

Eric: So in this case, you might subclass the thing we've already got in hand, say for me working on the dessert, I'd say a floor wax is a special kind of dessert, and you with the floor wax, you'd say a dessert is a special kind of floor wax.

John B: Elephant is a subclass of wall, floor, snake, tree, and rope. (p. 379)

Eric: The blind men were lucky, that they were each looking at a single part of a larger system. But with desserts and floor waxes, the systems are more complex. At first we might not have any problem. One way is we can say we go with your model, one way is to go with my model, or one way is to come up with a new model that meets everyone's needs. Let's say we introduce a new abstraction.

John: They're both Sprayables.

Eric: So we've discovered both the dessert topping and the floor wax are sprayables.

Dave: It opens up new product opportunities because you could make something that's a floor wax, dessert topping, and bug spray.

Eric: I think the marketing department would have trouble with that last one.

Jeff: Maybe lip gloss as something in the same unified space as floor wax and dessert toppings.

Russ: How are we making these trade-offs to decide how much of the system should be unified?

Eric: It's not always unification. you might have a system that's grown to the point where integration has become burdensome, so you decide to split things off and go separate ways.

Dave: As things scale, I've never seen it be easy to abstract a core.

Chris: Could you abstract out a framework?

Eric: I'm not talking about a huge company with a "chief architect" someplace dictating to everyone in the company "these are the objects you'll use."

Phil: During the development of J2EE at Sun, different groups had a concept of "qname" that was slightly diffferent. We got everyone in the same room and agreed on a common interface that everyone could use, and we created a JAR with just qname in it that everyone could use.

Eric: That's a Shared Kernel.

Phil: Right, and it's a little thing, not a big one.

Dave: What was the overhead involved in getting all the interested party together in a room to make that decision?

Phil: You have no idea.....

[...]

Eric: The first thing is to have contexts that are bounded. And have a map so you can say, "This thing belongs to this context."

John C (?): What about the tragedy of the commons problem, since the shared parts...?

Eric: But all we're agreeing on is the _boundaries_.

John B: "Good fences make good neighbors."

Jeff: Get that down.

Eric: You want to know, "Am I in my own context, where I can go my separate way, or am I in a shared context where I need to integrate with someone else?"

John C: I'm thinking of a company where there are two products, one of which is a big revenue producer, and another that gets less resources. The one that makes a lot of revenue basically gets to disregard the needs of the other one.

Eric: That sounds like a case for Conformist, because of the power differential.

Eric: I'm not saying the company has some global enterprise-wide context map. I'm just saying for your own project, identify the different contexts there.

Eric: Even in a one-person project, you'll have multiple contexts, like "current understanding", vs. "last years understanding". (The code you wrote last year, but haven't had a chance to refactor to your latest insight.)

???: What about upstream/downstream suppliers where one is stuck with a supplier.

???: "Ball and chain" pattern.

(Mike: discussion of a protocol with a large installed base with messaging to distributed clients -- difficulties with changing the protocol to enrich the service.)

Eric: So your clients have a presumption, a model for what the messages in the protocol mean. And how they handle the messages reflects that model. If they get back a response message in a different format than the one they asked for, then they have to handle that. They have to handle the fact that the variations in the new model are exposed by the new protocol. So what made this hard is that within your context, you changed your domain model, but the other systems at the boundary are related to you via an OPEN HOST SERVICE. The interface expresses a frozen model.

Mike: Because so many groups are connected to it.

Eric: And part of the problem was a change in the model as expressed in the protocol. If you had just made a slight re-arrangement of the same information, it would be no means as difficult. There's a technical dimension to the problem, but there is importantly, a conceptual one. And the conceptual difference is what it makes it hard.

John B: Sounds more like ANTICORRUPTION LAYER rather than OPEN HOST SERVICE.

Mike: We have an invariant API.

John B: If you had an ANTICORRUPTION LAYER, you would be able to fold the new protocol into the old one.

Eric: But let's say he is getting his message data from somewhere else, a legacy system. So what he does is set up an ANTICORRUPTION LAYER to translate the old stuff into the new, enhanced model. But it's the client-facing side, he's got clients who are asking for stuff. There might be a few with ANTICORRUPTION LAYERs because they need to express the concepts of the message internal in unusual ways, but most of them use CONFORMIST, expressing his message stream in the same terms.

Mike: We want to enrich the service without affecting the clients who are not interested in / capable of dealing with the information in the new protocol.

Eric: They've always had Sweet 'N Low before, but you want to give them sugar.

Russ: You can give them more feeds, by establishing a an upstream message feed that you can translate into Sweet N' Low for the old clients, and to Splenda for the new clients. (Arranges two diverging lines of pens and flatware with a pink paper packet in one line of the V, and a yellow one in the other line).

Eric: OK, so I understand you have a TRANSLATION LAYER which takes the new, enriched internal format and emits a message feed in the old format for your established customer base.

Eric: There's a stress point on the OPEN HOST SERVICE pattern. If you have two sets of clients who want different services, it's somewhat difficult. OPEN HOST SERVICE says that everyone gets the same thing, everyone can accept the same protocol. So if your situation is that each customer wants little, extra bits on the service, perhaps you want a bunch of one-off translators, one-off versions for the different groups, to keep the primary protocol simple and clean. Now we end up with more of a classic CUSTOMER-SUPPLIER relationship for the custom parts of the protocol. That frees most of the clients from dealing with the special interfaces, and the individual special needs can be managed without changing anything about the common assumptions.

John B: You have an off-the-rack interface, and then a set of tailor-made ones.

Eric: But you want it recognized that that's what you're doing, that there is a decision process being made.

Chris: The more I'm listening to this is more like a pattern I applied in a system I worked on. In this case, the requester specifies the format. If they didn't specify, you got the old format. If you needed something new, something else offered by the current system, the client would change their format specifier.

Charlie: Do some of the specializations, some of the customizations really belong on the client side?

Eric: If you're using OPEN HOST SERVICE, you need to keep it simple and consistent for you as the maintainer. For variations, you may choose to make a special adaptation, negotiating it one at a time based on company priorities or revenue, etc. If you have a custom protocol that only *one* customer can use, you can change the interface as often as your two groups agree to. Once there are multiple clients of the protocol, it's far, far harder. It's the OPEN HOST SERVICE situation, where the interface is frozen in place.

Darlene: At what point might you go toward a general solution, a new protocol with the space to accommodate a new set of variations? Rather than maintain half a dozen variations on the common protocol?

Russ: Maybe we should define ANTICORRUPTION LAYER, we've used it several times.

(p. 364, ANTICORRUPTION LAYER: picture of the Great Wall of China)

John B: I'm seeing this adapter-service thing, that's a lot like...

Eric: I use the terms TRANSLATION LAYER and ANTICORRUPTION LAYER. An ANTICORRUPTION LAYER is certainly a TRANSLATION LAYER. It's the difference in intent, in posture, that makes the difference. An ANTICORRUPTION LAYER defends your system from having to adapt to a divergent external model. I don't think you could mechanically tell the difference. But it's the difference between a wall and a bridge, almost. A bridge is like a regular TRANSLATION LAYER, where one side is reaching out to the other, or both to each other. An ANTICORRUPTION LAYER is protected, a wall, a moat, and a gate. You don't have an ANTICORRUPTION LAYER separating you from a protocol that you designed.

Russ: Maybe a protocol you designed in the past, that you don't want to work with any more.

Eric: With ANTICORRUPTION LAYER I make stronger statements about why you're doing it. It's that you are protecting your model from the concepts on the other side. The concepts on the other side of the wall will mess you up if you have to try and deal with them.

John B: Not just corrupting data, corrupting your model.

Eric: Your way of thinking. There isn't a functional distinction between the two.

Mike: The OO-SQL translation layer as one example of trying to bridge the gap.

Eric: An ANTICORRUPTION LAYER is one-sided, built by one side to protect itself. Vs. the Chunnel, a cooperative effort by the British and French to bring each other together.

Mike: You could think of an O-R persistence layer as an ANTICORRUPTION LAYER if you have to adapt to an organizational standard which interferes with how you can deal with things.

John C: A Cartesian to radial coordinate translation.

Eric: More like where you have Cartesian coordinates on one side and on the other, a tribal society which describes how to find things by how many days' walk between locations, considering weather conditions, and refers to locations by their historical association. You would want to protect the clean, simple Cartesian model from the complex expression of locations on the other side.

John B: So let's say you have an RDBMS with transaction scripts talking to a database. That's where you might put a translation layer to protect the database?

(some additional discussion of ANTICORRUPTION LAYER vs. TRANSLATION LAYER in different contexts)

Mark: Web pop-up blockers are an ANTICORRUPTION LAYER.

John B: They protect you from the advertisers' protocol.

Eric: By doing complicated gymnastics inside the browser. If you provide a compatible interface to protect your clients from changes, that's being nice.

John B: It's like being CONFORMIST to a layer that keeps squiggling out from under you, you conform to what the ANTICORRUPTION LAYER presents and adapt to the changes inside that layer.

Eric: If the old model is nice and clean, if it isn't a conceptually difficult translation... unless there were no longer a straightforward relationship between the new model and the old model, it's not something where the service is protecting yourself. I don't think that offering a

Russ: Insulation but not anti-corruption.

Eric: But if the old model were a BAD one, incompatible, a messy, complex translation from the current system's model, then perhaps it is an ANTICORRUPTION LAYER on an outward feed.

Tracy: Maybe I can make a point that will help. So let's say the new internal model is the brown sugar. So if the guys that wrote this offer a new interface that's sugar, and doesn't offer the interface of Sweet N' Low, then the client might build an ANTICORRUPTION LAYER to defend themselves from the incompatible new interface.

Russ: So if the motivation is trying to protect your old clients by offering a translation layer to a protocol they want, it's different from...

Eric: Yes, the attitude is different.

John B: It's where there is a meeting of minds (TRANSLATION LAYER) vs. no meeting of minds, a disagreement (ANTICORRUPTION LAYER).

Charlie: The word "corruption" is subjective itself, it depends on point of view.

(some additional discussion of ANTICORRUPTION LAYER to attempt to clarify its usage)

p. 371, SEPARATE WAYS

Phil: I love the picture for SEPARATE WAYS. You see all those team rowboat pictures in those motivational posters. Seeing that picture of that one guy in the rowing shell really captures the feel.

John B: It's like a standalone context, like your earlier discussion of STANDALONE CLASS.

Eric: Yes. But separate contexts may introduce duplication. If you have separate contexts, you can have duplication. But not sharing.

Russ: It's positive danger to share things between contexts.

Eric: Unless you have a SHARED KERNEL.

Mike: Does SHARED KERNEL drive you to use CONTINOUS INTEGRATION? Or another specific process to support the SHARED KERNEL.

Eric: Yes, if you have SHARED KERNEL, you have a process that needs to support it. CONTINUOUS INTEGRATION is an example of one process that could support it, but it's not the only way to do it. Frequent integration, appropriate to its rate of change; having each side supply some test cases, and each side runs all the shared, compiled test cases. I wouldn't recommend in more detail than that, but you do need a process.

John B: So you might have meetings or pow-wows between the teams sharing the SHARED KERNEL, to negotiate the interface changes, where an XP team would just go bam, there the interface changes.

Eric: *Within* a context, you can use full-on continuous integration.

Charlie: Does a SHARED KERNEL tend to be more stable than the rest of the system?

Eric: Sometimes, but not necessarily. Sometimes it has the most change at certain phases of the project, although it has more inertia from the multiple forces depending on it. You've traded away some agility.

John B: You need these patterns in order for XP to work, for changing the system to make it better?

Eric: The assumption that change makes things better is implicit to XP.

Chris: Does the way that XP works, that you surge forward, changing the model, in a couple of different contexts. Does that make integration of two divergent teams' work difficult at a later point? The lack of detailed design documentation?

Phil: Just read the tests?

John B: The tests will get you a long way. All the translations will have to be green-bar preserving.

Russ: That's where you encounter the greatest risk of the tests becoming irrelevant. When the model changes, the tests may be making irrelevant assertions. Incorrect assertions.

John B: The unit tests, yes. Not the acceptance tests. They reflect knowledge of the domain.

Eric: But those acceptance tests contain some assumptions about the model, they exist within a context. If the model changes slightly, what the acceptance tests express may be subtly different.

Jeff: Perhaps if the acceptance tests were expressed in different units, they might be able to be consistent within a larger framework. Say more detailed units of time or money or something. That you could translate the acceptance tests into a common larger perspective, but the new perspective might have lots of holes in the acceptance test coverage.

John B: But how do you do this in the context of a non-XP team? You have a document, maybe, but it doesn't reflect how things really are.

Phil: How things used to be, how things were supposed to be, how we thought the system was going to turn out.

Chris: Even if those two documents were inaccurate, they are marker points to bring up subtle points that people might forget. But they provide a place to start talking, a guide to find out if the two kinds of apples we're trying to merge are really two kinds of apples, rather than apples and something else.

Chris: To the extent you can automate the documentation (TogetherJ was mentioned)

John B: Supple design assertions, what's the invariant for an apple? Those can really help you reveal what the common points of view are between two models.

Russ: Sometimes it's how the actual artifacts of the code relate drives you in a direction. What Phil was saying earlier about refactoring driving you toward better understanding of how things were being used. When the problem is too big to hold in your head.

John B: The problem is not the technical issues so much that there is my model and your model, and clearly my model is better than yours, and there are two sets of (mine, yours) in the room. The difficulties are more sociological than technological.

Russ: But maybe we aren't even at this point. We have to decide whether the models have any correspondences where we can extract some common point of view. Using diagrams, pictures, descriptions, etc, to see if common points of correspondence occur.

Charlie: I was once a "swamp guide" for new hires at my company. There were lots of questions about certain idiosyncrasies in the code which related to evolution in the company's business model without the objects being changed to reflect the new point of view.

John B: The context of "now and then".

Eric: Similar to Mike's issue with the different messaging protocols. He had to deal with the protocol based on "then", and the internal model based on "now", and facing the challenge of how to get more "now" into "then".

p. 388: a diagram grouping the "context" patterns in relationships, from SEPARATE WAYS at one end (need no control of other systems, no communication) to Single BOUNDED CONTEXT (need high control, high communication).

Russ: Even on our small team, we have three different contexts in which there's a "Book" object

Eric: (discussing the diagram) But CONFORMIST has no control and requires high communication. ANTICORRUPTION LAYER is somewhat similar. Then there's a break to a set of patterns which require greater integration, greater control over other systems and more communication about internals... CUSTOMER-SUPPLIER TEAMS, OPEN HOST SERVICE, SHARED KERNELs are partway along toward the single BOUNDED CONTEXT.

Russ: You're really nice to XML on p. 376.

Eric: I wrote that back in the glory days of XML. We're all a little disillusioned these days. I really wanted to talk about XML as a stimulus to create common languages for interchange.

Eric: The E-commerce enthusiasts for XML as the magic bullet are not realizing that the really key thing is the common model. The problem isn't getting to a common syntax. With a common model, you can reach a common syntax fairly easily.

John B: The fact that there's a common syntax, a common way of parsing it did help take some of the syntax and formatting issues out of the way.

Russ: XML helps you with the easy problems, but not the hard ones, the conceptual meaning of the marked up object. Here's a price with a dollar value. But does it include tax? Not? How are you allowed to interpret this value you've been given, <price><value unit="USD">50</value></price> ?

(brief discussion of XML web services design, what might make it supple, will good designs win?)

Eric: p. 378, Notice the UML diagram is more compact than the poem!

Mark: What about the second and fifth guy?

Eric: Oops! Guess that was enough to make the point.

<!-- InstanceEndEditable -->