Tải bản đầy đủ - 0 (trang)
Chapter 1. Values to Value: Or Embarrassing Ramblings When Self-Reflecting on the Last Few Years

Chapter 1. Values to Value: Or Embarrassing Ramblings When Self-Reflecting on the Last Few Years

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

OverallValues

Inthepast,Iwasverygoodatplanningahead.Ioftenadded

functionality,structures,andmechanismstomyprojects

proactively.Thatpartusuallyturnedoutprettywell,butIoften

forgotabouttheartifactsaddedonthatnevercametoany

gooduse.Ofcourse,Iaddedloadsofthem,too.Thecostwas

prettylarge,bothindevelopmenttimeandinincreased

complexity.

Overthelastfewyears,we'vebeenencouragedtouseanother

approach:"Dothesimplestthingthatcouldpossiblywork."Toa

largeextent,theideacomesfromtheExtremeProgramming

(XP)movement[BeckXP].Anotherfairlysimilarwaytoputitis

"YouAren'tGoingtoNeedIt"(YAGNI),whichisagoodwayof

helpingyoustayinline.Iguess"KeepItSimpleStupid"(KISS)

couldgohere,too.

Bothapproachesarekindofthetwoextremes(addallyoucan

thinkofupfrontversusdothesimplestthing),butIthinkthey

bothmisssomethinginthattheydon'taddressthetradeoffs

theymake.Justabouteveryquestionregarding"isthisorthat

best"canbeansweredwith"itdepends."It'sabouttradeoffs.I

tendtopreferanapproachthatissomewhereinthemiddle,

movinginoneortheotherdirectiondependinguponthe

situation.Theword"lagom"isaSwedishwordmeaning

somethinglike"justright"or"nottoomuch,nottoolittle."

Lagomor"tobalance"togetherwithbeingcontextsensitiveare

theoverallvaluesI'dliketovalue,aswellascontinuous

learning.

Let'shaveacloserlookatacoupleofmorespecificareasof

values(architectureandprocessingredients),startingwith

someaimedatarchitecturetogetusintotherightmood.







ArchitectureStylestoValue

Architectsanddevelopersmustmakedesigndecisionsbasedon

therequirementsoftheproject.Ihaven'tcollectedan

exhaustivelistofvaluesregardingarchitecturestyleshere,but

IhavedecidedonafewmainthingsI'dliketocommentonto

someextent,suchasmodelfocus,domainmodels,databases,

distribution,andmessaging.First,Ithinkit'swisetokeepa

modelfocus.



FocusontheModel

Foralongtime,Ihavelikedtheobject-orientedparadigmalot,

butitwasn'tuntilprettyrecentlythatImadethefullmoveto

thatparadigmmyself.Therehavebeenplatformproblemswith

usingtheparadigmbefore,butnowtheplatformsaremature.



Note

Asareviewerpointedout,maturitydependsonthe

platformwearetalkingabout.Ifyoucomefroma

VBbackground,whatwasjustsaidisreasonable,

butifyoucomefromJava,SmallTalk,C#,andso

on,theplatformhasbeenmatureforquitesome

time.



Around13yearsago,Itriedtouseavisualmodelto

communicatemyunderstandingoftherequirementsofa

systemIwasabouttobuild,andIusedsomeOMT[Rumbaugh

OMT]sketches.(OMTstandsforObjectModelingTechniqueand



wasamethodwithaprocessandanotation.Thenotationwas

verysimilartotheoneinUnifiedModelingLanguage,UML,

whichisn'tjustacoincidencebecauseOMTwasthemain

inspirationforthenotationinUML.)Wewerediscussing

multiplicitybetweenclasses,wherebehaviorshouldbelong,and

soon.Irealizedafterafewsessionsthatusingmytechnique

fordiscussionwithexpertusers,insteadoftheirtechnique,was

acompletefailure.Theyansweredmyquestionsrandomlyand

didn'tseeoraddmuchvalueatallinthediscussion.(The

systematlargewasn'tafailure,it'sstillbeingusedandit'sthe

coresystemthere,butthedevelopmentprocessdidn'tgoas

smoothlyasitcouldhave.Ihadtochangemethod.)



UseCaseFocus

Ihavethoughtaboutthatexperienceseveraltimesandhave

actuallyjokedabouthownaïveIwas.Intheyearsfollowing,I

alwaystriedtoplaybythemethodologiesofthetargetgroups;

Imeanthemethodologiesoftheuserswiththeusers,andthe

methodologiesofsoftwaredevelopmentwithdevelopers.One

techniquethatworkedprettywellinbothcampswastheuse

casetechnique[JacobsonOOSE].(Atleastitworkedoutwellin

theinformalmannerofXP[BeckXP]stories,shorttext

descriptions,whichwaswhatIused.Suchadescriptionisa

shortdescriptionofapieceoffunctionalityinasystem.An

exampleis"RegisterOrderforCompanyCustomer.")

Itwasverynaturaltousersandcouldbemadenaturalto

developers,too,soitbecamethebridgingtoolofminefor

years.ThewayIdidthebridgingwastohaveoneclassperuse

caseinthesoftware.

Itdidcometomyattentionthatthankstomywayofapplying

usecases,Ibecameprettyproceduralinmythinking.Iwas

designingalittlebitlikeTransactionScript[FowlerPoEAA],but

Itriedtobalanceitbygeneralizingasmuchbehavioras



possible(oratleastsuitable).

AfewyearsagoIheardIvarJacobsontalkingaboutusecases,

andIwasprettysurprisedwhenIrealizedthathedidn't

encapsulatetheusecasesinclassesoftheirownasIhad

expectedandhaddoneforalongtime.

Anotherthingthatgotmekindofworriedaboutthismethod

wastheconstantstruggleIwashavingwithmyfriendand

Valhalla-developerChristofferSkjoldborgwhenweworkedwith

theDomainModelpattern[FowlerPoEAA].Hesawlittlevaluein

theusecaseclasses,maintainingthattheycouldevengetin

thewaybecausetheymightbecomeahindrancewhenmixing

andmatchingusecaseparts.



DifferentPatternsforDealingwiththeMainLogic

Beforewecontinue,ImustsayafewwordsaboutTransactionScriptand

DomainModel,whichwehavealreadytouchedupon.

MartinFowlerdiscussesthreewaysofstructuringthemainlogicinapplication

architectureinhisbookPatternsofEnterpriseApplicationArchitecture[Fowler

PoEAA].ThoseareTransactionScript,TableModule,andDomainModel.

TransactionScriptissimilartobatchprogramsinthatallfunctionalityis

describedfromstarttillendinamethod.TransactionScriptisverysimpleand

usefulforsimpleproblems,butbreaksdownwhenusedfordealingwithhigh

complexity.Duplicationwillbehardtoavoid.Still,verymanyverylargesystems

arebuiltthisway.Beenthere,donethat,andI'veseentheevidenceof

duplicationeventhoughwetriedhardtoreduceit.Itcropsup.

TableModuleencapsulatesaRecordset[FowlerPoEAA],andthenyoucall

methodsontheTableModuleforgettinginformationaboutthatcustomerwithid

42.Togetthename,youcallamethodandsendid42asaparameter.TheTable

ModuleusesaRecordsetinternallyforansweringtherequest.Thiscertainlyhas

itsstrengths,especiallyinenvironmentswhenyouhavedecentimplementations

fortheRecordsetpattern.Oneproblem,though,isthatitalsohasatendencyto

introduceduplicationbetweendifferentTableModules.Anotherdrawbackisthat

youtypicallycan'tusepolymorphisticsolutionstoproblemsbecausethe

consumerwon'tseetheobjectidentitiesatall,onlyvalue-basedidentities.It'sa

bitlikeusingtherelationalmodelinsteadoftheobject-orientedmodel.

DomainModelinsteadusesobjectorientationfordescribingthemodelasclose

tothechosenabstractionsofthedomainaspossible.Itshineswhendealingwith

complexity,bothbecauseitmakesusageofthefullpowerofobjectorientation

possibleandbecauseitiseasiertobetruetothedomain.UsageoftheDomain

Modelpatternisn'twithoutproblems,ofcourse.Atypicaloneisthesteep

learningcurveforbeingabletouseiteffectively.



Domain-DrivenDesignFocus

Therealeye-openerformeregardingtheusageofusecases

wasDomain-DrivenDesign(DDD)[EvansDDD].(Wewilltalka

lotaboutDDDsoon,butfornow,let'sjustsayit'sabout

focusingonthedomainandlettingitaffectthesoftwarevery



much.)Istillthinkthattheusecasetechniqueisagreatwayof

communicatingwithusers,butDDDhasmademethinkitcan

helpalotifwecanmanagetoactivelyinvolvetheusersin

discussionsaboutthecoremodel.Itcanheadoffmistakesvery

earlyandhelpthedevelopersunderstandthedomainbetter.



Note

"Model"isoneofthoseextremelyoverloadedterms

insoftware.Ithinkweallhaveanintuitiveidea

aboutwhatitis,butI'dliketodescribehowIthink

aboutit.Insteadoftryingtocomeupwiththe

definition,hereinallsimplicity(thiscouldfillabook

ofitsownbytherightauthor)areafewproperties

ofamodelthatyoucancomparetoyourown

understandingoftheterm.Amodelis

Partial

Foracertainpurpose

Asystemofabstractions

Acognitivetool

Also,

Amodelhasseveralpresentations(for

example:language,code,anddiagrams).

Thereareseveralmodelsinplayinasystem.

Ifyouwouldliketoreadmore,verymuchhasbeen

writtenaboutwhatamodelis.Agoodplacetostart

isthefirstpagesinEricEvans'book[EvansDDD].

(AspecialthankstoAndersHessellundandEric



Evansforinspiration.)



Themodelisagreattoolforcommunicationbetween

developersandusers,andthebetterthecommunicationis

betweenthosegroups,thebetterthesoftwarewillbecome,

bothintheshortandthelongrun.

We(includingme)havebeenusingmodelsforever,ofcourse,

butthedifferencebetweenoneofmyoldmodelsandthosethat

havebeenbuiltwiththeideasofDDDisthatmyoldmodels

hadmuchmoreinfrastructurefocusandtechnicalconcept

focus.Mynewmodelsaremuchcleanerfromsuchdistractions

andinsteadfocustotallyonthecoredomain,itsmainconcepts,

andthedomainproblemsathand.Thisisabigmindshift.

Anotherwayofexpressingitisthattechnicalities(suchasuser

interfacefashion)comeandgo.Corebusinesslasts.Andwhen

thecorebusinesschanges,wewanttochangethemodeland

thesoftware.

It'snotrocketsciencesofar,andI'mprobablyjustkickingin

opendoors.Ithink,however,thisliesattheverycoreofhowto

achieveefficientsoftwaredevelopment,andinmyexperienceit

israrelyused.BythisImeanfocusingonthemodel,havinga

model(withdifferentpresentations)thatisusedbybothusers

anddevelopers,andnotgettingdistractedbyunimportant

details.



WhyModelFocus?

I'dliketoexaggeratethisabit.Let'splayagame:Whatkindof

developerwouldbethebestoneforbuildingaverticalsystem

inaspecialfield,let'ssayinfinance?Itgoeswithoutsaying



thatdevelopershouldbetechnicallysavvy,veryskilledand

experienced,haveahugesocialnetwork,andsoon.Itwould

alsobeveryniceifhewasextremelyskilledinthebusiness

domainitselfanditwouldn'thurtifhehadworkedas,say,a

traderfortenyears,ifthat'sthekindofsystemtobebuilt.

Findingdeveloperslikethatdoeshappen,butinmyexperience

it'smoretheexceptionthantherule.Inthecaseofthe

developerbeingabletomoveontoanotherdomainforanew

systemwhenthefinancialsystemisupandrunning,that

exceptionbecomesevenmorerare.Thisisbecausedevelopers

justcan'thavetenyearsofexperienceinlogistics,healthcare,

insurance,andtherest.

Anothersolutioncanbetoletthedomainexpertusersdevelop

thesoftwarethemselves.Thishasbeenanolddreamfor

decades,andtoadegreeit'sslowlybecomingmoreandmore

viableallthetime.Atthesametime,ittakesawaytimefrom

them,timetheyoftencanusebetterfortheircorework.

There'salsotoomanytechnicalproblemsstillinvolved.

Sowhat'sthenextbestthing?Theanswerisobvious(atleast

fromtoday'sstandpoint):makethedeveloperlearnasmuchas

possibleaboutthedomainheorsheisworkingonandadd

userstothepicturetobringthedomainexpertisetotheproject

teamandtoactivelyandconstructivelyworkwithintheproject.

Theuserswouldnotjustsettherequirementsalthoughthatis

alsoveryimportantbutwouldactuallyhelpoutwithdesigning

thecoreofthesystem.Ifwecanmanagetocreatethis

atmosphere,nobodyismoreskilledthanthedomainexpert

useratdecidingonwhatthecoreis,whatthekeyabstractions

are,andsoon.

Ofcourse,asdeveloperswearealsonecessary.Thewhole

thingisdoneincooperation.Forexample,whatmightbeseen

asatinydetailtobusinesspeoplecanbeahugethingtousin

thedomainmodel.Theymightsay:"Oh,sometimesit'slikethis

instead,"andeverythingistotallydifferent,butbecauseit'snot



themostcommonvariant,theythinkit'sunimportant.



TimetoTryDiscussingtheModelwithCustomersAgain

WhywouldInowsucceedindiscussingthemodelwiththe

customerswhenIfailedbefore?Manythingshavechanged.

First,it'simportanttohaveasenseofthecontextandthe

projectgroup.Second,usecasescanhelpalotwhengetting

started,andthenyoucanswitchthefocuslatertothecore

modelitself.Third,buildingsystemsissomethingmanymore

peoplehaveexperienceinandhavebeentaughtaboutnow.

Fourth,tobepicky,themodelrepresentedasgraphical,UMLlikesketchforexampleisnotthemostimportantthingtohave

usersworkon;it'sstilltypicallyarepresentationthat

developerslikebetterthanusers.Whatwearelookingforisthe

ubiquitouslanguage[EvansDDD].

TheubiquitouslanguageisnotsomethinglikeUML,XML

Schema,orC#;it'sanatural,butverydistilled,languagefor

thedomain.It'salanguagethatwesharewiththeusersfor

describingtheproblemathandandthedomainmodel.Instead

ofuslisteningtotheusersandtryingtotranslateittoourown

words,aubiquitouslanguagewouldcreatefewerreasonsfor

misunderstandings,anditwillbecomeeasierfortheusersto

understandoursketchesandactuallytohelpcorrectmistakes,

helpingusgainnewknowledgeaboutthedomain.Ifit's

suitable,youcandiscussubiquitouslanguageinthecontextof

thegraphical/codemodelswiththeusers.Ifnot,youstillhave

themostimportantthingdoneifyoucatchtheubiquitous

language.



Note

EricEvanscommentedonthepreviouswiththe

following:"Somethingtomakeclearisthatthe

ubiquitouslanguageisn'tjustthedomainexpert's



currentlingo.Thathastoomanyambiguitiesand

assumptionsandalsoprobablytoolargeascope.

Theubiquitouslanguageevolvesasacollaboration

betweenthedomainexpertsandthesoftware

experts.(Ofcourse,itwillresembleasubsetofthe

domainjargon.)"



Theubiquitouslanguageissomethingthatyoushouldwork

hardtokeepwell-definedandinsynchwiththesoftware.For

example,achangeintheubiquitousshouldleadtoachangein

thesoftwareandviceversa.Bothartifactsshouldinfluence

eachothers.



IfYouHaveaModelFocus,UsetheDomain

ModelPattern

Ifwehaveagreedonhavingadeepmodelfocusandusing

object-orientation,Ibelievethenaturalresultistousethe

DomainModelpattern[FowlerPoEAA]forstructuringthecore

logicoftheapplicationsandservices.Youfindanexampleofa

smallDomainModelinFigure1-1.



Figure1-1.AnexampleofaDomainModel,an

earlysketchfortheexampleapplication,further

discussedinChapter4,"ANewDefault

Architecture"



Note

Ifyouaren'tuptospeedonUML,Ithinkagood

booktoreadisUMLDistilled[FowlerUMLDistilled].

It'snotessentialthatyouunderstandUML,butI

thinkitwillbehelpfultoknowthebonesbecauseI

willbeusingUMLasasketchtoolhereandthere(of

course,youwillbenefitfromitatothertimesas

well,notjustwiththisbook).



EventhoughFigure1-1showsjustanearlysketchofasmall

domainmodel,Ithinkwecanseethatthemodelexpresses

domainconceptsandnottechnicaldistractions.Wecanalsosee

thatitcontainsseveralcooperatingsmallpieces,whichtogether

formawhole.



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

Chapter 1. Values to Value: Or Embarrassing Ramblings When Self-Reflecting on the Last Few Years

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

×