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

5.
Are the developers knowledgeable about the domain? Are they 
interested
in the domain?
6.
You won't find perfect answers, of course. You know less about this project right now than you
ever will in the future. But these questions give you a solid starting point. By the time you have
specific initial answers to these questions, you'll have started getting insight into what most
urgently needs to be done. As time goes along, you can refine the answers—especially the 
CONTEXT
MAP, DOMAIN VISION STATEMENT
, and any other artifacts you've created—to reflect changed
situations and new insights.
[ Team LiB ]

---

[ Team LiB ]
Who Sets the Strategy?
Traditionally, architecture is handed down, created before application development begins, by a
team that has more power in the organization than the application development team. But it
doesn't have to be that way. That way doesn't usually work very well.
Strategic design, by definition, must apply across the project. There are many ways to organize a
project, and I don't want to be too prescriptive. However, for any decision-making process to be
effective, some fundamentals are required.
First, let's take a quick look at two styles that I've seen provide some value in practice (thus
ignoring the old "wisdom-from-on-high" style).
Emergent Structure from Application Development
A self-disciplined team made up of very good communicators can operate without central authority
and follow 
EVOLVING ORDER
to arrive at a shared set of principles, so that order grows organically,
not by fiat.
This is the typical model for an Extreme Programming team. In theory, the structure may emerge
completely spontaneously from the insight of any programming pair. More often, having an
individual or a subset of the team with some oversight responsibility for large-scale structure helps
keep the structure unified. This approach works well particularly if such an informal leader is a
hands-on developer—an arbiter and communicator, and not the sole source of ideas. On the
Extreme Programming teams I have seen, such strategic design leadership seems to have
emerged spontaneously, often in the person of the coach. Whoever this natural leader is, he or she
is still a member of the development team. It follows that the development team must have at
least a few people of the caliber to make design decisions that are going to affect the whole
project.
When a large-scale structure spans multiple teams, closely affiliated teams may begin to
collaborate informally. In such a situation, each application team still makes the discoveries that
lead to the idea for a large-scale structure, but then particular options are discussed by the
informal committee, made up of representatives of the various teams. After assessing the impact
of the design, participants may decide to adopt it, modify it, or leave it on the table. The teams
attempt to move together in this loose affiliation. This arrangement can work when there are
relatively few teams, when they are all committed to coordinating with each other, when their
design capabilities are comparable, and when their structural needs are similar enough to be met
by a single large-scale structure.