25-Nov-2003
Domain Driven Design (Evans) II.
Notes by Jeff Miller

This meeting revisits the final published form of a book that SVP reviewed
in an earlier draft two years ago.

(some comments and questions unattributed)

(notes start with discussion in progress)

(previous to this point, Eric compared and contrasted model-driven
design with domain-driven design)

Eric: It depends on whether you demand that the classes in your model

have meaning in the domain.

Russ: “bits of responsibililty”

Eric: It matters that the classes in the model… The reason some
models give you that kick is that they are are close to the domain.

Robert: Is it easier to refactor the model, classes and objects, than

services?

Russ: Let me do a quick check here. “Most talented developers don’t

have much interest in learning about the specific domain in which they

are working” ? (p.4) How true is that?

Robert: Probably, let’s say, at Sun Microsystems, your domain is
technical stuff you’re doing for someone else.

Eric: That’s cheating. That’s the exception that proves the rule.
(“developers get interested in the domain when the domain is
technical”).

Russ: Let’s exclude technical domains, then. What do people think?

Mark: Key word… I think “talented” is misplaced. I’d use
the
generalization without this word.

Eric: You may be partly defining “talented” as a person with
enough
insight to be interested in the domain.

Russ: And connecting “talented” with “successful”.

Mark: People may not care about “widgets” in the product sense
rather
than the GUI sense. The only way you can care about it is to really
learn it.

Eric: Often on larger projects there’s an infrastructure team broken

off… The most talented developers get to pick what team to be on.
Where do they end up? The infrastructure team. They don’t work on the

account reconciliation feature. Instead they do fancy framework
generalization about the UI or something.

[…]

Eric: I’d certainly like for talented developers to have interest in

the domain. When they were working on the account reconciliation code,

they did a better job than the person who replaced them. So part of
what I’m hoping from domain driven design is that we could give the
talented person a better way to think about the domain, a way that it

can be interesting. I don’t think the group here is representative.

Russ: Of talented developers?

(general laughter)

Eric: Present company excepted.

Chris: Technical knowledge is often more transferable than domain
knowledge.

Eric: And the way domain-related development (notice I don’t say
domain-driven development) is done is often very boring. And when you

add things to your resume… if you say you have mastered the specifics

of the cargo handling operations at a port, it would just be clutter.

You wouldn’t put it on at all.

Chris: Yes, accounting, finance, there are a few generic, transferable

domains that would count.

Eric: And does your peer group of other developers… they think you’re

really smart when you can do cool technical tricks. Do other
developers think you’re smart when you find a better way to reconcile

accounts? No.

Tim: Interest…my personal interest sometimes in the complexity of a

domain. Multi-state tax law for multinational companies. So if I
tackle it as a complex problem, it’s interesting, but if I got assigned

to it, it’s not clear at the outset that it’s actually quite an
involved problem. Now I’m working on music playlists, I’m a little
more interested in the domain.

Eric: If people in some domain want a new application to do something

more than create, read, edit, delete… It’s like you’re a
15th-century physicist.

Q: “Getting your head chopped off?”

Eric: Sometimes, perhaps. People may not support and understand your

way of thinking. But think how exciting it could be to be among the
first to see rhyme and reason in how things move. Before that, people

would speculate on motion, and often they got it wrong.

John B: It’s a very similar analogy, actually, to what often happens
in
software development. Speculation rather than testing.

Eric: We’re still at that level with domain modeling with most domains.

There are a few that are better done, say accounting. There are some
powerful abstractions, a ledger, credit, debit, double-entry. It’s
well on its way. But most other domains are virgin territory.

Eric: What’s missing… what’s missing is the idea that domain modeling

is a discipline. Saying “I’m good at diving into domains, finding
a
model, building software based on that.” Being able to put that on

your resume, having it mean something among your peers.

Chris: I’ve certainly seen contract positions advertised for people
with skill doing domain modeling. They call them “Rational Rose
Modelers” or “UML modelers for the domain.”

Eric: I guess there’s a silver lining in that cloud.

Russ: Are you sure it’s silver?

John B: There’s this meta-skill, then, domain modeling, that you can

capture, otherwise you couldn’t write a book on it.

Eric: Well, I guess _I_ couldn’t write a book on it if it didn’t exist.

Q: How do you tell if you have a good model for a domain, vs. a good

architecture in the model. You were saying that there are a lot of
things in the domain that aren’t captured well by UML.

Eric: Perhaps it would be best to keep moving through the material to

answer that question.

Eric: Sometimes, when the code is closely tied to the model. You
might choose to move a method, to re-assign a responsibility. That can

mean the model has changed; the model in your head, not necessarily a

particular UML diagram.

Russ: You had a good example of having to create a larger-grained set

of objects in the system to be able to work well with an object
database, and that caused you to re-think the model and how you were
going to deal with the domain.

Eric: In our original model, perhaps we might call it an analysis
model, we had a large number of small objects in intricate
relationships. It was a serious performance problem in connection with

the database. So we needed to model the problem with fewer objects.
There were 3 possible outcomes: (1) the same concept, but different
implementations, rolling in subcomponents into the object which
aggregates them, absorbing variant behavior; (2) a modified model, not

as nice, but it works; (3) a new way of thinking about the problem that

also works well as a way of breaking down the domain. We had some of
each. But in each case, we said the way we think about the problem
will be tied to the implementation. Maybe the model will not be as
beautiful, but we do have to support it. There might be “teaching

models” to tell people about the domain, but there’s only one domain

model that

Russ: Does anyone have a story about when there was an analysis model

that was at variance with the code?

(1): I had this issue. There were often subtle problems with the
model, things that were not implementable. We had to go back to the
analysts again.

Tim: We didn’t go back to the analysis phase.

Russ: And you’d already used that time?

Tim: Yes. We would have had to cut into QA time. And yes, it was a
problem that the model was not really useful. Did the analysts get
paid? Yes. It met their criteria. Measured against our phase, well,
no. We had a notion of the model, but we were too busy coding
workarounds.

Eric: Did you change your objects to reflect new concepts or stick with

the original ones from the model?

Tim: Both. Sometimes we worked around it with a mapping layer, other

times the model was loosely enough defined that we could implement it

in a reasonably flexible way.

Eric: I’d like to distinguish between “UML”, a representation
of what
someone thought was the model at some time, and “the model”,
which is
how you are thinking about and communicating with the code.

Tim: An interesting part of this is that I’m sure the analysts had a

model which was not the UML. But it was transcribed to UML and we just

had to guess at what was missing.

Eric: UML just doesn’t capture enough.

Russ: Isn’t that what OCL is for?

(2): Usually you give people X and they are happy, occasionally people

ask for X, you give them X, and they wanted Y. But when you hand it
over, it does not provide people what they need to accomplish the task

in the environment — speed, memory use, usability — not a conceptual

mismatch, necessarily, but a poor implementation in terms of the
working context.

Eric: Extreme Programming says, “just don’t try to understand it
all up
front”. So they have elaborate practices to stay customer-focused
and
deliver something useful. You can get something done, delivering
feature-by-feature code. But part of the story is also agility,
responsiveness to changing requirements. Partly it’s things like test

frameworks, refactoring, etc. to keep the _code_ quality high. But if

you have also been using domain driven design, the internals of the
software reflect what the customer cares about and wants to do, not
just the external interface, the services the software provides. So
you need a close relationship with a domain expert. This is not
necessarily the customer who is choosing and assigning value to
features, or the user who will be working about it. There is iteration

in code, while in domain knowledge, there’s what I call knowledge
crunching, reflecting on what you have learned about the domain and
evolving your model to a more representative and more useful state.

Eric: Probably that’s true.

Russ: It goes further than that. By modeling the domain well, by
coding that into the software, you also find that the next thing you
haven’t designed yet, you’re more likely able to fit it into the
existing software because of the way its structure reflects the
structure of the domain.

Eric: XP has more things to guard your process against spinning your

wheels and not making useful progress. You could apply a very
straightforward, procedural approach to an iterative development and
make good progress.

(2): You’re talking about more about architecture, and I’m talking
about features.

Eric: You’ll notice I don’t actually talk about architecture except
toward the end of the book when I talk about architecture teams as a
way to organize larger development efforts. But for a domain with
complex requirements, where there are interrelationships among the
various pieces, then model-driven, domain-driven design is important.

Keith: I’ve worked with code where there’s a model, but it has kind of

evaporated, it isn’t visible in the code as you see it and work with
it. Do you need, at least, a good object oriented language?

Eric: Well, code of that description is not a model-driven design. And

how you get one is much of what this book is about. Especially part 2,

and part 3 is about getting a good one. So modeling — what your
“Rational Rose Modeler” would be expected to do (looking at
Chris), is
the opposite of hands-on modeling.

Keith: In the case I’m thinking about, the team created a model and
implemented it.

Eric: Does it show up in the code?

Keith: You can’t really see it. It’s sort of like a fragmented mirror

or a Picasso painting.

Eric: Then it’s not model-driven design.

John B: “Team = Code” ?

Keith : Conway’s Law? The structure of the code reflects the structure

of the organization?

Russ: I think you were a little harsh about not being able to do
model-driven design in C. You can do object-like stuff if you don’t
need inheritance. We had structures of function pointers, we passed
around a “this” pointer, and everything corresponded and felt
much like
you would feel programming in an object-oriented language.

Eric: I don’t want to overstate it. But I think that choosing the
right language is really powerful. It’s harder to write, it’s harder
to read.

Russ: But I think you could read the code and see right back to the
model we were working with.

Mark: It depends more on the programmer. I’ve seen awful code in C++

and really clean code in C.

Eric: I’m not trying to pick good and bad among languages. But when
you want to do model-driven design…the model belongs to some style,

and mostly these days the model is in terms of interacting objects. So

choosing an object-oriented language gives you code which can be
expressed in terms closer to the model than other languages can easily

express. You need a programming language which supports your modeling

paradigm, whether it’s object-oriented, mathematical equations, or a
chain of logical rules.

Eric: I’d certainly like to see a language that’s better at supporting

object-oriented design than Java. I have worked with Smalltalk, which

I consider to be better, but it is not radically better, not in a
different league.

Keith: Have you considered Scarlet? You write the algorithmic parts,

the object and methods, in one part of the language, and separately
describe how the objects are composed.

Eric: You could consider the current fashion for compiling a system out

of UML and OCL as a programming language which is close to the model,

but I don’t think it’s a good programming language. I’d have to see
Scarlet to see what I think. I don’t want to get into any religious
wars about programming languages, I’d just like to point out that you

want to choose the right tool for the job.

Eric: I try to stay away from the dichotomy between the “analysis

model” and the “implementation model”. Each one is useless
in
isolation, since the analysis model doesn’t tell you whether the system

actually obeys, say, a constraint you’ve noted in the model. This is
not to say that all parts of the model are equally important, but that

the core, meaningful, abstract concepts from the domain are expressed

in the model that your implementation is based on.

Tim:

Eric: I advise people not to get attached to any particular model.
There are always alternatives, or almost always. If you find that your

original model does not work for building the system, then I take that

as a sign for rethinking the model. So the shift I describe in the
book — from composed groups of little objects, to a stack of tokens
and a parser which interpreted these as a little language. It was
equally elegant, but perhaps less accessible to some developers. And
it reflected a different model, a different way of thinking about and

expressing the concepts from the domain.

Russ: Key points from the introduction?

Eric: One point is not so much about whether you have a good model
(that’s more part 3), it’s about how to keep your model in sync with
your development. If your “smart people” are doing nothing but

modeling, but you don’t implement the model in the terms it presents,

then

(3): Don’t you want your junior people in on modeling, so they can get

mentoring and absorb skills?

Eric: I go further than that. I say everyone should be modeling, and

everyone should be programming. If you aren’t doing that, you aren’t
doing model-driven design. You have to do modeling as you program.

Russ: Let me say something heretical. What if you had a “thinker”
and
a “coder”, and the coder goes back whenever there is a problem,
and
asks the model to be adjusted and fed back. Is that model-driven
design? Clearly there are communication costs.

Eric: I guess that could be model-driven design. But if you adapt your

implementation to be more do-able, you introduce a change in the model.

I wouldn’t advocate that. You want someone’s eyes on the code who
understands the model, and can recommend whether it’s consistent with

the model to tweak the code a bit for the sake of implementation, or
whether there is some issue in the model which needs to be re-thought.

Every time I’ve seen this approach succeed, the people who had created

the model were also participating in coding it.

(1): Scaling of this approach?

Eric: Part 4 of the book discusses this. But there are also issues
about how to partition the model into chunks which make good objects
(Part 2).

Russ: Like the comparison between the elements of the model… and
saying that they are not things that you try to identify like
constellations in the night sky.

John: I see that when people try to reverse-engineer a system. They
look at all the stars, and say, “well, there’s a scorpion in there

somewhere.”

Russ: And you can extract the patterns with an automated tool.

Chris: (p.70) You seem to have defined the “application layer”
very
strictly. I might equate it to a “services layer”. There is
some
business knowledge, often, in doing things like exposing tasks, in
doing error handling. That amounts to business logic. Recovery
strategies in the case of failures, perhaps.

Eric: I might not want to put those in the application layer. I talk

about services in the domain layer, services which are fundamentally
domain behavior, and others which are more application behavior.

Chris: I agree that there are two kinds of services. But I find that

even in things, like services for aggregating network traffic, there is

some business logic.

Eric: All right. Then there’s a little workflow in there. But you
want to push it back if you can. A lot of workflow is not really
business related. Things like going from screen to screen in an
application. Or having an application which constructs a new account
in a particular way, but it doesn’t necessarily matter that you do it

in that way to the domain.

Chris: I’m thinking of metaservices, which call to services which exist

in the domain. Have you worked with Struts or JFaces?

Eric: I’ve been on such a project, but I wasn’t involved in that part

of the application.

Chris: I wanted to ask about applications of Struts or JFaces which
might be either in harmony with this approach, or at variance with it.

Eric: J2EE entity beans, I guess the recommended way to use them,
really separates your data from your behavior. Does Struts carry
baggage like that? I don’t know.

Chris: What I wanted to see is if the recommended or common patterns

for using Struts were problematic. As an example from a different
framework, say, the .NET suggested practice of exposing RowSets all the

way from your database up to your UI objects?

(discussion of Microsoft approach… view through to the database as
a
way of scaling through stateless servers)

Azad: And what you might call, not the “Smart UI”, but the
“Smart
Database” pattern, controlling things with stored procedures. For

certain applications, you can get quite a ways with this approach.

Eric: You could make it work in a model-driven way, but your modeling

paradigm would have to be in terms of entities, relationships,
triggers, etc. It strikes me as a rather masochistic way to do
modeling.

Russ: That’s kind of a lead-in to the Smart UI pattern.

Bob: First… having the domain objects responsible for persisting
things. But unfortunately I’ve seen readers and writers all over the
system, knowing bits and pieces about the serialized form, breaking
encapsulation. I wanted to check in about where you were going.
Perhaps “what” should be persisted should belong to the domain
object,
and “how” should belong to the implementation?

John B: I think that is Chapter 6.

Eric: Yes. Let me just refocus on the goal. When you’re looking at
the domain object, you can think about its domain meaning, not about
the implementation details of how it talks to the database. If you
have a framework that lets you disentangle the domain meaning and
behavior with the implementation.

Bob: I’ve used Aspects a lot lately, to isolate things like
persistence.

Eric: I’ve dipped my toe into this, and I thought it was neat. But
I’d just like to focus on whether the persistence framework helps you

read the code in terms of its domain nature (or at least gets out of
the way), or whether it does not.

Russ: I was curious to know about how aspects and refactoring interact

in practice. How well do they work together. Bob, have you been using

Aspects in a serious way?

Bob: More playing at this point, but I can give you a pointer to a blog

from a fellow at Microsoft, an entry something like “A Year With

Aspects”, where he talks about the difficulties with multiple aspects,

dependencies and duplications, after working with AOP for a while.

Azad: How does the model interact with documentation?

Eric: If you start with the core notion that the model is a set of
concepts that you want to be able to communicate, to understand, to use

in talking about the domain and the software implementation, then any

way of documenting that is compatible with that is reasonable.

Azad: Or if you were dealing with something that was more heavily
rules-based. Or when your domain experts are expressing the domain in

different terms than you find useful for implementation.

Eric: I’d recommend using the same style for capturing domain knowledge

from the experts and for designing and implementing the system.

Azad: No question about that.

Eric: Or have a rules engine and integrate that into the system. But

it may be worse than modeling their rules as Java objects. You still
need a ubiquitous language which you can communicate in terms of the
domain, in terms of the design, and the implementation.

Robert: Perhaps in a lot of domains, there are a lot of little surface

rules in the processes you go through. But in order to build things
that will go a longer way, I feel there’s a danger in not trying to
discover the objects.

Eric: The concepts of the domain.

Eric: It’s hard to carry two models with a mapping between them. The

mapping is itself a modeling problem.

(4): Or in some languages, being able to overlay knowledge about how
to
connect things, to expose different ways of

Eric: So you’re introducing candidate abstractions into the language,

in the terms of the domain?

Russ: So if your domain experts are not communicating in terms which

map very closely to the system you are building, you’ve lost a lot of

their expertise.

Azad: So I think that we disagree on one little point.

Eric: “Never do it” on my side, vs. “Avoid it.” But
when I expressed
it that way in the book, the reviewers recommended that I remove all
the caveats and reservations. I really do believe that whenever there

is one model for talking to domain experts and another model for
programming, then we are really missing the boat. We won’t get the
agility in the design.

Azad: Partly what I was trying to express was that in the currently
popular programming language, whatever that might be, there may be some

concepts that are key to the domain that aren’t easily mapped or
modeled.

Mark: Something I wanted to ask that isn’t in the book so explicitly

… trying to get the developers to buy in, having the whole team
involved … but what about management? How do you change the culture

of management to allow teams of developers to do these things?

Eric: Managers are very buzzword-driven. If they are interested in the

buzzword (today maybe it’s XP, tomorrow maybe Domain Driven Design),
you’ll be more likely to be able to do it.

Robert: Managers also pay attention to success as well as buzzwords.

You try and make strong connections between this approach and
successful projects.

Eric: On the web site, there’s actually something called “Managers’

Guided Tour To Domain Driven Design”

Mark: Is it in PowerPoint format?

Russ: A good lead-in to Smart UI. You really need forward-looking
management to take on model-driven development with nice testing and
all that. Smart UI gives you a quick burst of productivity up to a
certain point, then you run into a point where you can no longer scale

it. Model-driven and domain-driven… you start with something kind of

linear, lose a little from complexity, gain some from the set of
strong, interacting abstractions. It takes a little while for the more

advanced techniques to really bring home their benefits.

Eric: I do say that MDD is more important for cases where the domain
is
complex.

Bob: It’s robustness. YAGNI works if you don’t have to go back and
touch it. MDD is about robustness. A small change in the problem
domain is a small change in the objects and classes.

John B: XP’s “system metaphor” speaks to this.

Eric: YAGNI applies a lot in model driven design, as well. For
analysis modeling, you don’t have something that tells you when you can

stop.

Eric: Do the _simplest_ thing that can possibly work… it might be
really hard. Thinking profoundly in order to express the problem most

elegantly and most simply. It’s really a profound breakthrough.

John B: Kent Beck expressed this as a question: “What is the simplest

thing that can possibly work? Why aren’t you doing that?” rather
than
simply “Do the simplest thing that could possibly work.” There’s
a
level of reflection there that’s missing without the questions.

Eric: Especially when you know you’ll have a version 2, you need a
robust way of developing software like model-driven design. There may

be simple ways to solve simple problems where you may not have to use

such techniques. If your problem fits into a pre-existing tool, get it

off the shelf.

John B: I often start with a smart UI. I start in domains where the UI

is the biggest risk. Then I factor the domain objects out of the UI as

time goes on. I’m working on a graphical interface to a text-based
conferencing system, and I can see there are a set of objects wanting

to come out. But the next several stories don’t call for that to
happen.

Russ: And then, when you’ve learned what you can from the first
prototype with the smart UI, you have a choice between factoring out
the domain objects, and retiring the prototype and re-building it.

Eric: You may have different experience from I about how easy it is to

refactor out of a smart UI. My experience has been that when I step
into a client’s place where there isn’t some sort of layered
architecture present, then I often will say that I do not know how to

help them. I’ve had a lot of trouble with escaping from a bad design.

(discussion of experiences factoring out of a smart UI: John B, Russ,

Jeff M)

Eric: Very early in the history of a system, especially if you are
probing for key risks, you can get away with a “Smart UI”. But
if you
plan your system to have any sort of a life in development, you should

plan to have a domain layer.

Bob: How about non-layered architectures. Pipes and Filters?
Blackboard?

Russ: Composite?

John B: Composite sounds like the structure of the domain layer.

Russ: Are we the only people who have made a success out of a
non-layered architecture? (Russ describes a system that separates I/O

and other implementation concerns in specific service classes, but not

separate layers).

Eric: The four-layer architecture diagram I present is probably too
specific. The essence is isolating the domain. Have a domain layer
representing the software constructs relevant to business logic. It
sounds like what you describe is not a layered architecture, but it is
a separation of the domain. It’s too bad it comes across as so much of
a specific prescription.

Bob: For domain-driven business applications, they pretty much do look

a lot like this layered architecture you present.

Attending

(partial list only)

Don Chin
Vince Nibler
Tim Huske
Mark Taylor
Robert Benson
Russ Rufer
Jeffrey Blake
Ken Scott-Hlebek
Carlos McEvilly
Batman/Tao
Tracy Bialik
Jeff Miller
Chris Lopez
John Brewer
Azad Bolour
Keith Ray
Bob Evans
Walter Vannini

(and several more, total 23)