They brainstormed. There were a lot of possibilities. Alternative packaging schemes were
proposed. Maybe some document could give an overview of the system, or some new views of the
class diagram in the modeling tool could guide a developer to the right
MODULE
.
But the project
leaders weren't satisfied with these gimmicks.
They could tell a simple story of their simulation, of the way data would be marshaled through an
infrastructure, its integrity and routing assured by layers of telecommunications technology. Every
detail of that story was in the model, yet the broad arc of the story could not be seen.
Some essential concept from the domain was missing. But this time it was not a class or two
missing from the object model, it was a missing structure for the model as a whole.
After the developers mulled over the problem for a week or two, the idea began to jell. They would
impose a structure on the design. The entire simulator would be
viewed as a series of layers
related to aspects of the communications system. The bottom layer would represent the physical
infrastructure, the basic ability to transmit bits from one node to another. Then there would be a
packet-routing layer that brought together the concerns of how a particular data stream would be
directed. Other layers would identify other conceptual levels of the problem.
These layers would
outline their story of the system.
They set out to refactor the code to conform to the new structure. M
ODULES
had to be redefined so
as not to span layers. In some cases, object responsibilities were refactored so that each
object
would clearly belong to one layer.
Conversely, throughout this process the definitions of the
conceptual layers themselves were refined based on the hands-on experience of applying them.
The layers,
MODULES
, and objects coevolved until, in the end, the entire design followed the
contours of this layered structure.
These layers were not
MODULES
or any other artifact in the code. They were an overarching set of
rules that constrained the boundaries and relationships of any particular
MODULE
or object
throughout the design, even at interfaces with other systems.
Imposing this order brought the design back to comfortable intelligibility. People knew roughly
where to look for a particular function. Individuals working independently could make design
decisions that were broadly consistent with each other. The complexity ceiling had been lifted.
Even with a
MODULAR
breakdown, a large model can be too complicated to grasp. The
MODULES
chunk the design into manageable bites, but there may be many of them. Also, modularity does
not necessarily bring uniformity to the design. Object to object,
package to package, a jumble of
design decisions may be applied, each defensible but idiosyncratic.
The strict segregation imposed by
BOUNDED CONTEXTS
prevents corruption and confusion, but it
does not, in itself, make it easier to see the system as a whole.
Distillation does help by
focusing attention on the
CORE DOMAIN
and casting other subdomains in
their supporting roles. But it is still necessary to understand the supporting elements and their
relationships to the
CORE DOMAIN
—and to each other. And while the
CORE DOMAIN
would
ideally be
so clear and easily understood that no additional guidance would be needed, we are not always at
that point.
On a project of any size, people must work somewhat independently on different parts of the
system. Without any coordination or rules, a confusion of different styles and distinct solutions to
the same problems arises, making it hard to understand how the parts
fit together and impossible
to see the big picture. Learning about one part of the design will not transfer to other parts, so the
project will end up with specialists in different
MODULES
who cannot help each other outside their
narrow range. C
ONTINUOUS INTEGRATION
breaks down and the
BOUNDED CONTEXT
fragments.
Do'stlaringiz bilan baham: 
