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



Download 7,21 Mb.
Pdf ko'rish
bet289/343
Sana17.11.2022
Hajmi7,21 Mb.
#867526
1   ...   285   286   287   288   289   290   291   292   ...   343
Bog'liq
Eric Evans 2003 - Domain-Driven Design - Tackling Complexity in the Heart of Software

G
ENERIC
 S
UBDOMAIN
 Versus C
OHESIVE
 M
ECHANISM
Both 
GENERIC SUBDOMAINS
and 
COHESIVE MECHANISMS
are motivated by the same desire to
unburden the 
CORE DOMAIN
. The difference is the nature of the responsibility taken on. A 
GENERIC
SUBDOMAIN
is based on an expressive model that represents some aspect of how the team views
the domain. In this it is no different than the 
CORE DOMAIN
, just less central, less important, less
specialized. A 
COHESIVE MECHANISM
does not represent the domain; it solves some sticky
computational problem posed by the expressive models.
A model proposes; a 
COHESIVE MECHANISM
disposes.
In practice, unless you recognize a formalized, published computation, this distinction is usually
not pure, at least not at first. In successive refactoring it could either be distilled into a purer
mechanism or be transformed into a 
GENERIC SUBDOMAIN
with some previously unrecognized model
concepts that would make the mechanism simple.
When a M
ECHANISM
 Is Part of the C
ORE
 D
OMAIN
You almost always want to remove 
MECHANISMS
from the 
CORE DOMAIN
. The one exception is when



MECHANISM
is itself proprietary and a key part of the value of the software. This is sometimes the
case with highly specialized algorithms. For example, if one of the distinguishing features of a
shipping logistics application were a particularly effective algorithm for working out schedules, that
MECHANISM
could be considered part of the conceptual 
CORE
. I once worked on a project at an
investment bank in which highly proprietary algorithms for rating risk were definitely in the 
CORE
DOMAIN
. (In fact, they were held so closely that even most of the 
CORE
developers were not
allowed to see them.) Of course, these algorithms are probably a particular implementation of a
set of rules that really predict risk. Deeper analysis might lead to a deeper model that would allow
those rules to be explicit, with an encapsulated solving mechanism.
But that would be another incremental improvement in the design, for another day. The decision
as to whether to go that next step would be based on a cost-benefit analysis: How difficult would it
be to work out that new design? How difficult is the current design to understand and modify? How
much easier would it be with a more advanced design, for the type of people who would be
expected to do the work? And of course, does anyone have any idea what form the new model
might take?

Download 7,21 Mb.

Do'stlaringiz bilan baham:
1   ...   285   286   287   288   289   290   291   292   ...   343




Ma'lumotlar bazasi mualliflik huquqi bilan himoyalangan ©hozir.org 2024
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