Tải bản đầy đủ - 0 (trang)
Chapter 10. Design Techniques to Embrace

Chapter 10. Design Techniques to Embrace

Tải bản đầy đủ - 0trang

InversionofControl/DependencyInjection,andAspect

Orientation.

Iaskedacoupleofmyfriendstowriteaboutthosedesign

techniques,andwehavetheircontributionshere,butIpenned

thefirstsectioninthischaptermyself.Overto"Contextis

King."



ContextIsKing

Ithinkit'sprettycommonnottogiveenoughthoughttohow

importantthecontextis.Forexample,whentheGoFpatterns

[GoFDesignPatterns]arediscussedandusedbydevelopers

withoutpriorexperienceofthesepatterns,itistypicaltoforget

thatthereisacontextforwhenthepatternsaresuitable.

Agoodidea/solution/anything,butinthewrongcontextitisn't

necessarilyanybetterthanabadcounterpart.That'sjustthe

wayitis.

Let'stakeastepbackbeforewefocusmoreonthespecific

context-relatedconceptofthissection.First,here'sawordon

layersandpartitions.



LayersandPartitions

Backin1994,GradyBooch'sbook,Object-OrientedAnalysis

andDesign[BoochOOAD],waspublished.Itgavemeabetter

understandingofwhatJimRumbaugh'sbook,ObjectModeling

Technique[RumbaughOMT],hadintroducedtomeafewyears

before.Onesuchexamplewaslayersandpartitions.The

conceptoflayerswasquitefamiliartome,butnotpartitions

thewayBoochdescribedthem.Hesawpartitionsasslicesin

theotherdimensioncomparedtothelayers.

Tomakethismoreconcretewithanexample,twotypicallayers

aretheUIandtheDomainModel.Twopossiblepartitionsmight

bethesubsystemforregisteringordersandthesubsystemfor

administeringusercomplaints.BothpartitionsmighthaveaUI

andaDomainModel.

Today,justasitwasbackthen,Ithinklayeringhasreceived



muchmorefocusthanpartitions.Layeringhasbeenavery

importantwayofproviding"separationofconcerns."You

probablyhaveafirmgraspofwhattheideais:tolivebythe

principleofSingleResponsibility(SRP)[MartinPPP].

Inaway,thisalmosttotalfocusonlayeringischanging.Ithink

layeringhasrelaxedabitwithDDD,atleastcomparedtothe

rigorouslayeringIusedinthepast[NilssonNED].(Well,weare

stillveryfocusedonfactoringouttheinfrastructurefromthe

DomainModel.)



Note

WediscussedlayeringaccordingtoDDDinChapter

4,"ANewDefaultArchitecture."



Atthesametime,thereisanincreasingunderstandingofhow

youcan'tcreateonesinglehugeDomainModel,oratleastthat

it'softentoocomplex,costly,orinefficienttogothatroutein

large-scalesituations.IalsothinkServiceOrientation(SO)isa

drivingforcewhenitcomestotheincreasedinterestin

partitioning.Thewholeproblemsimplybecomesmoreevident.

Becauseoftheincreasedinterestinpartitioning,theinterestin

layeringmightlessen.It'sjustnotasimportantorbeneficial

witharigorouslayeringdesignforatinypartition.

Let'shaveacloserlookatthereasonsforpartitioning.



ReasonsforPartitioning

Whilelayeringisoftenbasedontechnicalreasoning,



partitioningisoftenbasedonorganizationalreasons.Sure,

partitioningcouldalsobedoneforatechnicalreason;for

instance,acertainpartitionmightbecomestalefasterand

mightbeonewe'dliketoswapforanotherimplementationlater

on.Theideathenmightbetomakeitobviousandeasyto

achievewhenthedaycomes.

Butagain,organizationalreasonsareimportantforpartitioning,

suchasbecauseoneteamtakescareofthisandanotherteam

takescareofthat.ThisistotallyinlinewithadiscussionIhad

withsomecolleaguesaboutmotivationsforlayering.Noneof

themthoughtthatlayeringwasgoodtousefororganizinga

team.That'ssomethingI'vedonefromtimetotime,and(tomy

mind)withsuccess.WhatIthinktheyallreallymeantwasthat

it'sabetterideatoorganizetheteamaroundpartitionsinstead.

Andthenthelayeringislessstressedinsideeachpartition.We

will,ofcourse,stillseethatdifferentpeoplehavedifferentmain

interestsandexpertise,andweshouldn'tfightthat.Weshould

justnotcreatealargedepartmentofUIdevelopersthatbuilds

theUIforallapplications,anotherdepartmentofDomainModel

developers,andyetonemoredepartmentofdatabase

developers.Outofthosetwodimensions(ifyouhaveto

choose),themostimportantisthedomainproblemsthat

shouldbesolved,notwhattechnologiestouse.Rememberthat

whenorganizingtheteamalso.

Whatalsomattersregardingwhetheryouneedpartitioningor

notisthesizeofthedevelopmenteffort.Foratinysystem,one

partitionmightbeallthatisneeded;foralargesystem,agood

partitiondesignmightbeextremelyimportanttosucceed.

Tosummarizethis,Ithinkthatfirstit'samatterofpartitions,

andtheninsidethosepartitionsit'saquestionoflayers,notthe

opposite.

Let'sseeifwecancouplethistoDDD,whichbringsmeto

talkingalittleabouttheBoundedContextpattern[EvansDDD].



BoundedContext

Acommonquestionis"Howshouldwedealwithcomplexity?"

Andjustascommonanansweris"divideandconquer."Useof

hierarchiesisonewayofdividingandconquering.

DDDisprettymuchabouthierarchies.Oneextremelyuseful

toolthatI'vebeenemphasizingalotistheAggregatepattern,

whichisaprettycoarse-grainedunit.Entitiesisanotherunit,

andValueObjectsisyetanother(allfoundanddiscussedat

lengthin[EvansDDD]).

Ifwegointheoppositedirection,"up"fromAggregates,wewill

findthatBoundedContextsisn'tthesameasaggregates,but

ratherthesameassubsystemsorsub-models.

ThebasicideawithBoundedContextistobeveryexplicitabout

inwhatcontextthemodelapplies.Youshouldalsobevery

strictaboutthemodelanditsconceptswithintheBounded

Context;whatisoutsidedoesn'treallymatterthatmuch.

Fromanarrowperspective,agoodreasonforthedivisioninto

severalBoundedContextsistobeabletothinkaboutallthe

detailswithinonemodelandtobeabletokeepitpure.Atthe

sametime,fromawiderperspectivewecanthinkabout"large"

abstractionsthatareeasytograspandthinkaboutinoverview

terms.

AstrongadvantageoftheAggregateisitsboundary.It

simplifieslife,decreasescoupling,andmakesconnectionsmore

explicit.Againwefindadvantagesofaboundary,thistimeona

higherlevelwiththeBoundedContext.



Note

AlthoughIseegreatvalueinboundaries,thereare

alsocosts.Youmightintroducealotofoverhead



whenitcomestocommunicationandperformance.

Asusual,keepitsimpleandaddcomplexitywhen

yougainmorethanthecost.



IfwebindthistotheexampleIusedinthepreviouschapters,

thatofthesalesorder,theremightbeoneboundedcontextfor

orderingandanotherforshipping.ThisisnothowIstartedto

talkaboutitinmylittleexample,butinareal-world,large

scalesituationitmightmakesensefromatechnological

standpoint,anddifferentpartsoftheorganizationmightvery

wellbedealingwitheachofthosebusinessprocesses,which

mightbeagoodreasonforthesplit.



HowDoBoundedContextsandPartitions

Relate?

I'vebeentalkingaboutpartitionsandBoundedContexts,but

thatdoesn'tmeanthatIseethemasthesamething.It's

possiblethattheBoundedContextisthesameasatypical

partition.ItmightalsobethataBoundedContextisbuiltupof

severalpartitionsinstead,butprobablynottheopposite.



ScalingupDDDProjects

AtypicalreasonforapplyingBoundedContextsisthatthey

provideawayofmakingitpossibletoscaleupDDDtolarger

contexts.InsteadofhavingonehugeDomainModelthatahuge

teamtouches,itmightmaketheeffortofunderstandingthe

modelmucheasierifyousplitthemodelintoseveralsmaller

ones,lettingthedevelopmentgroupsfocusontheirown



models.

BoundedContextsmightalsohelppreservetheUbiquitous

Languagefrombecomingun-crispandhavingloosedefinitions.

InsteadwhatyouwillgetareseveralUbiquitousLanguages,

oneperBoundedContext,whichispartlyabadbuy.Butonthe

otherhand,eachofthesewillbemorepowerfulandexact.

Rathertwogood,thanonebad.

Whenyoufindoutthatwhatyouthoughtwasasinglemodel

hasstartedtohaveconceptswithdifferentmeaningsandthat

theUbiquitousLanguageisn'tasclearandcrispasbefore,that

canverywellbeasignthatithasactuallybecometwomodels.

Insteadoffightingit,itcanoftenbewisetopromotethis

evolutionanddefinetwodifferentBoundedContexts.

It'stimetoshiftfocusandtalkaboutanotherreasonfor

partitioningofDomainModels.



WhyPartitionaDomainModelSO?

AssumingthatwealreadyhavealargeDomainModel,why

wouldweneedtopartitionit?Thisisnotanewproblem,butI

thinkSOhasmadetheproblemmoreapparentthanwhen

comparedtoothersolutionsfordistributedsystems,suchas

EJBandCOM+.Inthosesystems,thepartitioningwashelpful

butmostoftennotsostrictlyenforced,asisthenormforSO

systems.



Note

I'mawarethatmanySOpeopledon'tthinkfromthe

DomainModelandout,butstartwiththeinterfaces

instead.AsIseeit,it'salwaysabitofeach.



Thisbookisnotaboutintegrationormessaging,butmerely

aboutarchitectureanddesignforoneserviceorone

application.Butwerelaxthefocusofthebookforasectionand

havealookatanintroductiontoServiceOrientedArchitecture

(SOA)thatUdiDahanhaswritten.







AnIntroductiontoSOA



ByUdiDahan

BothDDDandSOAarerelativelynewconcepts,thefirstbeing

quitewell-defined,andthesecondlessso.Whilethereare

thosewhoclaimthatSOAhasbeenaroundsincetheearly

CORBAdays,neverhastherebeensuchbroadvendorand

industrybuy-infor"justanarchitecture."



SoWhatIsSOAAnyway?

AlthoughanumberofdefinitionsofSOAhavebeenproposed,

noonedefinitionhasbeendeclaredthevictor.Mostdefinitions

arebasedaroundtheideathatsystemsarecomposedof

independentservices.However,whatexactlyconstitutesa

serviceisunclear.OnedefinitionofSOAthatcannotberefuted

isthatSOAisawaytodevelopsoftware.Specifically,SOAdeals

withsystemsorapplicationsthatare,orcanbe,distributed.

Theacknowledgementthatdistributionisaprimary

architecturalissueisoneoftheunderlyingcurrentsofSOA.



WhyDoWeNeedSOA?

Softwarethatismeanttoruninadistributedenvironment

needstobedesigneddifferently.Thisisafundamentalshift

fromdistributedobjectthinkingwhereapplicationswoulduse

non-localresources"transparently,"withnoknowledgeofthe

locationoftheseresources.Theproblemsthatarosewith

distributedobjectarchitectureswereprimarilyfoundin

performance.Thesemanticsofworkingwithlocalandremote



resourcesneedtobedifferent,ahard-learnedlessonthathas

becomealitanyindistributedsystemsdevelopment:"Chunky

overchatty."

Chunkyinterfaces,alsoknownascoarse-grainedinterfaces,

causemoreworktobeperformedinasinglecallthanfinegrainedinterfaces,whichrequiremultiplecallstoperformthe

sameamountofwork.Theexplicitcoordinationandresourcelockingthatneedstotakeplaceoverfine-grainedinterfacesis

totallyencapsulatedinasinglechunkycall.Thisresultsinclient

codethatislesscoupledtotheservercodeimplementation.

Infact,theevolutionofdistributedsystemsarchitecturehas

beenpunctuatedbytheintroductionofnewideasandthe

soberingeffectsofrealityperformance.Despitethefactthat

Moore'slawhasheldovertheyears,andapparentlywill

continuetohold,theworldoflarge-scalesystemsdevelopment

continuestobepreoccupiedwithperformance.However,itis

notsomuchperformanceasastaticmeasurethatis

interesting,butratherscalability,thedynamicmeasureof

performanceovervaryingloads,thatarchitectsstriveto

maximize.

SOAisthenextstepontheladderofarchitecturalevolution

thatwillenablenewsystemstobebuilt,andoldersystemsto

beutilized,inscalablesolutions.



HowIsSOADifferent?

Whilecurrentdistributedsystemsdevelopmentpracticesdesign

layersanddeploytheminphysicaltiers,SOAunifiesthesetwo

conceptsinto"services,"whichareboththeunitofdesignand

deployment.TheotheraspectthatdifferentiatesSOAfrom

currentpracticeisthecodificationofcommunicationbetween

services;whiletherearenorestrictionsonhowlayersortiers

shouldcommunicate,servicesmustcommunicateaccordingto



message-exchange-patternsdefinedbyaschema.Thereisalso

boththeoreticalandpracticalsupportforusingonlyone-way

asynchronousmessagingforinter-servicecommunication;

however,thishasnotyetwonindustry-widesupport.



Note

Notethat"schema"doesn'tnecessarilydictateXML,

butratherthesetofmessagesthatflowbetween

services.

WhileXML,andSOAPbyextension,arenot

prerequisitesofSOA,theextensibilityofXMLmakes

theversioningofschemamucheasier.



WhatIsaService?

Besidesbeingboththeunitofdesignandtheunitof

deployment,servicesaresurprisinglyill-definedforthesizeof

thebuzzsurroundingSOA.Insteadofdefiningwhataserviceis,

mostoftheliteraturedescribespropertiesofservices.Onesuch

exampleisthefourtenetsofServiceOrientation:

Servicesareautonomous

Serviceshaveexplicitboundaries

Servicesexposeschemaandcontract,notclassortype

Servicecompatibilityisdeterminedbasedonpolicy



Tài liệu bạn tìm kiếm đã sẵn sàng tải về

Chapter 10. Design Techniques to Embrace

Tải bản đầy đủ ngay(0 tr)

×