[도메인 주도 설계 핵심] 1장: 나에게 도메인 주도 설계는

사실이 아니라 공부한 내용과 생각을 정리한 글입니다. 언제든 가르침을 주신다면 감사하겠습니다.

http://www.yes24.com/Product/Goods/48577718

도메인 주도 설계 핵심 - YES24

DDD가 우리에게 상처를 줄까?

• DDD 가 복잡한 게 아니라 우리가 해결해야 하는 문제가 복잡한 것이다
• DDD는 복잡한 문제를 해결하기 위한 수준 높은 도구들의 모음이다

좋은, 나쁜 그리고 효과적인 설계

• 설계는 필연적이다. 좋은 설계의 대안은 나쁜설계이다. 절대 설계하지 않는 것이 아니다.
• 효과적 설계는 조직이 무엇에 강점을 가져야 하는지 이해시키고, 정확한 소프트웨어 모델을 생성하도록 가이드할 때 사용한다.
• 설계는 단지 어떻게 생겼는지, 어떤 느낌인지가 아니라, 그게 어떻게 동작하는지에 대한 것이다.

전략적 설계(큰그림)

• 전략적 설계부터 시작하지 않으면, 효과적으로 전술적 설계를 적용할 수 없다.
• 비즈니스상 전략적으로 중요한 것, 중요도에 따라 일을 나누는 방법 그리고 필요에따라 통합하는 방법을 다룬다.
• 도구들 -> 바운디드컨텍스트, 보편언어, 서브도메인, 컨텍스트 메핑을 다룰 것이다.

전술적 설계(세부 그림)

• 도메인 모델의 세부사항들을 그리기 위한 도구들
• 엔티티와 값 객체를 알맞은 크기의 애그리게잇으로 묶는 데 사용하는 애그리게잇 패턴
• 도메인 이벤트

학습 과정과 지식의 정제

• DDD는 비즈니스(도메인)와 관련된 지식을 더욱 발전시킬 수 있도록 생각하는 법을 알려준다.
• 또한 이를 빨리 할 수 있도록 도구를 제공한다.

---

내 생각

• DDD(도메인 주도 설계)는 말 그대로 개발을 위한 개발을 하지 말고 도메인(비즈니스 문제해결)을 위한 개발을 하자라는 생각에서 출발한것 같다.
  • 때때로, 우린 도메인(비즈니스 문제)에 집중하기보단 어떻게 구현할지에 더 집중할 때가 있고 이렇게 만들어진 소프트웨어는 도메인을 위한 최적의 소프트웨어가 아닐 수 있다.
• DDD는 우리가 만드는 소프트웨어가 도메인 관점에서 최적의 산출물이 될 수 있도록, 도메인에 대한 명확한 멘털 모델(도메인 모델)을 설계하는데 도움을 주는 도구들의 모임이다.
• 키보드를 두드리기전에 나와 우리 팀이 명확한 도메인 모델을 형성하고 공유하고 있는지 생각해 보자.
  • 만약 도메인 모델이 없다면, 요구사항을 파악하지 않고 개발을 시작하는 것과 같을 수 있고
  • 만약 도메인 모델이 공유되지 않았다면, 각자의 도메인 모델이 합쳐진 진흙 덩어리를 만드는 것과 같을 수 있다
• 팀원들과 함께 도메인 모델을 형성, 공유하고 이렇게 형성된 도메인 모델에 맞춰서 구체적인 소프트웨어를 설계하자. 그렇게 만들어진 소프트웨어는 조금 더 도메인에 가까운 소프트웨어가 될 것이다.
• 도메인 모델을 만드는 게 어렵다면??? -> DDD 책에서 추천하는 도구들을 참고해 보자!

---

참고

• https://goldfishhead.tistory.com/84
• https://www.youtube.com/watch?v=XKGLbh9sXiI