Eternity's Chit-Chat

aeternum.egloos.com



Domain-Driven Design Essence Domain-Driven Design

Domain-Driven_Design_Essence.pdf

사내 웹진에 3개월간 연재한 글로 기술적인 내용은 배제하고 Domain-Driven Design의 핵심적인 개념과 사상에 관해 설명해 보았습니다.

 

철저하게 구현 관점에서 Domain-Driven Design을 설명했던 Domain-Driven Design의 적용에 비해 이 글은 Domain-Driven Design의 기본 원리에 무게중심을 두었습니다.

 

블로그에 올려 놓은 Domain-Driven Design 프리젠테이션 자료와 함께 보시면 효과적일 것 같습니다.


핑백

덧글

  • muscly 2010/04/02 16:06 # 삭제

    좋은 글 잘 읽었습니다. 회사분이라는 걸 며칠 전에 알았네요. ^^
  • 이터너티 2010/04/03 12:21 #

    회사분이셨군요 ^^
    블로그 보니 일본에 파견 나가신것 같은데 맞는지 모르겠네요.
    건강 잘 챙기시고 본사에서 뵐 수 있는 기회가 있었으면 좋겠습니다.
  • muscly 2010/04/12 13:40 # 삭제

    네, 꼭 한 번 뵙고 싶네요~ ^^
  • 민재 2010/04/13 17:14 # 삭제

    와우,,, DDD관련 포스팅을 많이 하셨네요. 감사..
    저도 관련해서 강좌를 준비중입니다.. 언제 인연이 되면 만나뵙게 되길 바랍니다. ^^
  • 이터너티 2010/04/15 12:26 #

    안녕하세요.
    DDD 강좌를 준비하신다니 많은 분들이 참여하셔서 좋은 내용을 공유히셨으면 좋겠네요. ^^
    좋은 강좌 부탁드립니다.
  • 4444 2010/10/11 22:25 #

    요번에 ddd책을 보았는데, 이곳의 값객체 설명등.. 너무 좋은 자료가 많아 도움이 많이 되었어요.
    하지만 여기 pdf자료를 보던 중 저랑은 다른 생각을 가지고 있는거 같아 그 점에 대해 문의 드리고 싶어요.
    애자일 같은 경우에는, code의 tdd나 refactoring을 통해 design을 이끌어 내는데( code -> design) ,
    ddd의 저자는 이 방식의 한계를 지적하고 domain에서부터 model을 이끌어 내는 것 또한 중요하다고 지적하는거 같아요.
    ddd책 초반에 애자일은 over engineering에 대한 두려움때문에 설계에 대한 깊은 이해를 하지 않는다.라고 적혀있고,
    중간챕터인 deeper insight에서는 domain에 대한 사유를 통해 모델의 breakthrough또한 강조하고 있는거 같아요.
    그러나 여기 pdf에는 ddd와 애자일의 이런 차이에 대해 제대로 보여주지 못하는거같아요.
    마치 ddd의 설계방식과 자일의 설계방식이 동일한 것처럼 설명하는 거 같아요.
    ddd는 애자일의 iterative process는 옹호하지만, code->design의 설계방식은 한계가 있다고 하는거 같거든요.
  • 이터너티 2010/10/12 16:20 #

    안녕하세요. 좋은 질문 주셔서 감사합니다. ^^

    질문하신 내용 중에 제가 쓴 글에서 애자일을 언급한 부분에 관해 오해가 있으신 것 같아 해당 내용에 관해 답변 드리겠습니다.

    결론부터 말씀 드리면 제 글에서 DDD와 애자일의 설계 방식이 동일하다고 말하고 있지는 않습니다.

    제가 쓴 글의 초반부에 애자일을 언급한 것은 DDD라는 개념이 각광을 받게 되던 시기의 몇 가지 중요한 전환점 중의 하나가 애자일의 확산이기 때문입니다. 추가적으로 POJO를 언급한 것 역시 동일한 맥락에서였는데 기술적으로 Spring, Hibernate와 같은 비침투적인 프레임워크를 도입하여 도메인 레이어를 고립시킬 수 있게 됨으로써 DDD의 개념을 실제로 구현할 수 있는 발판이 마련되었기 때문입니다.

    글 후반부에서 DDD를 설명하면서 여러 가지 애자일의 프랙티스를 언급한 것은 DDD의 개념 역시 애자일과 밀접한 관련을 맺고 있기 때문입니다. DDD의 서문에서 Evans가 피력한 내용을 인용하도록 하겠습니다.

    "이 책은 특정 방법론에 매여 있지 않으나 "애자일 개발 프로세스"라는 새로운 진영을 지향한다. 특히, 아래의 두 가지 실천방법이 프로젝트 수행 중에 일어나야 함을 가정하고 있다. 아래의 두 가지 실천방법은 이 책의 접근법을 적용하기 위한 선행 조건이다.
    개발은 반복주기를 통해 진행되어야 한다. …
    개발자와 도메인 전문가는 밀접한 관계를 가져야 한다. …
    켄트벡, 워드 커닝햄이 주축이 돼서 고안해 낸 익스트림 프로그래밍은 애자일 프로세스 중에서도 가장 탁월하고 나 또한 가장 많이 업무에 적용해 오고 있다. 이 책 전반에 걸쳐 설명을 구체적으로 하기 위해 설계와 프로세스간 상호작용에 대한 토론의 기반으로 XP를 사용할 것이다. 여기서 설명된 원칙들은 다른 애자일 프로세스에도 쉽게 맞출 수 있다."

    정리하면 DDD는 애자일과 같은 프로세스와 무관한 패턴과 원칙, best practice의 집합입니다. 즉, DDD를 하기 위해서 애자일을 사용할 필요는 없지만 Evans의 경우 DDD의 개념을 적용하기 위한 최적의 프로세스로 애자일을 언급하고 있습니다.

    위 질문의 요지는 제가 애자일과 DDD의 설계 방식을 동일한 것으로 보고 있다는 것인데 만약 그렇게 이해되셨다면 아마 제 글솜씨가 조금 모자란 것이 원인이 아니었나 싶네요. ^^;;

    말씀하신 내용 중에 Evans가 "TDD나 REFACTORING의 한계를 지적하고 도메인에서 모델을 이끌어 내는 방법을 강조했다"고 말씀 하셨는데 그 부분은 책의 내용을 잘 못 이해하고 계신 것 같습니다. 앞서 말씀 드린 바와 같이 DDD는 도메인 모델을 만들기 위한 패턴과 best practice의 집합이며 그것을 얻기 위해 어떤 프로세스를 사용해도 무방합니다. TDD/REFACTORING을 통해 개발을 진행하건 사전 설계를 통해 개발을 진행하건 그 결과가 도메인 지향이면 무관하다는 것이죠. 다만 지속적인 피드백과 MODEL-DRIVEN DESIGN을 위해서는 애자일 적인 프로세스가 훨씬 더 효율적인 것으로 언급하고 있으며 책 전체적인 관점은 Evans가 이야기한 것처럼 애자일을 지향하고 있습니다.

    인용해 주신 "애자일은 over engineering에 대한 두려움 때문에 설계에 대한 깊은 이해를 하지 않는다”라는 문구는 애자일이 항상 그렇다는 것이 아니라 애자일에 미숙한 개발자들에게서 그런 문제가 발생할 수 있다라는 의미로 해석하는 것이 맞을 것 같습니다. Evans가 DDD라는 책을 저술한 취지 중 하나는 설계 기술이 부족한 개발조직이 애자일 적용 시 참고할 수 있는 설계 지침을 제공하는 것입니다. 아래 DDD의 서문을 인용합니다.

    “안타깝게도 몇몇 애자일 프로세스 사상은 오해의 소지가 있다. 이는 “가장 단순함”에 대해 제각기 다른 정의를 내리기 때문이다. 지속적인 리팩토링은 작은 재설계가 연속적으로 일어나는 것이다. 즉, 확고한 설계 원칙이 없는 개발자는 이해하거나 변경하기 어려운 코드만을 만들어 낼 것이며, 이는 기민함과는 거리가 멀다. 그리고 예상치 못한 요구사항에 대한 두려움이 종종 과도한 선행 작업으로 이끌기도 하지만, 반대로 지나친 선행 작업을 회피하려는 노력이 또 다른 두려움을 만들어 내기도 한다. 즉, 깊이 있는 설계에 대한 사고를 전혀 하려 들지 않는다는 것이다.
    사실 XP는 예리한 설계 감각이 있는 개발자에게는 최선의 선택이라 할 수 있다. XP 프로세스는 여러분이 리팩토링을 통해 설계를 향상시키고, 이러한 리팩토링을 자주, 그리고 빠르게 수행한다는 것을 가정한다. 그러나 지금까지의 설계를 선택하는 방식은 리팩토링 자체를 쉽게 만들거나 또는 어렵게 만들 수도 있다. XP 프로세스는 팀원들간 의사소통 기회를 늘리려 하지만, 이러한 모델 및 설계에 대한 선택은 의사소통을 명확하게도, 또는 혼란스럽게 할 수도 만든다.
    이 책은 설계 및 개발 실천지침을 한데 엮어 도메인 주도 설계와 애자일 개발 방법이 어떻게 서로를 보완하는지를 보여 준다. 애자일 개발 프로세스 환경하에서 도메인 모델링에 정교하게 접근한다면 개발을 가속화할 수 있을 것이다. 도메인 개발과 프로세스와의 상호 관계를 고려한다면 순수하게 설계만을 다루는 것에 비해 이 같은 접근법을 보다 실용적으로 만들 것이다.”

    "deeper insight에서는 domain에 대한 사유를 통해 모델의 breakthrough또한 강조”한다는 내용이 애자일에 대한 반대라고 할 수는 없습니다. 오히려 Evans는 breakthrough를 통해 deeper model을 얻기 위해서는 고객과의 밀접한 상호작용 속에서 지속적으로 개념(그리고 코드도 함께)을 리팩토링하는 애자일 적인 접근 방법을 강조하고 있습니다.

    대답하기 어려운 질문이라 제딴에는 최선을 다해 답변을 드린다고 드렸는데 도움이 되실 지 모르겠네요. ^^;
  • 4444 2010/10/12 17:50 #

    제 생각에는 애자일과 ddd의 가장 큰 차이점이 model의 유무라고 생각해요. 애자일은 요구사항->code->design->릴리즈->(비교)요구사항->.. 이런식의 빠른 반복적 프로세스이고, ddd는 요구사항->model<->design<->code 이런식의 반복적프로세라고 생각하거든요. pdf에 링크거신 마틴파울러의 is design dead 의 글도 애자일쪽에서 model을 만들지 않는 경향을 지적한 글이라고 생각되고요. 저자가 얘기하는 리팩토링은 애자일에서의 code->design의 리팩토링뿐만 아니라, design->model차원에서의 리팩토링도 얘기하고있습니다. ddd에서 technical refactoring에 대한 한계를 지적하고, model자체의 refactoring을 얘기하는데, 애자일에서는 model이라는거 자체가 없다고 생각해요. 그렇기 때문에 저자는 ddd가 애자일의 이 약점을 보안할 수 있는 방법이라고 소개하는거 같고요. 애자일의 tdd/refactoring설계방식에는 model이 없는데 어떻게 model에 대한 리팩토링이 행해질수 있는지 의문이에요. 특히나 저자는 ubiquitous language를 도입하면서, 언어차원에서의 추상화(modeling)을 이루어 내려고 노력하는거 같아요. " the model relationships become the combinatory rules all language have. the meanings of words and phrases echo the semantics of the model. " ddd가 바라보는 설계추상화 수준과, 애자일이 목표로하는 추상화 수준은 많이 다르다고 생각되어져요.
    결국 제 생각에는 '애자일에는 model이라는거 자체가 없다.' 인데 이게 맞는 얘기인가요?
  • 이터너티 2010/10/12 18:36 #

    앞서 말씀 드린 바와 같이 애자일과 DDD의 차이점이라고 하는 것은 의미가 없습니다. 서로 비교 대상이 아니기 때문입니다.

    애자일은 과도한 사전 설계로 인해 분석 마비 상태에 빠지기 쉬운 heavy-weight 방법론에 대한 반대 급부로 발생한 방법론의 집합이라고 보시면 되고(XP, SCRUM, Crystal Clear등이 여기에 속합니다) DDD는 방법론과 무관한 패턴과 BEST PRACTICE 집합으로 보셔야 합니다. 444님께서 참여하시는 프로젝트가 애자일을 적용하느냐 heavy-weight 방법론을 적용하느냐와 무관하게 적용 가능한 도메인에 중점을 두는 설계 철학으로 보시는 것이 합당합니다. 즉, TDD를 하는 경우이건 Domain Model에 대한 사전 설계를 한 후 개발에 들어가는 경우이건 DDD는 유효하다는 것이죠.

    Martin Fowler의 "Is Design Dead"는 애자일이 좋은 설계의 가치를 무시한다는 오해를 바로잡기 위해 작성한 글로 Fowler의 결론은 '애자일은 설계를 무시하지 않는다'입니다. 아래 한글 번역 문서의 결론 부분을 여기에 인용합니다.
    http://blog.naver.com/j6040148?Redirect=Log&logNo=120015111138

    "그래서, [애자일에서] 디자인은 죽었는가?
    전혀 그렇지 않다. 다만 디자인의 성향이 바뀐 것이다. XP 디자인은 다음과 같은 기술을 요구한다.
    - 코드를 최대한 명확하고 단순하게 유지하려는 부단한 의지
    - 필요할때 자신있게 개선시킬수 있는 리팩토링 기술
    - 패턴에 관한 훌륭한 지식: 그냥 해결책으로 보는것 뿐만 아니라 언제 그것을 사용하고, 어떻게 차츰 발전시킬지를 날카롭게 판단하여야 한다.
    - 현재 내려진 결정이 나중에는 변하게 될수 있다는 것을 알고, 미래의 변화에 항상 눈을 뜨고 디자인을 하는 기술.
    - 디자인을 꼭 이해해야 하는 사람에게 코드나 다이어그램 특히 '대화'를 통해서 전달하는 방법을 아는 것.
    이런 기술이 두렵게 느껴질 수도 있다. 하지만 훌륭한 디자이너(설계자)에게는 항상 고통과 노력이 따른다. XP가 이 고통을 조금도 줄여주지는 않는다 - 나에겐 그랬다. 하지만 XP가 효율적인 디자인을 위한 새로운 길은 가르쳐 주었다고 생각한다. 진화하는(evolutionary) 디자인이 그것이다. 나는 진화를 아주 좋아한다. 만약 진화가 없다면 나도 없는 것이다.(미래는 없는 것이다.)"

    애자일에서 Model이 없다는 것은 잘 못 알고 계신 내용입니다. TDD는 테스트 기술이라기 보다는 좋은 설계를 지향하기 위한 기술로, 좀 더 객체-지향적인 설계를 가능하게 합니다. 오히려 Kent Beck, Martin Fowler, Uncle Bob, Alastair Cockurn을 비롯해서 애자일 진영에 속하는 모든 사람들은 훌륭한 설계와 객체-지향적인 Domain Model의 가치를 역설하고 있습니다.

    444님께서는 애자일에 대한 많은 부분을 오해하고 계신 것 같습니다. 애자일은 단순하게 TDD나 리팩토링이 아닙니다. 계속해서 애자일이 단순히 구현을 먼저하고 설계를 나중에 하는 것으로 말씀하시지만 그것은 애자일, 그 중에서도 XP가 지향하는 프로세스일 뿐이며 애자일 전체로 봤을 때는 아주 작은 부분을 차지합니다. TDD를 애자일 전체와 동일시하시면 안됩니다. TDD와 리팩토링은 XP에 의해 유명해진 프랙티스의 하나일 뿐이며 현재는 애자일과 무관하게 적용할 것을 추천하는 BEST PRACTICE입니다. TDD를 한다고 해서 애자일을 하는 것은 아니며, 반대로 TDD를 하지 않는다고 해서 애자일을 하지 않는 것은 아닙니다. 애자일에서 중요한 것은 요구사항을 수용할 수 있는 고품질의 소프트웨어를 빠른 시간에 개발할 수 있는 기민함을 가지는 것입니다.

    애자일에 관련된 다양한 책이나 아티클을 읽어 보신 후 다시 한 번 DDD의 내용을 음미해 보시는 것이 어떨까 합니다.

    다시 한번 말씀드리지만 DDD는 설계 프로세스와 무관하며 애자일적인 가치를 중요하게 생각한다는 것입니다.

    답변이 됐는지 모르겠네요. ^^
  • 4444 2010/10/12 20:30 #

    예. 맞네요. 제가 xp와 애자일을 동일시하고있었네요. 특히나 tdd와 리팩토링을 애자일의 전부라고 생각한건 잘못된 생각이었어요. tdd와 리팩토링에 의한 설계방식에 대한 강한 반발로 인해, 애자일 전체에 대해 오해하고있었어요. 애자일 선언을 다시 읽어보니 ddd에서 중요시하는 가치하고 같네요. 빠른반응.고객과 협업,개인간 상호작용.
    하지만 tdd가 객체지향적 design을 이끌어 주는건 동의하지만, 그것이 model을 만들어 준다는건 동의할 수가 없어요. 밑으로부터의 설계는 추상화 수준에 한계가 있다고 생각해요. 제가 계속 귀찮게 하는건 아닌지 모르겠네요..
  • 이터너티 2010/10/13 18:49 #

    귀찮게 하시는 것은 아니니 궁금한 사항 있으면 언제라도 글 남겨주세요. ^^

    모델이란 프로젝트의 도메인에 대한 적절한 추상화라고 보시면 될 것 같습니다. 즉, 도메인의 중요한 개념들을 가공한 후 소프트웨어 개발에 적절한 핵심만 추려내고 단순화한 것이죠. DDD에서 모델은 프로젝트에 참여한 사람들이 동의하는 공통의 용어를 사용해야 하는데 이를 UBIQUITOUS LANGUAGE라고 합니다. 또한 모델은 구현 가능해야 하며 구현과 지속적인 피드백을 주고 받으며 동일한 상태를 유지해야 하는데 이를 MODEL-DRIVEN DESIGN이라고 합니다. 즉, DDD에서 말하는 도메인 모델이 존재하느냐 존재하지 않느냐는 프로젝트에 참여한 사람들의 협업 관계와 도메인을 지향하고자하는 의지에 따른 것이지 특정한 구현 방법과는 무관한 것입니다.

    TDD에 관한 가장 큰 오해는 TDD를 설계에 대해 고려하지 않고 코드를 작성하는 code-and-fix로 생각하는 것입니다. TDD는 단순하게 설계와 무관하게 구현만 하는 것이 아니라 가장 단순한 설계에 이를 수 있도록 시스템이 제공해야 하는 기능을 Test Case의 형식으로 작성하고, 기능을 통과시키기 위한 가장 단순한 솔루션을 통해 Test Case를 통과시킨 후, 통과한 Test Case를 regression test의 용도로 삼아 최적의 설계를 얻기 위해 구체적인 코드를 보며 리팩토링을 하는 과정입니다. TDD란 Ron Jeffries가 말한 것처럼 작동하는 가장 단순한 솔루션을 만드는 가장 효과적인 방법이라고 할 수 있습니다.

    말씀하신 것처럼 TDD는 모델을 만들어 주지 않습니다. 모델은 프로젝트에 참여한 사람들 간의 긴밀한 협력과 도메인에 대한 분석을 통해 만드는 것이지 TDD를 통해 만들어 지는 것이 아닙니다. 이것은 어떤 방법을 사용하더라도 마찬가지입니다. 즉, 공통의 모델을 만들기 위한 노력이 없다면 사전 설계 후에 구현에 들어간다고 해도 프로젝트 관련자들 간에 공유할 수 있는 모델을 만드는 것은 불가능합니다. 이것은 UML을 사용해서 다이어그램을 그린다고 해서 모델이 만들어지지 않는 것과 동일한 것이죠.

    TDD는 단순하면서도 고품질의 소프트웨어를 구현하기 위한 방법이지 모델을 만들기 위한 방법이 아닙니다. DDD와 TDD는 이름만 유사할 뿐 서로 완전히 다른 레벨의 개념이며 비교할 필요가 없는 것이죠. TDD는 그것이 도메인에 관계된 것이건, 기술적인 인프라스트럭처에 관계된 것이건 어떤 대상을 구현하기 위한 방법일 뿐입니다.

    단순히 TDD를 한다고 해서 무조건 좋은 모델이 만들어진다고 주장하는 사람은 없습니다. 다만 사전 설계에 비해 TDD를 통해 더 단순하고 품질이 높은 설계를(모델이 아니라) 얻는다는 것이죠. 따라서 "TDD가 모델을 만들어 준다는 건 동의할 수 없다"는 말씀은 허수아비 공격의 오류라고 할 수 있습니다.

    그러나 모델을 만들기 위한 전제조건이 갖추어 졌을 경우 모델을 코드로 구현하기 과정에 있어서 TDD를 적용하는 것은 효과적이라고 생각합니다. 그것은 아무런 구체적인 피드백 없이 머릿속으로 사전설계를 하는 것에 비해 구체적인 코드로부터의 피드백을 활용할 수 있는 TDD가 더 적절한 설계의 모델을 얻을 수 있기 때문이죠. 이것은 Model-Driven Design을 달성하는 좀 더 쉬운 방법이라고 생각합니다. 실제로 구현을 해봐야 모델과 구현 간에 일관성 여부를 확인할 수 있을 테니까요.

    "밑으로부터의 설계는 추상화에 한계가 있다"라고 하셨지만 여기에서 "밑으로부터"의 정의가 무엇을 말씀하시는 것인지 잘 모르겠습니다. "밑으로부터의 설계"가 레이어 아키텍처의 밑으로부터의 설계(또는 도메인 레이어로부터의 설계)를 의미하시는 것이라면 TDD는 Mock을 사용해서 위로부터의 설계가 가능하다는 말씀을 드리고 싶습니다. "밑으로부터의 설계"가 구체적인 코드로부터 설계를 이끌어 내는 방식을 말씀하시는 것이라면(아마도 말씀하시고자 하시는 것이 이것이 아닐까 싶은데) 코드를 통한 구체적인 피드백 없이 설계만을 진행하는 "위로부터의 설계" 방식은 "잘못된 추상화에 이를 수 있다"라는 사실을 말씀 드리고 싶습니다.

    아마도 DDD에서 말하는 도메인 모델이 구현 전에 만들어져야 한다고 생각하셔서 이렇게 말씀을 하신 것이 아닌가 하는 생각이 듭니다. 실제로 DDD에서 말하는 도메인 모델은 반복적인 과정을 통한 지속적인 리팩토링을 통해서 만들어지는 것입니다. DDD의 Part III: Refactoring Toward Deeper Insight는 이와 같은 과정에 관해 전반적으로 설명하고 있으니 다시 한 번 읽어 보시면 도움이 될 것 같네요.

    TDD에 대한(그리고 리팩토링을 통해 최적의 솔루션에 이르는 방법에 대한) 거부감을 버리시고 실제로 적용해 보시면서 왜 그렇게 수많은 사람들이 TDD를 적용하려고 하는지를 느껴보셨으면 합니다. 아래에 실제로 보시면서 TDD를 따라 하시기에 좋은 참고 자료를 적습니다.

    -테스트 주도 설계
    http://kangcom.com/sub/view.asp?sku=200412020003
    예제는 간단하지만 TDD의 흐름에 관해 가장 적절한 설명을 담고 있습니다.

    -Test Driven:TDD and Acceptance TDD for Java Developers
    http://www.amazon.com/Test-Driven-Acceptance-Java-Developers/dp/1932394850
    이 책의 2장과 3장은 TDD와 리팩토링을 이해할 수 있는 깔끔한 예제를 제공하고 있습니다.

    -Growing Object-Oriented Software, Guided by Tests
    http://www.amazon.com/Growing-Object-Oriented-Software-Guided-Tests/dp/0321503627/ref=sr_1_1?ie=UTF8&s=books&qid=1286948027&sr=1-1
    TDD를 통해 객체 지향적인 도메인 레이어를 구현하는 방법에 관해 배울 수 있습니다.

    - 패턴을 활용한 리팩터링
    http://kangcom.com/sub/view.asp?sku=200607110007
    1장을 읽어 보시길 권합니다. 말씀하신 밑으로부터의 설계와 위로부터의 설계에 관해 좋은 참고자료가 될 것이라고 생각됩니다.

    답변이 점점 길어지네요. ^^;;
  • 4444 2010/10/13 21:19 #

    아직도 의문이 남는게,
    1. 켄트백은 tdd와 코드 리팩토링을 중요한 설계방법론으로 생각하던데 제가 제대로 이해한게 맞나요 ?
    2. tdd와 코드 리팩토링은 설계방법론인가요 아니면 좋은 코드를 만드는 도구인가요 ?
    3. 단위테스트가 아닌 tdd로 코드구현을 현업에서 많이 사용하시나요 ?

    제가 이해한게 다음과 같은데 제대로 이해한게 맞는지도 의문이에요.
    -애자일은 특정한 방법론이 아닌, 애자일의 가치를 중요시하는 태도이다.
    -tdd와 리팩토링은 model을 만들 수 없지만, model 과 design/code가 iterative하게 발전할 수 있게 해준다.

    책추천과 답변 감사합니다. 책을 읽어도 얘기할 상대가 없어서 문제였는데, 잘못된 생각을 고칠 수 있는 좋은 기회를 얻어서 다행이라고 생각해요. 책을 읽고 의문이 있으면 질문을 올려도 될까요 ? 컴쪽으로 공부하면서 이런 질문을 할 곳도 없고, 제대로 된 답변을 얻을 곳도 없어서요.
  • 이터너티 2010/10/16 17:17 #

    답변 드리겠습니다.

    1. 켄트백은 tdd와 코드 리팩토링을 중요한 설계방법론으로 생각하던데 제가 제대로 이해한게 맞나요 ?
    -> 거창하게 방법론이라는 용어를 붙이기는 어렵지만(2번 답변에 관련한 내용을 적었습니다) 좋은 설계를 만들기 위한 방법이라는 관점에서는 맞습니다. TDD는 클라이언트 관점에서 실패하는 테스트를 작성하고(클라이언트 관점에서 직관적이고 사용하기 편리한 API를 만들 수 있습니다), 테스트를 통과하도록 코드를 작성한 후(테스트를 통화하기 위해 필요한 최소한의 작업만 하기 때문에 불필요한 가외 기능이 추가되지 않습니다), 코드를 리팩토링(만들어진 테스트 케이스가 회귀 테스트의 역할을 하기 때문에 리팩토링에 대한 안전망을 확보할 수 있습니다)하는 과정을 통해 훌륭한 설계를 만들어 내는 방법 또는 프랙티스입니다. 실제로 TDD는 XP의 프랙티스 중 하나로 포함되어 있습니다.

    2. tdd와 코드 리팩토링은 설계방법론인가요 아니면 좋은 코드를 만드는 도구인가요 ?
    -> 톰 디마르코의 말을 빌자면 방법론에는 대문자로 M으로 시작하는 방법론과 소문자 m으로 시작하는 방법론이 있습니다. 다음은 톰 디마크로가 저술한 피플웨어에서 발췌한 것입니다.
    “방법론에는 대문자로 시작하는 것과 소문자로 시작하는 것 두 가지가 있다. 이 둘은 커다란 차이가 있다. 소문자로 시작하는 것(methodology)은 임무를 수행하기 위한 기본적인 접근 방법이다. 그것은 두꺼운 책에 쓰여 있는 것이 아니라, 임무를 수행하는 사람들의 머릿속에 들어 있다. 하지만 대문자로 시작하는 방법론(Methodology)은 매우 다르다. 대문자로 시작하는 방법론은 사고를 집중화하려는 시도이다. 모든 중요한 의사결정은 그 일을 실제로 수행하는 사람들이 아닌 방법론을 세운 사람에 의해 이루어진다. 하지만 그것의 본질은, 바로 실제 업무를 수행하는 사람들이 너무도 멍청해서 누군가 대신 업무에 대한 생각을 해주어야 한다는 것이다.”
    말씀하시는 방법론이 대문자 M으로 시작하는 것이라면 TDD는 방법론이 아니지만 소문자 m으로 시작하는 방법론을 말씀하시는 것이라면 방법론이 맞습니다. 이런 관점에서는 TDD는 방법론인 동시에 좋은 설계를 가진 코드를 만들기 위한 도구와 동일합니다. 단순히 방법론이라는 용어를 사용하면 오해의 소지가 있어 명확하게 분리해서 말씀 드렸습니다.

    3. 단위테스트가 아닌 tdd로 코드구현을 현업에서 많이 사용 하시나요 ?
    -> 아쉽게도 현재 많이 사용되고 있지는 않습니다. 단위 테스트 작성에 대한 필요성은 인지하고 계시지만 테스트를 먼저 작성하는 방법에 대해서는 아직까지도 어려움을 느끼시는 경우가 많습니다. (부끄럽지만 저 역시 제가 TDD를 잘 하고 있다고 말씀 드리기 어렵군요. ^^;;) TDD를 하기 위해서는 좋은 설계에 대한 감각을 가져야 하는데 이러한 감각이 결여되어 있을 경우 TDD를 한다고 해서 (안 하는 것 보다는 나을지 몰라도) 여전히 좋은 설계를 만들 수는 없기 때문이기도 하고, TDD를 설계가 아닌 단위 테스트 작성의 용도로 생각하시는 경향으로 인해 좋은 설계보다는 테스트 커버리지를 높이기 위한 관점에서 접근하는 경우가 종종 있기 때문이기도 합니다. 레거시 코드가 TDD에 걸림돌이 되는 경우도 있고요.
    아직까지 현업에서 TDD를 제대로 활용하고 있지는 못 하지만 지속적으로 관심을 가지고 적용하려는 개발자들이 늘고 있어 점차적으로 기본 프랙티스로 자리 잡지 않을까 하는 기대는 해봅니다.

    아래는 추가적으로 주신 내용에 대한 답변입니다.

    -애자일은 특정한 방법론이 아닌, 애자일의 가치를 중요시하는 태도이다.
    -> 애자일은 특정한 방법론이라기 보다는 유사한 특성을 가진 가볍고 기민한 방법론들을 묶어서 부르는 용어입니다. 현재는 조금 남용되는 경향도 보이지만 애자일의 가치를 중요시하는 태도를 애자일이라고 합니다. 그렇게 하는 것은 애자일적인게 아니야 라는 말을 들으실 때는 태도의 관점에서 보셔도 무방할 것 같습니다.

    -tdd와 리팩토링은 model을 만들 수 없지만, model 과 design/code가 iterative하게 발전할 수 있게 해준다.
    ->예 말씀하신 내용이 맞습니다.

    궁금한 사항이 또 생기면 제 블로그에 질문 남겨 주세요. 답변을 달면서 여러 가지 생각들을 정리할 수 있어서 좋네요. ^^
  • 4444 2010/10/19 02:41 #

    친절하게 답변달아주셔서 감사합니다. 좀 더 많이 공부한 후에 궁금한 사항이 있으면 질문남길게요.
  • 에반킴 2011/08/28 21:05 #

    4444님 질문 덕에 많이 배우고 갑니다^^
  • 이터너티 2011/08/29 12:04 #

    평소에 생각하지 않았던 부분에 대해 질문 주시는 경우가 많아서
    답변을 달면서 저도 많이 배우게 됩니다. ^^
  • ㅎㅎㅎ 2011/11/07 15:41 # 삭제

    내용을 참 잘 정리 하셨네요.. 많은 도움이 되었습니다..

    며칠전 한 개발자사이트에 {소스코딩 = 설계} 라는 글을 올렸다가 왕따..ㅠ.ㅠ..
    (워낙 글 솜씨가 없다보니..ㅡ.ㅡ.. 제가 쓴글은 아래...)
    http://www.devpia.com/MAEUL/Contents/Detail.aspx?BoardID=83&MAEULNO=28&no=3890&page=1

    이글의 링크를 사용하여 다시 추가로 쓰고 싶은데.. 괜찮겠죠..??..^^;..
  • 이터너티 2011/11/07 17:55 #

    예 링크를 다셔도 무방합니다.
    작성하신 글을 보니 아래 글을 참조하시는 것이 더 좋을 것 같네요.
    제 글은 DDD에 관련된 글이라 관련 내용에 대해 깊게 다루고 있지 못하는데 비해
    Jack W. Reeves의 글은 생각하시는 개념을 매우 명확하게 설명하고 있습니다.

    Code as Design: Three Essays by Jack W. Reeves
    http://www.developerdotstar.com/mag/articles/reeves_design_main.html

    아니면 제 블로그에 있는 다음 글을 참조하셔도 좋을 것 같네요.
    http://aeternum.egloos.com/1545662
    http://aeternum.egloos.com/1561326
    http://aeternum.egloos.com/1576712

    방문해 주셔서 감사합니다. ^^
  • ㅎㅎㅎ 2011/11/07 18:57 # 삭제

    답글 감사합니다..

    알려주신 "Code as Design"은 영어의 압박이 있지만 천천히 읽어봐야겠네요..

    한글로 이렇게 좋은 글들이 있는걸 알았으니.. 종종 놀러 올께요..^^;
  • lantlani 2012/04/07 10:08 # 삭제

    정말 좋은 글을 읽게 되서 감사드립니다.
    그리고 감사 인사 드릴려고 댓글을 내리다 보니, 댓글에서도 너무 좋은 내용이 많네요. 앞으로도 자주 놀러 오겠습니다. ^^
  • 이터너티 2012/05/31 23:48 #

    방문해 주셔서 감사합니다.
    요즘에 조금 정신이 없어서 답글이 늦었네요. ^^
※ 로그인 사용자만 덧글을 남길 수 있습니다.