Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • 책에서는 핵심 도메인은 기술적 역량, 차별성, 비교 우위가 있어야 한다고 설명 [247]

    • 하지만 실제로 돈을 버는 핵심 도메인은 기술적 차별성이 없는 경우가 많음 [249]

      • 예: 삼성전자, 넷플릭스, 아마존 등은 기술이 아니라 외부 요인(협상력, 콘텐츠 등)으로 돈을 법 [254]

  • 기술적 우위의 정의가 매우 다양하고, 실제로는 뻥이 많음 [264]

    • "나만 만들 수 있다"는 주장도 현실에서는 거의 없음 [270]

  • 핵심 도메인 내재화(자체 개발)는 현실적으로 어렵고, 오히려 외주 비율이 높음 [295]

    • 대기업, 은행, 국가기관 등도 핵심 도메인을 외주로 처리함 [298]

    • 오프라인 예시: 건물 주차장, 자본잉여금 관리 등도 외부에 맡김 [305]

    • IT 기업도 외주인력, 오픈소스, 오픈 API 등 외부 솔루션을 적극 활용 [317]

    • 핵심 도메인일수록 외주 비율이 높고, 빠른 대응이 중요함 [329]

5. 핵심 도메인 내재화와 기술적 차별성의 현실 [244]

  • 책에서는 핵심 도메인은 기술적 역량, 차별성, 비교 우위가 있어야 한다고 설명 [247]

    • 하지만 실제로 돈을 버는 핵심 도메인은 기술적 차별성이 없는 경우가 많음 [249]

      • 예: 삼성전자, 넷플릭스, 아마존 등은 기술이 아니라 외부 요인(협상력, 콘텐츠 등)으로 돈을 법 [254]

  • 기술적 우위의 정의가 매우 다양하고, 실제로는 뻥이 많음 [264]

    • "나만 만들 수 있다"는 주장도 현실에서는 거의 없음 [270]

  • 핵심 도메인 내재화(자체 개발)는 현실적으로 어렵고, 오히려 외주 비율이 높음 [295]

    • 대기업, 은행, 국가기관 등도 핵심 도메인을 외주로 처리함 [298]

    • 오프라인 예시: 건물 주차장, 자본잉여금 관리 등도 외부에 맡김 [305]

    • IT 기업도 외주인력, 오픈소스, 오픈 API 등 외부 솔루션을 적극 활용 [317]

    • 핵심 도메인일수록 외주 비율이 높고, 빠른 대응이 중요함 [329]


6. 유비쿼터스 언어(공통 언어)와 도메인 용어의 한계 [347]

...

  • DDD는 "문제를 먼저 정의하고, 도메인을 깊이 이해한 뒤 해결책을 도출하는 방식"에 최적화되어 있습니다.

  • 따라서 해외(특히 유럽, 미국 등지)의 분석 중심, 가설 기반, 실험적 접근 방식과 가장 잘 어울립니다.

  • 반면, 해결책을 먼저 상정하고 역으로 문제를 맞춰가는 조직 문화에서는 DDD가 형식적으로만 적용되고 실제 효과는 떨어질 수 있습니다.

마치며

나는 DDD신봉자도 반대자도 아니며 단지 뭔가 배울것이 어딘가에 있을것이다란 작은믿음이 있으며 , 프로젝트 초기팀을 셋업할때 이것을 꼭 적용하기 보다 "그냥 도움되는것있으면 배워~" 정도로 소개를 합니다.

적용하기 어려운 이유를 찾는것도 역시 뭔가를 배우고 있는것이고 통찰력을 기를수 있는 지점이라 생각되어 왜? 적용하기 어려운가를 조사하고 정리해보았습니다.

가령 MSA는 왜 적용하기 어려운가? 를 열심히 심층분석하다 보면~ 역설적으로 그것을 배워 나가지 않을까요? 안되서 포기해야할 이유를 찾는것이아니라 안되는 이유를 찾아 극복하다보면 우리만의 방식을 찾고 만들어내지 않을까?

다음은 AI 에이전트는 수직적이지도 않고 수평적이지도 않습니다. 그냥 수행할 뿐이죠 과거의 개발방법론중 좋은 컨셉을 모아 시키면 되지 않을까? 시도한 컨텐츠입니다.

NEXT

...