[DDD] DDD Quickly ( 도메인 주도 설계란 무엇인가?) 정리

http://www.kyobobook.co.kr/product/detailViewKor.laf?ejkGb=KOR&mallGb=KOR&barcode=9788966260126&orderClick=&Kc= 

도메인 주도 설계란 무엇인가 - 교보문고

도메인 주도 설계란 무엇인가?

• 자동차라는 것은 단순한 조립품 이상의 것이다. 좋은 자동차는 비전으로부터 출발하고, 그 비전은 주의 깊게 명세서로 기술되고, 이것은 다시 설계로 이어진다. 원래의 비전을 달성할 때까지 여러 달 또는 여러 해 동안 수많은 설계가 완벽해질 때까지 수정되고 보완된다. 설계 과정에서 테스트 / 그 결과에 따른 설계 수정이 상당 부분 차지한다. 그 후 마침내 자동차는 생산에 들어가고 부품이 생산되어 조립되는 것이다. 소프트웨어 개발도 이와 유사하다.
• 좋은 소프트웨어를 만들기 위해서는, 그 소프트웨어가 무엇에 관련된 것인지 알아야 한다. 우리가 출발해야 하는 곳은 언제나 도메인이다.
• 소프트웨어 프로젝트를 시작할 때, 우리는 그 소프트웨어가 동작해야 하는 도메인에 집중해야 한다. 소프트웨어의 전반적인 목적은 특정 도메인의 일이 더 잘 굴러가도록 하는 데 있다.
• 소프트웨어에 도메인을 반영하여 만들어야 한다. 소프트웨어는 도메인의 핵심 개념과 각 구성 요소를 담고 있어야 하고 그들 간의 관계를 정확하게 실체화해야 한다. 소프트웨어는 도메인을 모델링해야 한다.
• 우리는 정보를 조직화, 체계화하고, 이것을 작은 부분으로 나누고, 그 조각들을 다시 논리적 모듈로 그룹화한 다음 한 번에 하나씩 선택해서 다루어야 한다. 어느 부분을 분석하고 어느 부분을 제외할지 결정하는 것은 상당히 도전적인 작업임에 틀림없다. 그러나 이러한 작업은 설계의 한 부분이고 그 자체가 소프트웨어 개발 프로세스이다.
• 우리가 모델로 의사소통할 필요가 있다.
• 왜냐하면 결국 소프트웨어의 목적이란 현실 세계의 도메인 안에 있는 비즈니스 문제들을 해결하기 위한 것이기 때문이다. 따라서 그 도메인과 소프트웨어는 철저하게 혼합되어야만 한다.

유비쿼터스 언어

• 도메인 주도 설계의 핵심 원칙은 모델 기반의 언어를 사용하는 것이다. 모델은 소프트웨어와 도메인이 서로 교차하는 지점이기 때문에 모델 기반 언어를 사용하는 것이 가장 적절하다.
• 모델을 언어의 중추로 사용하라. 팀이 사용하는 모든 의사소통의 형식에 항상 이 언어가 사용되도록 확인하라
• 유비쿼터스 언어 : 도메인 기반 모델을 표현한 언어가 프로젝트 전반에 걸쳐 모든 사용자에 의해 항상 사용되어야 한다는 의미.
• 새로운 모델에 부합하도록 리팩터링 하라. 늘 쓰는 단어의 의미에 서로 합의하는 식으로 혼란을 해소하라.
• 만약 도메인 전문가가 언어의 어떤 부분을 이해할 수 없다면 잘못 설계 되었을 확률이 높다. 모호함, 불일치를 늘 검토하라

도메인 주도 설계

• 핵심 개념을 매우 정확하게 반영하는 모델을 만들어야 한다.
• 도메인 모델링과 설계를 밀접하게 관련시켜라
• 개발자들을 피드백 제공자로 동참시켜라
• 코드를 작성하는 사람들은 모델을 아주 잘 알고 있어야 하고, 모델의 무결성에 대해 책임감을 느껴야 한다. 코드의 변경이 곧 모델의 변경을 의미한다는 것을 깨달아야 한다.
• 모델 주도 설계를 위한 블록

  

  출처 : DDD Quickly

   
  • 계층형 아키텍처
    • 프로그램 전체가 매우 단순한 상태여야 한다. 따라서 복잡한 프로그램을 '레이어'로 분할해야 한다. 하나의 레이어에 도메인과 관련된 모든 코드를 집중시켜서, 타 레이어로부터 독립적으로 만들어야 한다.
    • 도메인 레이어는 핵심 도메인이슈에만 집중해야 한다.

      

      출처 : DDD Quickly

  • 엔티티 : 여러 상태를 거치는 동안에도 동일한 값을 유지하는 식별자를 지니는 유형의 객체. (ex. 계좌번호. 주민등록번호) 시스템의 전 생명주기 동안, 또는 그 이상으로 확장될 수 있는 연속성과 식별성의 흐름이 중요
  • 값 객체 : 하나의 객체가 도메인의 어떠한 측면을 표현하는 데 사용되지만 식별자가 없는 경우 ( 엔티티 객체와 구분 필요)
  • 서비스 : 도메인의 행위 가운데 어떤 행동이나 일부 동사는 어느 객체에도 속하지 않는다. 이러한 유형의 행위가 도메인에서 식별되었을 때, 가장 좋은 해결 방법은 이러한 행위를 서비스로 정의하는 것이다. 서비스 객체는 내부적인 상태를 가지지 않으면서, 단순히 도메인에 기능을 제공하는 목적을 지닌다.
    • 서비스의 세가지 특징
    1. 서비스에 의해 수행되는 오퍼레이션은 일반적으로 엔티티 또는 값 객체에 속할 수 없는 도메인의 개념을 나타낸다.
    2. 수행되는 오퍼레이션은 도메인의 다른 객체를 참조한다.
    3. 오퍼레이션은 상태를 저장하지 않는다. (stateless)
  • 모듈화 : 관련된 개념과 작업을 조직화하여 복잡도를 감소시키는 기법
  • 설계에서 모듈을 사용할 때는 응집도는 높이고 결합도는 낮추는 방향으로 적용해야 함
  • 도메인 객체의 생명주기 관리를 위한 세 가지 패턴
    1. 집합 (Aggregate) : 객체의 소유권과 경계를 정의하는 데 사용되는 패턴
       • 데이터를 변경할 때 하나의 단위로 간주되는 괸련된 객체들의 집합
       • 다른 객체들은 root에 대한 참조만 지니게 하라
    2. 팩토리(Factory) : 객체의 생성과 저장을 도와주기 위한 설계 패턴
       • 생성 절차를, 쪼갤 수 없는 원자적인 상태로 만들어야 함
       • 다른 객체를 생성하는 데 필요한 지식을 포함하지만, 외부에 드러내지 않는 객체 메서드
    3. 레포지토리(Repository) : 객체의 생성과 저장을 도와주기 위한 설계 패턴
       • 객체의 참조를 얻는 로직을 캡슐화하기 위해 사용.
       • 도메인 객체가 도메인의 다른 객체의 참조를 얻고자 하부의 영속성을 보장하는 인프라스트럭쳐를 참조할 필요가 없어지는 것
  레포지토리와 팩토리를 혼용하면 안됨 : 팩토리는 '순수 도메인'이며 새로운 객체를 생성해야 하는 반면 레포지토리는 인프라스트럭쳐와 이어지며, 이미 생성되어 있는 객체를 검색해야 한다.

  

  출처 : DDD Quickly

깊은 통찰을 향한 리팩터링

지속적인 리팩터링 : 설계와 개발 공정 동안에, 우리는 종종 작업을 멈추고, 코드를 살펴보아야 한다.

• 모델링에 대해서 우리가 제일 먼저 배운 것은 비즈니스 명세를 읽고 명사(to class)와 동사(to method)를 찾는 것
• 핵심 개념 드러내기
  • 암시적 개념을 인지하고, 그것이 도메인 개념이라면 그냥 남겨두어서는 안되며 모델과 설계에 반영해야한다.

모델 무결성 보존

출처 : DDD Quickly

• 당신의 최고의 재능을 핵심 도메인에 쏟고, 핵심 도메인을 기준으로 사람을 채용하라. 깊이 있는 모델을 찾고, 유연한 설계를 만들기위해 핵심적인 부분에 노력을 쏟아라. 시스템의 비전을 충실하게 만들어라. 여타의 파트에 대해 투자할지 고민할 때, 정제된 핵심 부분을 지원하는 목적에 얼마만큼 기여하는지 검토하여 투자 여부를 결정하라.
• 최고의 개발지들을 핵심 도메인의 구현에 할당하는 것도 중요하다. 도메인의 비즈니스 로직은 지루하고 보상이 없는 것이다. 그럼에도 불구하고, 도메인의 비즈니스 로직은 도메인의 심장이다. 만약 핵심 비즈니스 로직이 제 역할을 하지 못한다면, 멋진 기술적 부가 기능은 모두 무용지물이 된다.

오늘날 DDD는 중요하다

• DDD는 팀 전체가 함께 하는 거대한 작업
• 도메인 모델링의 위험을 늘 기억하라
  • 단순한 상태를 유지하라
  • 구체적인 시나리오에 초점을 맞추라.
  • DDD를 모든 것에 적용하려고 하지마라. 어느 부분에 적용할지 결정하라. 그리고 그 경계 바깥에 있는 것들에 대해서는 신경쓰지 마라.
  • 실험을 많이 하고 실수를 많이 할 것이라고 예상하라. 모델링은 창조적인 작업이다.

짧은 소감 

도서를 완독하고 정리하고 나니 DDD 방법론에 대한 전반적인 지식과 컨텍스트를 이해할 수 있게 되었다.

구체적이고 세세한 설계 방법과 실무 접목을 위해서는 더 공부를 해야겠다.