결론

1. DDD를 공부하면서 느낀 점
   1. 객체지향 5원칙이 있다. DDD는 이 5원칙을 개념적으로 더 구체화시키는 설계 기법이라고 생각되었다. "어떻게 하면 더 객체지향스럽게 만들 수 있을까?", "어떻게 하면 좀 더 의사소통을 쉽게 할 수 있을까?", "어떻게 하면 유지보수의 비용을 줄일 수 있을까?" 등등.. 결국 DDD는 프로젝트를 객체지향답게 개발하는 방법이다.
      • SRP(단일 책임 원칙)
      • OCP(개방-폐쇄 원칙)
      • LSP(리스코프 치환 원칙)
      • DIP(의존 역전 원칙)
      • ISP(인터페이스 분리 원칙)
   2. TDD에 관해서 부정적으로 생각했었던 부분이 바뀌었다. TDD에 대해서 부정적이 었던 이유는 TDD를 도입해야 한다고 말하는 사람들 중 왜 TDD가 실패하는지에 대해서 말해주는 사람이 없었다. 내가 생각하는 TDD의 실패 이유는 Interface이다. 왜 Interface일까? 구체적인 코드를 개발하기 전 테스트를 만들려면 코드에 대한 Interface가 필요한데 개발을 진행하다 보면 Inteface가 빈번이 변경된다. 이럴 때마다 테스트의 수정이 일어나고 결국 발목을 잡게 된다. 그럼 어떻게 해야 할까? 물론 Interface가 변경되는 것은 막을 수 없지만, DDD에서 Distillation 과정을 통해 Aggregate, Service, Module의 개념이 잘 적용되었을 때 테스트의 수정 횟수와 범위가 확연하게 줄어든다. 때문에 TDD의 성공 확률도 크게 증가할 것이다.
   3. DDD에서 나오는 내용을 100% 완벽하게 적용해야 좋은 것은 아니다. 개발 중인 프로젝트의 상황에 맞게 적용해야 한다. 무엇보다 중요한 점은 팀원과의 합의, 의지, 공유, 점진적인 개선이다.
   4. 첫 번째로 2년 전 DDD를 모르는 시점에서 개발했던 프로젝트는 객체지향스럽게 만들기로 팀원들과 합의하에 진행했다. Module을 나누고 Layer를 나누고 최대한 Dependency를 분리하는 것에 초점을 맞췄다. 이전에 하던 프로젝트와 비교해서 개선된 느낌은 있었지만 피부로 와 닿지 않았다.  두 번째로 다른 신규 프로젝트를 진행했다. 첫 번째 프로젝트에서 불편하다고 느꼈던 점들, 개선해야 할 점들을 정리했다. 한 가지 예를 들면 Repository를 Infrastructure Layer에 만들면서 느끼는 불편함이었다. JPA의 특정 기능을 개발할 때 어쩔 수 없이 만들어지는 중복 코드와 이로 인해 나도 잘 모르는 사이에 발생하는 Dependency의 침범이 있었다. 두 번째 프로젝트는 이를 개선하는 방향으로 진행되었다. 이때부터 운영의 편의성과 Domain의 개념이 명확하게 드러나기 시작했다. 급하게 들어오는 요청에도 변경되는 부분과 영향도가 최소화되었다. 점점 변경에 대해서 자신감이 붙었고, 이전보다 훨씬 안정적인 운영이 가능하게 되었다.   마지막으로 DDD내용과 프로젝트를 비교하면서 부족한 부분, 개선해야 할 부분과 방법을 고민하고 있다.
2. DDD에서 헷갈렸었던 점
   
   1. 가장 헷갈렸었던 부분은 Module과 Aggregate이다. 책에는 분명 Module이 나와있지만, 국내 DDD를 정리한 글들을 보면 이 Module에 관한 내용이 없다. 그렇다고 책에 내용만 보면 Aggregate와 너무 헷갈렸었다. 내가 내린 결론은 Module은 개념적 큰 단위이자 Package이다. Aggregate는 개념적으로 작은 단위로 묶을 수 있는 Entity의 집합이다.
   2. 개념인 부분을 여러 관점과 시점에서 설명하다 니 비슷한 내용들이 조금씩 겹치는 부분이 많았다. 어느 정도 머리로는 분류가 되었지만, 확실하게 습득하는 것은 실습을 하면서 체득하는 게 좋을 것 같다.