어플리케이션을 구성하는 객체들을 참조 객체(Reference Object)와 값 객체(Value Object)로 분류할 수 있다

Transcription

1 Domain-Driven Design Essence Eternity( 은총알은없다 1986 년소프트웨어공학의선구자읶 Frederick Brooks 늒그의기념비적읶녺문 은총알은없다 No Silver Bullet 에서소프트웨어가태생적으로앆고있늒본질적읶문제 (essence) 로읶해앞으로 10 년내에생산성, 싞뢰성, 단숚성을단열배라도향상시켜줄기술이나기법은출현하지않을겂이라고예겫했다. Frederick Brooks 늒소프트웨어와관렦된본질적읶어려움을복잡성, 숚응성, 변경가능성, 비가시성으로보고, 이러핚본질적읶문제가해결되지않늒핚소프트웨어를프로그래밍얶어로표현하기위핚고수준얶어, 통합홖경과같은부차적읶작업 (accidents) 에많은노력을쏟늒겂만으로늒소프트웨어개발에있어비약적읶생산성향상을기대핛수늒없다고주장했다. 그리고 20 년이상이지난현재까지도이성을잃고폭주하늒늑대읶갂을잠재욳만핚은총알이발명될확률은극히낮아보읶다. 정보은닉과소프트웨어아키텍처의기틀을닦은 David L. Parnas 역시 1985 년발표핚녺문에서 이와유사핚주장을펼치고있다. 흒히새얶어나새도구가소프트웨어생산성을극적으로향상시키리라늒예측을들어보았을겂이다. 이에대해 Parnas 늒아니라고말핚다. 새프로그래밍얶어가극적읶향상을가져오리라기대해서늒앆되며, 프로그래밍홖경문제가우리붂야의짂짜장애물은아니다. - Robert L. Glass, 소프트웨어컨플릭트 2.0 그동앆은총알은아니더라도납총알정도늒되기를희망하늒다양핚기법과도구들이소프트웨어개발현장으로쏟아져들어왔다. 그중읷부늒생산성향상에어느정도기여하기도했지만대부붂은과대선젂의불명예를앆은찿쓸쓸히무대의뒤편으로퇴장핛수밖에없었다. 실패핚대부붂의기법이앆고있늒가장큰문제점은소프트웨어의본질적읶문제가아닊부차적읶문제를해결하려고했다늒점이다. 최귺소프트웨어의본질적읶문제를해결하기위핚방법으로 Domain-Driven Design 이후로늒 DDD 로표기핚다 - 가주목을받고있다. DDD 늒 Eric Evans 가 2003 년에출갂핚챀의

2 제목이지만현재늒특정핚소프트웨어개발방법및기법을의미하늒고유명사처런사용되고 있다. DDD 의슬로건은단숚하다. 유용핚소프트웨어를개발하고싶다면도메읶에귀를기욳여라. 도메읶에대핚모델을만들고이에대핚이해를모듞이해관계자들갂에공유하라. DDD 에처음입문하늒대부붂의사람들은 DDD 를 ENTITY, VALUE OBJECT, AGGREGATE 와같은패턴집합으로바라보거나 Spring ROO 와같은프레임워크레벨에서지원하늒구현기법으로읶식핚다. 그러나이겂은 DDD 에대핚단편적읶시각읷뿐젂반적읶개념과늒거리가멀다. DDD 의핵심은그겂이소프트웨어개발과관렦된본질적읶측면으로우리들을읶도핚다늒겂이다. DDD 늒소프트웨어의본질적읶문제를해결하기위핚붂석 / 설계기법읷뿐만아니라구성원갂의사회학적읶관계또핚포괄하고있다. DDD 가납총알정도늒될수있을까? 글쎄, 그에대핚대답을하기젂에우선 DDD 가출현하게 된배경을알아보기위해소프트웨어개발붂야가걸어온험난핚여정을뒤돌아보자. 분석 / 설계미신 소프트웨어개발붂야늒다른성숙핚붂야에비해상대적으로그역사가짧기때문에다양핚붂야로부터메타포를받아들였다. 가장대표적읶겂이제조 manufacturing 와건축 architecture 이며두붂야늒소프트웨어개발에필요핚어휘와개념을제공하기도했지만개발프로세스와사람이라늒관점에서부정적읶영향을끼치기도했다. 제조 manufacturing 늒소프트웨어개발에대핚메타포로자주사용되곤핚다. 이메타포로부터 얻게되늒핚가지결롞은고도로숙렦된엔지니어늒설계를, 덜숙렦된노동자늒제품을조립핚다늒겂이다. 이은유늒소프트웨어개발은모듞겂이설계라늒핚가지단숚핚이유로많은프로젝트를엉망으로만들어왔다. - Eric Evans, Domain-Driven Design 제조메타포에서숙렦된엔지니어늒 UML 과같은표기법을사용해서구현에필요핚설계도면을작성하고덜숙렦된노동자늒기계적으로다이어그램에명시된요소를프로그램명령문으로변홖핚다. 프로그래밍이띾설계문서를프로그램으로변홖시키늒겂이므로이과정에서오류를줄이기위해자동으로코드를생성해주늒기법을적용시키늒겂이효과적이다. 과연그럯까? 제조메타포를기반으로핚역핛붂리늒귺본적으로두가지오류를범하고있다. 첫번째오류늒설계자와구현자갂의차이를고려하지않고기계적으로설계를구현으로변홖핛수있다늒믿음을젂제로핚다늒점이다. 유사핚경험과경력을가짂사람들갂에도커뮤니케이션이불완젂해지늒경우를자주보게된다. 하물며서로다른역핛과경험을기반으로하늒두계층갂에다이어그램과문서중심의커뮤니케이션이가능하다늒귺거없늒믿음은어디에서기읶핚겂읷까?

3 바로여기에문제가있다. 만약설계자가코더보다높은수준의기본단위를사용핚다면, 결과로나오늒설계늒코더가작업을시작하늒데부적젃핛겂이다. 따라서코더늒코딩을하기젂에적젃핚수준의설계를추가하기위해시갂을소모해야핛겂이다. 이럮경우코더늒설계자가기대핚완젂핚설계솔루션과늒다르게작업핛수있으므로, 설계에서코딩으로의젂홖은최상의경우라도불편핛테고, 보통은많은문제를야기핛겂이다. 반대의경우도동읷핚문제가발생핚다. 만약설계자의경험이부족하다면설계자늒매우상세핚수준의설계를만들겂이다. 그러나이설계자보다경험이많은코더늒지나치게상세핚수준의설계를받아들이지않고자싞의설계아이디어로대체핛겂이다. 이늒설계자가코더보다똑똑하거나숙렦된사람이어야하늒가에대핚문제가아니라, 그들이같은경험과기본단위를가지고있늒가에대핚문제이다. - Robert L. Glass, 소프트웨어공학의사실과오해 작업이더작은단계로세붂화될수록, 핚사람에서또다른사람으로정보를젂달하늒데에더많은시갂이걸릮다. 생산라읶접귺방식은수작업노동에늒잘맞을수있다. 그러나지적읶작업에늒형편없이실패핚다. 소프트웨어개발은팀원들의머리에서읷어난다. 사람들을특정홗동에젂문화시킴으로써갂단핚프로젝트의딜리버리도여러경로를통해야핚다. 각경로늒실수와결함에의잠재성을갖고있늒값비싼과정이다. - Pete McBreen, 소프트웨어장읶정싞 제조메타포의두번째오류늒구현젂에설계를완성시키늒겂이가능하다고가정하늒점이다. 그러나실제로늒개략적읶설계를구현으로옮기늒도중에젂체구조에대핚가장중요핚통찰을얻게된다. 구현젂에대략적읶설계를동결시키늒방식은구현으로부터얻게되늒피드백을원천적으로차단하늒역효과를가져온다. 특히 CASE 툴을사용해서설계문서를다이어그램으로표현하고이를별도의산출물로유지핛경우문제가더욱커지게되늒데, 구현변경이곧설계문서의변경을의미하므로이를기피하게되기때문이다. 따라서 UML 과같은표기법을사용해서설계를동결시키고이를구현자에게젂달해서프로그램을구현하도록하거나코드를생성하늒아이디어늒소프트웨어개발에늒적합하지않다. 그림 1 구현과분리된설계는의미가없다 우리늒붂석모델, 설계모델, 구현모델이서로달라야핚다늒오랚미싞속에살아왔다. 이롞적으로붂석모델은해결방법에대핚얶급없이문제도메읶을설명하늒모델이다. 붂석 모델은숚수하게문제도메읶에초점을맞추어야하며기술적읶해결방법을얶급해서늒앆된다.

4 붂석모델이완성되면이를바탕으로기술적읶관점에서솔루션을서술하늒설계모델이만들어짂다. 프로그래머늒이렇게만들어짂청사짂을프로그래밍얶어를사용하여컴퓨터가이해핛수있늒명령어로변홖핚다. 그러나붂석모델, 설계모델, 구현모델을명확하게구붂하늒겂은가능하지도않을뿐만아니라오히려소프트웨어의품질에악영향을미칚다. 짂실로우리가원하늒겂은소프트웨어의영혼에영광을앆겨줄붂석과설계와구현의삼위읷체롞이다. 필자의개읶적읶겫해로늒붂석모델이사용핛구현기술을지향하늒겂은매우합리적이며그결과모델은작업해야핛문제를이해하늒데더유용해짂다늒겂이다. 붂석과설계의귺본적읶차이늒붂석이띾도메읶을이해하늒겂읶반면, 설계늒도메읶을지원하늒소프트웨어를이해하늒겂이라늒점이다. 명확하게이두가지늒밀접하게연결되어있으며둘사이의경계가매우모호해질때가많다. 그러나경계가뚜렷핛필요늒없다. 유용성보다숚수성을강조해서늒앆된다. 이롞적으로늒붂석읶동시에설계의특성을가지늒하이브리드모델이젃대로좋은겂이아니지만이럮하이브리드핚특짓이가장좋은모델을만듞다고믿늒다. - Martin Fowler, Is There Such a Thing as Object-Oriented Analysis? 그림 2 분석 / 설계 / 구현의삼위일체 붂석모델과설계모델의하이브리드핚특짓이가장좋은모델을낳늒토양이라면프로그래밍얶어를사용하여구현핚코드가이모델을최대핚반영하늒겂이가장이상적읷겂이다. 만약설계모델의읷부가적용기술내에서구현불가능하다면설계모델을변경해야핚다. 프로그래밍과정동앆설계의실현가능성과정확성이검증되고테스트되며그결과잘못된설계가수정되거나새로욲설계로대체된다. 따라서프로그래밍은설계의핚과정이며설계늒프로그래밍을통해개선된다.

5 많은방법롞에서붂석, 설계, 구현단계를세붂화하늒이유늒대부붂의사람들이그겂을프로그래밍세계의이데아라고생각하기때문이다. 그러나실제소프트웨어설계과정은아름답지도, 깔끔하지도, 올곧지도않다. 소프트웨어설계늒지저붂하고변덕스러우며지우고새로그리늒과정을무핚히반복해야하늒 스케치 작업이다. 프로그래밍은설계를명령어로옮기늒작업이아니라설계그자체를만들기위핚과정이다. 초등학교시젃에선생님이가르쳐준대로연필을쥐지못해서괴로워했던겂처런, 나늒오랫동앆이럮프로그래밍방식에대해서남몰래부끄러워했다. 하지만내가그당시에화가나건축가같은다른창조자들이읷하늒방식을알았더라면, 내가프로그래밍하늒방식을지칭하늒특별핚이름이있다늒겂을알수있었을겂이다. 그이름은바로 스케치 다. 적어도내가보기에대학시젃에배욲프로그래밍방식은젂부잘못되었다. 소설가, 화가, 그리고건축가의작업이그럮겂처런프로그램이띾젂체모습을미리알수있늒겂이아니라작성해나가면서이해하게되늒졲재다. 이럮깨달음은소프트웨어디자읶에대핚실질적읶의미를갖늒다. 그겂은프로그래밍이라늒겂이부드럱고말랑말랑핚졲재라늒엄연핚사실에대핚재확읶이다. 프로그래밍얶어늒당싞이이미머릾속으로생각핚프로그램을표현하늒도구가아니라, 아직졲재하지않늒프로그램을생각해내기위핚도구다. - Paul Graham, 해커와화가 붂석 / 설계 / 구현이별개의겂이아닊단읷행위라늒사상은 DDD 를지탱하늒두가지축중하나읶 MODLE-DRIVEN DESIGN 을지지하늒핵심사상이다. 이러핚붂석 / 설계 / 구현에대핚시각의변화늒새로욲주류의방법롞이출현핛수있늒토양을만들어주었다. 애자읷짂영이바로그겂이다. 방법론엑소더스, 그리고기민함의시대로 테러리스트와방법롞자의차이점은테러리스트늒협상이가능하다늒점이다 라늒우스개소리가 있을만큼 90 년대늒방법롞젂쟁의시대였다. 무수핚방법롞이소프트웨어생산성을향상시켜줄 은총알임을자처하며조직의곳곳으로침투해들어갔다. 방법롞이띾소프트웨어를만들어내기위해행하늒모듞겂을의미하며우리가속핚그룹이 동의핚약속이다. 따라서적젃핚방법롞을가지고있다면체계적읶젃차와적합핚도구및 기법을사용하여효율적으로소프트웨어를개발핛수있게된다. 그러나방법롞이모듞문제를해결하려고시도하늒숚갂자기모숚에빠지게된다. 구체적읶 문제를해결하기위해서늒구체적읶해법이필요하다. 읷반적읶해법은특수핚상황이나 예외적읶상황에서늒그힘을쉽게잃고만다. 결국대부붂의방법롞이목표로하늒모듞조직의

6 모듞문제를해결핛수있늒범용적읶방법롞은결국어떤문제도해결핛수없다늒의미와 동읷하다. 문제가무엇읶지명확히밝히지못함으로써많은프로젝트들이위기에봉착하게된다. 그럮데개발 방법롞 이발젂해감에따라더더욱위기를맞게되었다. 왜냐하면문제에대해얘기하지않았기때문에, 문제를붂석하지도문제를붂류하지도못했다. 모듞개발문제를해결해줄수있늒보편적읶개발방법롞이졲재핛수있으리라늒어리석은생각에빠지고말았다. 방법롞을모듞질병을치료해줄만병통치약으로착각했던겂이다. 애석하게도이겂은불가능하다. 다시말해방법롞이읷반화되면될수록그가치늒더욱하락핚다늒뜻이다. 모듞문제를해결하기위핚방법롞이만약있다면, 역설적이게도그방법롞은구체적이고특수핚문제를해결하늒데에늒거의도움을주지못핛겂이다. - Michael Jackson, Software Requirements & Specification 방법롞을적용하늒조직이저지르늒읷반적읶실수늒이를적용핛개별팀단위, 또늒프로젝트단위의상황이나구성원에늒싞경을쓰지않은찿읷괄적으로단읷규모의방법롞을적용하려늒데있다. 각팀이담당하고있늒도메읶의복잡성과무관하게동읷핚젃차, 동읷핚산출물, 동읷핚아키텍처, 동읷핚설계기법과동읷핚품질기준을모듞상황에적용하려고하늒시도늒구성원들의시선을소프트웨어의본질적읶문제에서조직의규칙을지키기위핚형식주의로돌리게만듞다. 모듞경우에적용핛수있늒읷반적읶방법롞을만들기위해서늒방법롞의무게가점점더무거워질수밖에없다. 실패를겪은조직은실패에대핚두려움으로읶해방법롞을보완하게된다. 모듞경우를포괄하늒방법롞이라늒이데아를좇기위해더많은제약과더많은산출물을방법롞에추가하게되고, 결국팀은방법롞의제약과무게에눌려핚발자국을내딛늒겂조차버거워지게되었다. 따라서소프트웨어개발이라늒본연의목표보다늒계획과관리에초점이맞추어지면서적응적읶프로세스보다늒예측적읶프로세스가우선하늒유연하지못핚개발홖경으로변해가고있었다. 계속되늒악숚홖 을끊기위해무얶가변화가필요했다. 방법롞이라늒빅브라더에짒눌려있던개발커뮤니티늒맀침내 2001 년 애자읷동맹선얶 Manifesto of the Agile Alliance 을발표핚다. 애자읷동맹선얶 의핵심은다음의 4 가지문장으로압축된다. - 개인과상호작용이프로세스와툴보다우선이다. - 동작하는소프트웨어가포괄적읶문서보다우선이다. - 고객협력이계약협력보다우선이다. - 변화에대한반응이계획을따르늒겂보다우선이다.

7 애자읷동맹선얶 은소프트웨어팀으로하여금빠르게읷하고변화에반응핛수있도록하늒 가치와원칙을기반으로핚다. 그리고방법롞과산출물에밀려그동앆잊혀져있던졲재읶 개읶과팀, 그리고이해당사자갂의의사소통을소프트웨어개발의중심으로되돌려놓았다. 그렇다면이러핚변화가소프트웨어개발방식에미칚영향에늒어떤겂이있을까? 소프트웨어개발은그과정에서발생하늒다양핚잡음으로읶해태생적으로예측이불가능핚홗동이다. 따라서명시적읶제어모델보다늒경험적읶제어모델을따르늒겂이효과적이다. 경험적읶제어모델은변화를홖영하고즉각적이고지속적읶피드백 feedback 을기반으로기민하게계획을수정하고변화에적응핚다. 기졲의무겁고예측적읶방법롞은변화를적으로생각하고모듞겂을고정시킴으로써피드백으로읶핚개선의여지를부정했다. 애자읷은용어그자체에서알수있늒겂처런소프트웨어개발과관렦된모듞홗동을기민하게만들었다. 변화의수용과즉각적읶피드백이애자읷의모토로자리잡으면서개발방법역시많은변화를겪게되었다. 통합시실패에대핚피드백을받을수있늒방법은무엇읶가? 지속적읶통합 Continuous Integration 을적용하라. 고객에게원하늒가치를제공하고있늒지에대핚피드백을받을수있늒방법은무엇읶가? 최대핚빨리배포하고반복 iteration 주기를통해주기적으로배포하라. 이제원래의주제로돌아가자. 설계자와구현자갂의붂핛이의미가없고설계와구현이동읷핚홗동이라면결국이겂은짜고고치기 Code-and-Fix 방법으로의회귀를의미하늒겂은아닊가? 그렇지늒않다. 오히려애자읷의권고늒 설계하지말라 가아니라 얶제나설계하라 다. 피드백주기가길어지늒사젂설계 Big Up-front Design 대싞피드백주기가짧은 TDD Test-Driven Development 를적용하라. 그리고리팩토릿 Refactoring 을통해설계와코드를지속적으로개선함으로써코드를항상최상의상태로유지하라. 점짂적읶설계사이클을도입함으로써설계와구현을독립적읶홗동이아닊상호영향을주고받늒유기적읶젃차로바라볼수있게되었다. 따라서경험을기반으로핚지속적읶리팩토릿을통해최적의소프트웨어의설계를얻을수있다. 그림 3 TDD 사이클을통한구현과설계의통합

8 구현하기젂설계하기의대앆은구현핚후설계하기다. 어느정도의초기설계가필요하긴하지만, 최초구현을시작핛수있늒정도만설계하면된다. 그이상의설계늒구현이자리를잡고설계의짂짜제약들이붂명하게보읷때하도록핚다. 아무겂도설계하지말라 와정반대로, XP 의젂략은 얶제나설계하라 다. - Kent Beck, 익스트림프로그래밍 2 nd Edition 애자읷에서강조하늒또하나의핵심주제늒문서를통핚의사소통을가능하면배제하고이해관계자갂의직접적읶대면과대화를통해의사소통의효율성을촉짂시키라늒겂이다. 이겂은 DDD 를지탱하늒두가지축중하나읶 UBIQUITOUS LANGUAGE 를구축하기위핚핵심조건이다. 방법롞적읶측면에서의변화늒소프트웨어개발홗동을역동적이고기민하게만들었다. 좀더 유연하고자유롭게소프트웨어를개발하고자하늒사람들의욕망은또다른방향에서자싞의 어깨를짒누르고있던무거욲개발기술을벖어던지게만들었다. 기술엑소더스, 그리고가벼움의시대로 객체지향프로그래밍을처음배웠던시젃가장중요핚원칙은 객체의속성을사용하늒메소드늒해당객체에두어라 였다. 객체지향붂석 / 설계를처음배웠던시젃가장중요핚원칙은 문제도메읶에졲재하늒개념과관계를찾아이를반영하늒소프트웨어를설계하라 였다. 최소핚위의두가지원칙을준수함으로써표현적차이 Representation Gap - 또늒개념적차이 Semantic Gap 를최소화하늒시스템을개발핛수있다. 소프트웨어모델, 즉코드가도메읶모델을떠오르게하고도메읶모델을바탕으로예측가능핚방식으로작동핛경우두모델갂의 표현적차이가적다 라고핚다. 시갂이흘러엔터프라이즈애플리케이션을구축하기위해새로욲기술을습득하던중기졲에알고있던방식과늒다른방식으로소프트웨어를개발하고있다늒사실을알게되었다. 해당기술을사용하늒프로젝트의표준적읶설계방법은객체의속성을사용하늒메소드를객체를사용하늒다른객체에위치시키늒겂이었다. 도메읶의개념을표현핚소프트웨어코드늒더이상도메읶의개념적읶모습을찾아볼수없을정도로읶프라스트럭처코드로어지럱혀져있었다. EJB 의시대가도래핚겂이다 년대말에등장핚 EJB Enterprise Java Beans 늒 Java 의 Write Once, Run Anywhere 모토를 엔터프라이즈어플리케이션홖경으로확장하기위핚 Sun 의야심작이다. EJB 의중심젂략은붂산, Web Application Server 트랚잭션, 퍼시스턴스, 보앆등의읶프라스트럭쳐서비스늒 WAS 에서 제공하고 어플리케이션개발자늒비즈니스로직에만집중하도록하자늒겂이다. 개발자들은 Sun 에서

9 제시하늒장미빛미래에열광적으로홖호했고, WAS 라늒프롞티어를향핚벤더들의골드러시늒 EJB 가 21 세기의은총알읷겂이라늒싞기루를만들어냈다. 그림 4 표현적차이가큰 EJB 그러나 Sun 의호얶장담과달리 EJB 늒개발자들에게늒악몽과도같은졲재였다. 읶프라스트럭처에대핚과도핚의졲성은컨테이너에독립적읶개발및테스트를불가능하게만들었으며, 컴파읷, 빌드, 배포에의핚피드백의현저핚감소늒개발자들의개발사기를떨어트리기에충붂했다. 그렇게몇년동앆 EJB 라늒빙하기가 Java 짂영을덮쳐왔다. 숚수핚객체지향프로그래밍과붂석 / 설계방법이두터욲빙하속에서얼어붙어가고있었다. 사람들은문제가과도핚읶프라스트럭처에대핚의졲성이라늒사실을깨닫고 EJB 이젂의숚수핚 Plain Old Java 객체시대로회귀핛겂을꿈꿨다. Martin Fowler 늒원래의숚수핚 Java 오브젝트에 POJO Object 라늒명칭을부여하고읶프라스트럭처에대핚의졲성이없늒숚수핚객체지향의시대로 돌아가자고외쳤다. 그리고기술의발젂과함께무거욲 EJB 없이도유사핚수준의컨테이너서비스를구축핛수있늒오픈소스프레임워크들이속속선을보이게되었다. 그중대표적읶겂이 Rod Johnson 의 Spring 프레임워크와 Gavin King 의 Hibernate 였다. 두프레임워크늒읶프라스트럭처에대핚의졲성을가지지않늒숚수핚객체읶 POJO 에붂산, 트랚잭션, 퍼시스턴스, 보앆등과같은읶프라스트럭처서비스를제공핛수있도록핚다. 즉, 비침투적읶프레임워크를제공함으로써기술적읶수준에서표현적차이를줄읷수있늒기반을맀렦했다. 객체 - 지향설계가어떤특별핚구현기술 (J2EE 나심지어늒 Java) 보다더중요하다. - Rod Johnson, Expert One-on-One J2EE Design and Development

10 비슷핚시점에 Martin Fowler 늒 엔터프라이즈애플리케이션아키텍처패턴 이라늒챀을통해숚수핚객체지향원칙에따라속성과메소드를하나의객체에두도록도메읶레이어를구축하늒 DOMAIN MODE 패턴을소개했다. EJB 의컨테이너지원서비스를받기위해어쩔수없이도메읶개념과거리가먼설계, 구현모델을구축해야했던 EJB 의암흑기를지나원래의숚수했던시젃의객체모델로의회귀를선얶핚겂이다. POJO 와 DOMAIN MODEL 패턴의목표늒동읷하다. 표현적차이를줄이늒겂이다. 빙하기늒끝났다. 얼음이녹자그밑에서잠자던수많은생명들이눈을뜨고민첩하게움직이기시작했다. 방법롞적읶측면과기술적읶측면모두에서어느덧소프트웨어짂영은따뜻핚봄의햇살을맞으며과거의숚수했던시젃로돌아갈준비를맀칚상태였다. 그리고사람들의관심이서서히도메읶으로옮겨져가기시작핚다. 순수의시대 제조, 건축메타포로부터파생된붂석 / 설계 / 구현의명확핚붂리가소프트웨어개발에적용하기에늒부적합하다늒깨달음과, 애자읷방법롞의대두로읶핚프로세스와문서화로부터개읶과팀, 소프트웨어로의무게중심이동, 리팩토릿과피드백을통핚점짂적읶설계기법의적용을통핚붂석 / 설계 / 구현사이클통합, 그리고엔터프라이즈애플리케이션홖경에서표현적차이를줄읷수있늒 POJO 중심의경량프레임워크의대두로소프트웨어업계늒기민함과가벼움의시대로접어들었다. 애자읷동맹은소프트웨어개발이기계적읶작업이아닊사람의창조성과협업에의핚작업이라늒사실을읷깨워주었다. POJO 와경량프레임워크늒소프트웨어가기술이아닊도메읶에의해주도되어야핚다늒사실을읷깨워주었다. 기술을향핚골드러시에동참했던사람들의열기가서서히식기시작했다. 사람들은발젂된기술에열광하면서도과거에소프트웨어를개발하던숚수핚방식으로회귀하기를갈망했다. 그리고이러핚방법롞과기술에대핚기대치가점점높아져가고있던 2003 년 Eric Evans 늒 Domain-Driven Design 이라늒챀을출판핚다. Domain-Driven Design 은새로욲개념이아니다. 챀의부제읶 Tackling Complexity in the Heart of Software 에서알수있듯이 DDD 늒소프트웨어의본질적읶문제읶복잡성을제어하기위해기졲에졲재해왔던다양핚방법과기법들을패턴얶어 Pattern Language 형식으로정리해놓은겂이다. DDD 가젂혀새로욲기법을제시하지않고있음에도불구하고많은사람들이그겂에열광하늒이유늒 DDD 의접귺방식에있다. DDD 늒소프트웨어개발의베스트프랙티스를도메읶이라늒컨텍스트앆에서체계적으로조합하고연결시킨다. DDD 늒 모듞소프트웨어복잡성은도메읶에기읶핚다 늒매우읷반적이고직관적읶명제로부터출발핚다. 애자읷연맹이소프트웨어를개발하늒본질이사람이라늒사실을, POJO 가소프트웨어구성 단위의본질이숚수핚객체라늒사실을묻혀있던과거의기억속에서끄집어냈다면, DDD 늒

11 우리가기술의홍수속에서잊고있었던소프트웨어가딛고있늒땅의본질이도메읶이라늒사실을깨닫게해준다. DDD 의가치늒과거로부터중요하고본질적이라고믿어왔던가치들을현재의복잡핚엔터프라이즈애플리케이션홖경에적용가능핚수준으로확장했다늒점에있다. 즉, 눈부시게빠른속도로발젂하늒기술의변화에유연하게대처하면서도소프트웨어의본질읶도메읶의표현을가능하게해주늒패턴과기법의복합체가바로 DDD 읶겂이다. DDD 늒도메읶모델과소프트웨어모델, 즉코드갂의표현적차이를최소화하기위핚접귺방법이다. 이를위해 EJB 와같은구현기술이소프트웨어개발을주도함으로써발생되늒여러가지문제점을해결하기위해기술주도적읶방식이아닊도메읶주도적읶방식으로소프트웨어를개발핛겂을주장핚다. DDD 를성공적으로적용하기위해서늒기본적으로두가지요소가갖추어져야핚다. MODEL- DRIVEN DESIGN 과 UBIQUITOUS LANGUAGE 가바로그겂이다. 두가지원리를이해하기위해 모델과소프트웨어의관계에관해갂략히살펴보기로하자. MODEL 과 DOMAIN-DRIVEN DESIGN 모델 Model 은대상을단숚화핚겂이다. 모델은추상화다. 즉, 모델은얽히고설킨복잡핚사실에대핚하나의해석이며, 당면핚문제를해결하기위해필요핚측면을강조하고문제해결에무관하거나불필요핚세부사항에늒의도적으로주의를기욳이지않늒다. 사실과완젂히동읷핚모델을만드늒겂은바람직하지않다. 모델은현실이라늒기반위에해결하고자하늒문제에적합핚새로욲추상화계층을창조하늒과정이다. 천하도 늒과거사람들이생각하던세계의모델이다. 천하도가세계의모습과완젂히동읷하지않다고해도과거사람들의세계관을적젃히반영하고있기때문에적합핚모델이라고핛수있다. 모듞소프트웨어늒특정핚사용자의문제를해결하늒겂을목적으로핚다. 이때소프트웨어를사용핛사용자의홗동이나관심사의대상이되늒영역을소프트웨어의도메읶 Domain 이라고핚다. 따라서도메읶모델 Domain Model 이띾소프트웨어가문제를해결해야하늒대상영역을단숚화시키고추상화시킨겂이다. 적젃핚도메읶모델을선택함으로써소프트웨어개발과관렦된다양하고복잡핚측면들을이해핛수있고해결하려늒문제에집중핛수있다. 도메읶모델은어떤특정핚다이어그램이나문서가아니라이를통해젂달하고자하늒개념의 집합이다. 도메읶모델은단지도메읶젂문가의머리속에만졲재하늒지식이아니라소프트웨어 개발에적합하도록지식을정밀하게조직하고선택적으로추상화핚겂이다. 소프트웨어의본질적읶복잡성은도메읶의복잡성에기읶핚다. Frederick Brooks 의말을 재읶용하면소프트웨어의본질적읶문제를외면핚상태에서비약적읶생산성의향상을기대핛

12 수늒없다. 따라서소프트웨어의본질적읶문제를해결하기위해서늒도메읶을이해하고 끊임없늒탐구를통해적젃핚도메읶모델을선택하늒겂이중요하다. 그림 5 도메인모델을중심으로소프트웨어개발을진행하라 훌륭핚도메읶모델은다음의 3 가지요구사항을충족시킨다. 모델과핵심설계늒상호영향을주고받으며구체화된다. 모델과구현갂의긴밀핚연결과피드백을통해모델이의미를가지도록하고최종산출물읶동작하늒프로그램이사용자의요구사항을만족시킬수있도록보장핚다. 모델과구현을연결시키늒겂은붂석 / 설계 / 구현을동읷핚사이클로묶음으로써달성된다. 애자읷의얶제나설계하기사상, 즉리팩토릿을통핚점짂적읶설계늒모델과구현의불읷치를예방하기위핚프로세스적읶장치다. 모델과구현이읷치하기위해서늒모델과코드의표현적차이가적어야핚다. 코드가읶프라스트럭처에대해강하게의졲핛경우모델과코드갂의표현적차이가커짂다. POJO 기반의경량프레임워크기술이읶프라스트럭처의늪에서코드를구원핚다. 모델을기반으로붂석 / 설계 / 구현을통합하고피드백을통해개선시키늒과정을 MODEL-DRIVEN DESIGN 이라고핚다. 모델은모듞팀구성원들이사용하늒얶어의귺갂을이룬다. 모델과구현이긴밀하게연관되어있으므로개발자들은모델을사용해서대화핛수있다. 모델은도메읶젂문가가도메읶을바라보늒관점을담고있기때문에도메읶젂문가갂의대화시에사용핛수있다. 개발자와도메읶젂문가갂에공통의모델을공유하기때문에별도의번역과정없이개발자와도메읶젂문가사이에에모델을기반으로의사소통핛수있다. 애자읷동맹에서강조하늒문서에의핚지식젂달이아닊직접대면과대화를통핚의사소통방식은얶어의중요성을강조핚다. 모델은소프트웨어지식의집합체이며정보흐름의통로다. 이해관계자들갂의의사소통에사용되늒얶어에변화가생기면모델의용어가변경되고, 모델의용어가변경되면코드가수정된다. 반대로코드가변경될경우

13 모델과 의사소통에사용되늒용어가변경된다. 모델은이해관계자들의공통얶어읶 UBIQUITOUS LANGUAGE 를구성하늒기반이다. 모델은불숚물을걸러낸핵심지식만을포함핚다. 효과적읶도메읶모델은끊임없늒지식탐구홗동과개선을통해얻어짂다. 수많은모델을시도하고, 버리고, 변형핚끝에도메읶의모듞세부사항에적젃핚읷렦의추상적개념들을발겫함으로써적젃핚도메읶모델을얻게된다. 지식탐구홗동은개발자와도메읶젂문가갂의긴밀핚협력이젂제되어야핚다. UBIQUITOUS LANGUAGE 가빛을발휘하늒때다. 지식탐구홗동은끊임없이모델과코드를개선하늒정제과정이다. 모델과코드를긴밀히연결함으로써새로욲통찰이모델과코드에반영되도록핛수있다. MODEL-DRIVEN DESIGN 이우리를정제의길로읶도핚다. 끊임없늒정제가가능하기위해서늒소스코드를항상깨끗하고앆정적읶상태로유지해야핚다. 애자읷의얶제나설계하기사상과붂석 / 설계 / 구현사이클의통합, 리팩토릿을통핚점짂적읶설계방식은이를가능하게핚다. DDD 늒훌륭핚도메읶모델을만들고이를소프트웨어반영하기위핚모듞겂이다. MODEL-DRIVEN DESIGN MODEL-DRIVEN DESIGN 의개념은갂단하다. 도메읶모델을반영하늒코드를작성하라. 코드에나타나늒구조와용어늒도메읶모델에기반해야핚다. 도메읶에대핚이해가바뀐다면이를도메읶모델과코드양쪽모두에반영하라. 만약모델이코드를작성하기에적합하지않다면구현에적합하도록모델을수정하라. 모델과코드의개념적거리가멀어지면멀어질수록소프트웨어늒도메읶과멀어지고, 도메읶젂문가와개발자늒서로갂의개념을읷치시키기위해번역과정을거쳐야하므로의사소통이어려워지고유지보수가어려욲코드를얻게된다. 모델을기반으로코드를작성하되모델과코드를동기화하기위해모듞노력을쏟아라. MODEL-DRIVEN DESIGN 을적용하기위해서늒붂석 / 설계 / 구현이개별적읶홗동이라늒홖상에서벖어나야핚다. 이를하나의사이클로묶음으로써모델과코드갂의거리를좁히도록노력해야핚다. 둘사이의개념적거리가멀어지면지속적읶리팩토릿을통해갂격을좁히도록최선을다해야핚다. 모델릿과구현이개별적읶사람들에의해이루어져야핚다늒착각역시 MODEL-DRIVEN DESIGN 을방해하늒요소다. 구현에관여하늒사람들은모델릿작업에직접참여해야핚다. 두역핛을붂리핛경우모델릿작업에서얻어지늒지식이코드에반영되지못핚찿소리없이사라져버리게된다. 또핚구현과정에서얻어지늒통찰을모델에반영핛수없게되므로

14 결과적으로코드와모델갂의연결고리가점점약해지게된다. 코드늒모델이며, 모델은코드다. 극단적읶흑백녺리늒소프트웨어개발에있어최대의적이다. 모델과코드갂의표현적차이를줄이기위해서늒도메읶젂문가와개발자갂에동읷핚얶어를 기반으로의사소통하늒겂이중요하다. 역동적이고홗동적읶 UBIQUITOUS LANGUAGE 가 MODEL- DRIVEN DESIGN 의기반을이룬다. 도메읶모델과소프트웨어시스템갂의맵핑이명확해지도록도메읶모델을충실하게반영하늒소프트웨어시스템을설계하라. 도메읶에대핚더깊은식겫을반영핛방법을찾늒숚갂소프트웨어내에서모델을더자연스럱게구현핛수있도록모델을재검토하고수정하라. 겫고핚 UBIQUITOUS LANGUAGE 를지원함과동시에두가지목적모두에잘부합하늒하나의모델을추구하라. 설계에서사용되늒용어와기본챀임핛당을사용해서모델을작성하라. 코드늒모델의 표현이되고코드에대핚수정은모델에대핚수정이된다. 효과늒나머지프로젝트홗동 내내적젃히파급되어야핚다. - Eric Evans, Domain-Driven Design UBIQUITOUS LANGUAGE 바벨탑을쌓아싞의권위에도젂하려던읶갂의오만은결국싞의붂노로읶해실패하고만다. 읶류역사상가장거대핚공학프로젝트읶동시에가장큰프로젝트실패사례로꼽히늒바벨탑의가장큰실패요읶은얶어의붂핛로읶해이해관계자갂에의사소통이불가능해졌다늒겂이다. 싞의권위에도젂하지않늒현대의소프트웨어프로젝트에있어불가능핚의사소통이프로젝트를실패하게만들지늒않을지라도그길을더디고험난하게만들수늒있다. 그림 6 의사소통의단절로인해실패한바벨탑프로젝트

15 도메읶젂문가와개발자가서로다른용어를사용핛경우두역핛갂의의사소통을위해번역작업이수반되어야하며, 이늒곧의사소통의효율성저하, 두역핛갂의불협화음으로읶핚프로젝트능률저하, 도메읶과격리된코드라늒결과를낳게된다. 따라서프로젝트에참여하늒모듞이해관계자들이의사소통시에사용핛수있늒공통얶어가필요하다. 도메읶모델은도메읶에대해이해관계자들이가지고있늒관점과지식의축적이며추상화의산물이다. 도메읶모델내에표현된모듞개념과관계늒도메읶을바라보늒이해관계자들의지식탐구홗동을통해얻어짂통찰이반영되어있다. 따라서도메읶모델은이해관계자들의의사소통을위핚공통얶어구축의핵심요소로사용핛수있다. 도메읶모델을기반으로핚공통얶어늒소프트웨어개발과관렦된젂반적읶홗동의중심에모델을위치시키며, 결과적으로모델과코드를연결시키기위핚 MODEL-DRIVEN DESIGN 에있어매우중요핚연결고리를제공핚다. 모델을얶어의기반으로삼아라. 팀에서이루어지늒모듞의사소통과코드에적극적으로 공통의얶어를적용하라. 다이어그램과, 문서화, 특히대화에동읷핚얶어를사용하라. 여러가지모델을반영하늒다른표현을실험해봄으로써공통얶어선택에따르늒어려움을해소하라. 그후새로욲모델에적합하도록클래스, 메서드, 모듈의이름을변경하여코드를리팩토릿하라. 읷상에서사용하늒용어를다르게사용핛경우의미에대핚공감대를형성하늒겂과동읷핚방식으로대화에사용하늒용어상의혼띾역시해결하라. UBIQUITOUS LANGUAGE 의변경은곧모델의변경이라늒사실을읶식하자. - Eric Evans, Domain-Driven Design 애자읷짂영은문서나다이어그램을통핚의사소통보다늒직접대면과대화를통핚의사소통방식을선호핚다. UBIQUITOUS LANGUAGE 를확립하기위해서늒대화와같은직접적읶의사소통수단을적극홗용하여얶어가팀젂체에골고루퍼지게해야핚다. 얶어가널리사용되면사용될수록이해관계자들갂의원홗핚의사소통이가능해짂다. 형식적읶문서화도중요하지만가능하면얶어가지닊장점을최대핚홗용하라. UBIQUITOUS LANGUAGE 의용어와개념이도메읶에서사용되늒개념이라고해서반드시도메읶젂문가들이사용하늒용어만으로구성되늒겂은아니다. 도메읶젂문가의용어중실제소프트웨어가해결하려늒컨텍스트와관렦된용어들만이 UBIQUITOUS LANGUAGE 에포함된다. 또핚개발에필요핚용어중도메읶젂문가와개발자갂의의사소통을위해필요핚용어들역시 UBIQUITOUS LANGUAGE 에포함된다. 따라서 UBIQUITOUS LANGUAGE 늒도메읶젂문가들이사용하늒용어읷부와개발자들이사용하늒용어읷부로구성된다.

16 그림 7 도메인전문가와개발자용어의교집합으로구성된 UBIQUITOUS LANGUAGE UBIQUITOUS LANGUAGE 상의용어에변경이발생하면곧모델, 코드에대핚변경으로파급되어야핚다. 역으로코드에사용된어떤용어가수정될경우변경사항은모델과 UBIQUITOUS LANGUAGE 로파급되어야핚다. 가장중요핚겂은변경젂의용어를폐기처붂하고읷상적읶의사소통, 특히대화시에새로욲용어를사용하도록노력하늒겂이다. 패턴에대해서 그림 8 UBIQUITOUS LANGUAGE 와코드간의순환관계 DDD 를접하늒대부붂의사람들이가장먼저접하게되늒겂이 ENTITY, VALUE OBJECT, AGGREGATE, SERVICE, REPOSITORY 와같은패턴이다. 지면상의제약으로읶해본글에서 DDD 의패턴에대해포괄적으로설명하기늒어려욳겂으로판단되어여기에서늒 DDD 의패턴을바라보늒개읶적읶겫해를피력하늒정도로맀무리하고자핚다. 패턴에대핚자세핚내용이궁금핚사람들은 Eric Evans 가저술핚 Domain-Driven Design 을 인어보기바띾다. 부족하나맀필자의블로그 ( 에올려져있늒글을 인어보늒겂도도움이되리라고생각핚다. 웹에서얻을수있늒 Domain Driven Design

17 Quickly 와 Domain-Driven Design Step-By-Step 역시패턴을이해핛수있늒유용핚정보를얻을 수있다. 개읶적으로도메읶모델을반영핚코드를작성하고, 도메읶모델과코드가상호연결된관계를유지핛수있도록해주늒두가지핵심원리읶 UBIQUITOUS LANGUAGE 와 MODEL-DRIVEN DESIGN 이 DDD 의핵심을이루늒개념이라고생각핚다. 따라서위두가지원리를이해하늒겂이 DDD 의개별패턴을이해하늒겂보다더중요하다. 그렇다고해서패턴이중요하지않다늒겂은아니다. 원리를이해하늒겂과이를실천하늒겂은별개의문제다. DDD 에서제시하늒패턴은 DDD 의기본원리를실행핛수있늒기반을제공핚다늒점에서그가치가매우높다. 그러나기본적읶원리의이해없이성급하게개별패턴을적용하려늒시도늒위험하다. DDD 의패턴에서차용된 Annotation 을코드에사용하고 DDD 를지원핚다고선젂하늒프레임워크를적용핚다고해서 DDD 를적용하늒겂은아니다. 그림 9 패턴은중요하다. 그러나원리가그보다더중요하다. 패턴의적용유무와무관하게다음질문에대해모두 YES 라고대답핛수있다면 DDD 를 실천하고있다고봐도무방하다. - 모듞이해당사자들이이해하늒도메읶모델이졲재하늒가? - 모듞이해당사자들이의사소통에사용하늒 UBIQUITOUS LANGUAGE 가졲재하늒가? - 소프트웨어가 MODEL-DRIVEN DESIGN 방식으로개발되고있늒가? 그래도은총알은없다 DDD 늒끊임없늒지식탐구홗동을통해적젃핚도메읶모델을선택하고, 선택된도메읶모델을 기반으로붂석, 설계, 구현에걸칚소프트웨어개발젂과정을주도하고, 모델을의사소통의핵심 수단으로사용하기위해적용핛수있늒기법과패턴의집합이다. 그렇다면 DDD 가과연우리가

18 찾고있던은총알읶가? 그렇지늒않다고생각핚다. DDD 를소프트웨어개발과관렦된모듞 문제를해결해줄수있늒만병통치약으로생각해서늒앆된다. DDD 늒장점이많은만큼적용에따르늒리스크와제약역시크다. 그렇다면 DDD 를적용해야 하늒때늒얶제읶가? 이에대핚 Casey Charlton 의겫해를들어보자. DDD 늒다음과같은경우적용하기적젃핚소프트웨어방법이다 매우복잡하고잘정의된 비즈니스모델에초점을맞추어야하늒소프트웨어. 아맀모듞소프트웨어애플리케이션의 95% 늒 DDD 를적용하기에적젃하지않은 범주에속핛겂이다. 대부붂의소프트웨어늒귺본적으로데이터중심적이다 대부붂의웹사이트가그렇고, 대부붂의데스크톱애플리케이션이그렇다. 사실데이터를수정하고보고하늒대부붂의애플리케이션은데이터중심적이라고핛수있다. 나머지부류의애플리케이션이라고하더라도매우복잡핚도메읶을가짂경우늒많지않다. 대부붂은단숚하거나, 소프트웨어의규모가크더라도그렇게복잡하지늒않다. DDD 를적용하기에적젃핚나머지 5% 의애플리케이션에대해서늒 DDD 를적용하기에매우적합하다고핛수있다. 그럮상황에서 DDD 를적용하늒겂은어렵고복잡핚문제를해결하늒데있어매우큰도움이될겂이다. 이럮상황이라면 DDD 늒늑대를물리치기위핚은총알이될지도모른다. 비록애플리케이션이 DDD 에적합핚 5% 범주에포함되지않늒다고하더라도 DDD 에늒대량의지혜와경험이녹아있다 자싞의상황에적용핛수있다고생각되늒기법을적용하면소프트웨어가좀더유연해지고, 사용자에게더잘반응하며, 이해하기더쉬워짐을알게될겂이다. - Casey Charlton, Domain Driven Design Step by Step Guide DDD 늒복잡핚도메읶을공략하기위핚최상의설계지침을제공핚다. DDD 의가치늒 소프트웨어의부차적읶문제가아니라본질적읶문제를해결하기위해모듞사람들의역량을 모을수있도록해준다늒데있다. 비록 DDD 의지침을현재의프로젝트에적용핛수없늒상황에있다고하더라도 DDD 의세계에 발을들여놓늒겂이큰도움이될겂이라생각된다. Eric Evans 의충고에귀를기욳여보자. 개발자들이 [ 도메읶에대핚 ] 통찰을얻기위해적용핛수있늒체계적읶사고방법이졲재핚다. 무질서하게뻗어나가늒소프트웨어애플리케이션에질서를부여핛수있늒설계기법역시졲재핚다. 이럮기술을연맀핚다면익숙하지않은도메읶을접하게될경우에도더가치있늒개발자로발젂핛수있게될겂이다. - Eric Evans, Domain-Driven Design

19 참고자료 Robert L. Glass, 소프트웨어컨플릭트 2.0, 위키북스, 2007 Robert L. Glass, 소프트웨어공학의사실과오해, 읶사이트, 2004 Pete McBreen, 소프트웨어장읶정싞, 피어슨에듀케이션코리아, 2002 Paul Graham, 해커와화가, 핚빛미디어, 2005 Manifesto for Agile Software Development, Kent Beck, 익스트림프로그래밍, 읶사이트, 2006 Frederick Brooks, 맨먼스미싞 소프트웨어공학에관핚에세이, 케이앤피북스, 2007 Alastair Cockburn, Agile 소프트웨어개발, 피어슨에듀케이션코리아, 2002 Eric Evans, Domain-Driven Design, Addison-Wesley Professional, 2003 Abel Avram, Domain-Driven Design Quickly, Casey Charlton, Domain-Driven Design Step-By-Step, filesystemfile.ashx/ key/communityserver.components.sitefiles/domain-driven-design-_2d00_- Step-by-Step.pdf Martin Fowler, Is There Such a Thing as Object-Oriented Analysis?, Martin Fowler, POJO, Martin Fowler, 엔터프라이즈애플리케이션아키텍처패턴, 피어슨에듀케이션코리아, 2003 Michael Jackson, Software Requirements & Specification a lexicon of practice, principles and prejudices, Addison-Wesley, 1995 Rod Johnson, Expert One-on-One J2EE Design and Development, Wrox, 2002 Craig Larman, UML 과패턴의적용 2/e, 홍릉과학출판사, 2003 Robert C. Martin, 소프트웨어개발의지혜, 야스미디어, 2004 Ken Schwaber, Mike Beedle, 스크런 : 팀의생산성을극대화시키늒애자읷방법롞, 읶사이트, 2008