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



Download 7,21 Mb.
Pdf ko'rish
bet221/343
Sana17.11.2022
Hajmi7,21 Mb.
#867526
1   ...   217   218   219   220   221   222   223   224   ...   343
Bog'liq
Eric Evans 2003 - Domain-Driven Design - Tackling Complexity in the Heart of Software

Crisis as Opportunity
For over a century after Charles Darwin introduced it, the standard model of evolution was that
species changed gradually, somewhat steadily, over time. Suddenly, in the 1970s, this model was
displaced by the "punctuated equilibrium" model. In this expanded view of evolution, long periods
of gradual change or stability are interrupted by relatively short bursts of rapid change. Then
things settle down into a new equilibrium. Software development has an intentional direction
behind it that evolution lacks (although it may not be evident on some projects), but nonetheless
it follows this kind of rhythm.
Classical descriptions of refactoring sound very steady. Refactoring toward deeper insight usually
isn't. A period of steady refinement of a model can suddenly bring you to an insight that shakes up
everything. These breakthroughs don't happen every day, yet a large proportion of the changes
that lead to a deep model and supple design emerge from them.
Such a situation often does not look like an opportunity; it seems more like a crisis. Suddenly
there is some obvious inadequacy in the model. There is a gaping hole in what it can express, or
some critical area where it is opaque. Maybe it makes statements that are just wrong.
This means the team has reached a new level of understanding. From their now-elevated
viewpoint, the old model looks poor. From that viewpoint, they can conceive a far better one.
Refactoring toward deeper insight is a continuing process. Implicit concepts are recognized and
made explicit. Parts of the design are made suppler, perhaps taking on a declarative style.
Development suddenly comes to the brink of a breakthrough and plunges through to a deep
model—and then steady refinement starts again.
[ Team LiB ]


[ Team LiB ]
Part IV: Strategic Design
As systems grow too complex to know completely at the level of individual objects, we need
techniques for manipulating and comprehending large models. This part of the book presents
principles that enable the modeling process to scale up to very complicated domains. Most
such decisions must be made at team level or even negotiated between teams. These are the
decisions where design and politics often intersect.
The goal of the most ambitious enterprise system is a tightly integrated system spanning the
entire business. Yet the entire business model for almost any such organization is too large
and complex to manage or even understand as a single unit. The system must be broken into
smaller parts, in both concept and implementation. The challenge is to accomplish this
modularity 
without losing the benefits of integration,
allowing different parts of the system to
interoperate to support the coordination of various business operations. A monolithic, all-
encompassing domain model will be unwieldy and loaded with subtle duplications and
contradictions. A set of small, distinct subsystems glued together with ad hoc interfaces will
lack the power to solve enterprise-wide problems and allows consistency problems to arise at
every integration point. The pitfalls of both extremes can be avoided with a systematic,
evolving design strategy.
Even at this scale, domain-driven design does not produce models unconnected to the
implementation. Every decision must have a direct impact on system development, or else it
is irrelevant. Strategic design principles must guide design decisions to reduce the
interdependence of parts and improve clarity without losing critical interoperability and
synergy. They must focus the model to capture the conceptual core of the system, the
"vision" of the system. 
And they must do all this without bogging the project down.
To help
accomplish these goals, Part IV explores three broad themes: context, distillation, and large-
scale structure.
Context, the least obvious of the principles, is actually the most fundamental. A successful
model, large or small, has to be logically consistent throughout, without contradictory or
overlapping definitions. Enterprise systems sometimes integrate subsystems with varying
origins or have applications so distinct that very little in the domain is viewed in the same
light. It may be asking too much to unify the models implicit in these disparate parts. By
explicitly defining a 
BOUNDED CONTEXT
within which a model applies and then, when
necessary, defining its relationship with other contexts, the modeler can avoid bastardizing
the model.
Distillation reduces the clutter and focuses attention appropriately. Often a great deal of
effort is spent on peripheral issues in the domain. The overall domain model needs to make
prominent the most value-adding and special aspects of your system and be structured to
give that part as much power as possible. While some supporting components are critical,
they must be put into their proper perspective. This focus not only helps to direct efforts
toward vital parts of the system, but it keeps the vision of the system from being lost.
Strategic distillation can bring clarity to a large model. And with a clearer view, the design of
the 
CORE DOMAIN
can be made more useful.
Large-scale structure completes the picture. In a very complex model, you may not see the
forest for the trees. Distillation helps, by focusing the attention on the core and presenting
the other elements in their supporting roles, but the relationships can still be too confusing
without an overarching theme, applying some system-wide design elements and patterns. I'll
give an overview of a few approaches to large-scale structure and then go into depth on one


such pattern, 
RESPONSIBILITY LAYERS
, to explore the implications of using such a structure.
The specific structures discussed are only examples; they are not a comprehensive catalog.
New ones should be invented as needed, or these should be modified, through a process of
EVOLVING ORDER
. Some such structure can bring a uniformity to the design that accelerates
development and improves integration.
These three principles, useful separately but particularly powerful taken together, help to
produce good designs—even in a sprawling system that no one completely understands.
Large-scale structure brings consistency to disparate parts to help those parts mesh.
Structure and distillation make the complex relationships between parts comprehensible
while keeping the big picture in view. B
OUNDED CONTEXTS
allow work to proceed in different
parts without corrupting the model or unintentionally fragmenting it. Adding these concepts
to the team's 
UBIQUITOUS LANGUAGE
helps developers work out their own solutions.
[ Team LiB ]


[ Team LiB ]

Download 7,21 Mb.

Do'stlaringiz bilan baham:
1   ...   217   218   219   220   221   222   223   224   ...   343




Ma'lumotlar bazasi mualliflik huquqi bilan himoyalangan ©hozir.org 2025
ma'muriyatiga murojaat qiling

kiriting | ro'yxatdan o'tish
    Bosh sahifa
юртда тантана
Боғда битган
Бугун юртда
Эшитганлар жилманглар
Эшитмадим деманглар
битган бодомлар
Yangiariq tumani
qitish marakazi
Raqamli texnologiyalar
ilishida muhokamadan
tasdiqqa tavsiya
tavsiya etilgan
iqtisodiyot kafedrasi
steiermarkischen landesregierung
asarlaringizni yuboring
o'zingizning asarlaringizni
Iltimos faqat
faqat o'zingizning
steierm rkischen
landesregierung fachabteilung
rkischen landesregierung
hamshira loyihasi
loyihasi mavsum
faolyatining oqibatlari
asosiy adabiyotlar
fakulteti ahborot
ahborot havfsizligi
havfsizligi kafedrasi
fanidan bo’yicha
fakulteti iqtisodiyot
boshqaruv fakulteti
chiqarishda boshqaruv
ishlab chiqarishda
iqtisodiyot fakultet
multiservis tarmoqlari
fanidan asosiy
Uzbek fanidan
mavzulari potok
asosidagi multiservis
'aliyyil a'ziym
billahil 'aliyyil
illaa billahil
quvvata illaa
falah' deganida
Kompyuter savodxonligi
bo’yicha mustaqil
'alal falah'
Hayya 'alal
'alas soloh
Hayya 'alas
mavsum boyicha


yuklab olish