Domain-Driven Design: Tackling Complexity in the Heart of Software

Don't write frameworks for dummies
Team divisions that assume some developers are not smart enough to design are likely to fail
because they underestimate the difficulty of application development. If those people are not
smart enough to design, they shouldn't be assigned to develop software. If they are smart
enough, then the attempts to coddle them will only put up barriers between them and the tools
they need.
This attitude also poisons the relationship between teams. I've ended up on arrogant teams like
this and found myself apologizing to developers in every conversation, embarrassed by my
association. (I've never managed to change such a team, I'm afraid.)
Now, 
encapsulating irrelevant technical detail is completely different
from the kind of prepackaging
I'm disparaging. A framework can place powerful abstractions and tools in developers' hands and
free them from drudgery. It is hard to describe the difference in a generalized way, but you can
tell the difference by asking the framework designers what they expect of the person who will be
using the tool/framework/components. If the designers seem to have a high level of respect for
the user of the framework, then they are probably on the right track.
Beware the Master Plan
A group of architects (the kind who design physical buildings), led by Christopher Alexander, were
advocates of piecemeal growth in the realm of architecture and city planning. They explained very
nicely why master plans fail.

---

Without a planning process of some kind, there is not a chance in the world that the
University of Oregon will ever come to possess an order anywhere near as deep and
harmonious as the order that underlies the University of Cambridge.
The master plan has been the conventional way of approaching this difficulty. The master
plan attempts to set down enough guidelines to provide for coherence in the environment as
a whole—and still leave freedom for individual buildings and open spaces to adapt to local
needs.
. . . and all the various parts of this future university will form a coherent whole, because
they were simply plugged into the slots of the design.
. . . in practice master plans fail—because they create totalitarian order, not organic order.
They are too rigid; they cannot easily adapt to the natural and unpredictable changes that
inevitably arise in the life of a community. As these changes occur . . . the master plan
becomes obsolete, and is no longer followed. And even to the extent that master plans 
are
followed . . . they do not specify enough about connections between buildings, human scale,
balanced function, etc. to help each local act of building and design become well-related to
the environment as a whole.
. . . The attempt to steer such a course is rather like filling in the colors in a child's coloring
book . . . . At best, the order which results from such a process is banal.
. . . Thus, as a source of organic order, a master plan is both too precise, and not precise
enough. The totality is too precise: the details are not precise enough.
. . . the existence of a master plan alienates the users [because, by definition] the members
of the community can have little impact on the future shape of their community because
most of the important decisions have already been made.
—From 
The Oregon Experiment
, pp. 16–28 (Alexander et al. 1975)
Alexander and his colleagues advocated instead 
a set of principles 
for all community members to
apply to every act of piecemeal growth, so that "organic order" emerges, well adapted to
circumstances.
[ Team LiB ]

---

[ Team LiB ]