DDD 현실적 적용

아하! 그러면, 어떤 바운디드 컨테스트에서는 클린 아키텍처를 사용할 수 있고, 어떤 바운디드 컨텍스트에서는 DDD 전술적 설게를 사용할 수 있는건가요? 또한, 어떤 애그리거트에서는 클린 아키텍처를 사용할 수 있고, 어떤 애그리거트에서는 DDD 전술적 설게를 사용할 수 있는건가요?

아 넵 맞아요

네.

도메인 유형(핵심,지원,일반)에 따라 핵심 BC 는 헥사고널 아키텍처 + 도메인 모델 중심으로 구현하고, 지원BC는 단순하고 많은 노력이 필요하지 않은 도메인이라 판단되면 레이어드 아키텍처 + 트랜젝션 스크립트 패턴을 적용하는 것처럼 할 수 있습니다.

네 그리고 말씀하신 바 대로 기존 복잡한 레거시에서 마이크로서비스 로 변경 부분을 별도로 분리하는 교살자 패턴 (https://martinfowler.com/bliki/StranglerFigApplication.html ) 도 중요하죠. 제 생각에 소프트웨어 공학에 정답은 없는 것 같아요. 상황에 따라 여러 트레이드 오프가 있고 아키텍처적/설계 판단이 필요하겠죠.

지나고 보면 좋은 판단이었던 경우도 있고 아니었던 판단이 있고요. 거기서 그래도 의미있는 경험이 쌓여 Good 패턴이 되는 것 같습니다. 또 이런 패턴이 모든 상황에 맞는 것은 아니고요. ^ ^

DDD도 마찮가지라고 생각합니다.

빠르게 답변해주셔서 감사합니다! 회사마다 다르겠지만, 이커머스 프로젝트를 기준으로 핵심 도메인와 지원 도메인, 일반 도메인이 될 수 있는 예시 좀 알려주실 수 있나요? 제가 생각하기에는 주문, 결제 등은 핵심 도메인일 것 같은데, 지원 도메인과 일반 도메인은 도통 감이 안잡히더라구요ㅠㅠ지금 DDD 책 5권 읽고 있는데, 머리 속에 잘 안그려 지더라구요ㅠㅠ

아 넵 그런데 그건 정말 상대적인 개념이고 내부에서 결정하는 것이에요. 즉 일하시는 이커머스 회사에서 다른 업무는 다른 이커머스 회사와 차별점이 없는데 예를 들면 상품 카테고리 조회 기능만 굉장히 경쟁력이 있다 라고 결정하면 그것이 핵심 도메인 이 되는 겁니다. 예를 들면 쿠팡같은 회사는 쇼핑기능이 핵심이 아니라 물류라고 생각됩니다.

일반도메인은 중요하지만 이미 솔루션이 나와 있는것이죠 그럴리는 없겠지만 위의 예에서 쿠팡이 물류는 핵심이고 중요하기때문에 자체 개발하지만 쇼핑몰은 잘 만들어진 솔류션을 도입하는 결정을 내릴 수 있는데 이 도메인이 일반입니다.

그리고 지원은 말 그대로 지원이에요. 업무 중요도도 떨어지고, 복잡하지 않지만 없어도 되지만 있으면 도움이 되는 ... 그래서 외주를 쓴다거나, 새로 들어온 신규 구성원에게 OJT용도로 전담케 한다거나...

아 그럼, 핵심 도메인과 일반 도메인은 있되, 지원 도메인은 없을 수도 있는거군요!

1. 만약에 비즈니스적으로 핵심도메인이지만 회사 개발팀 능력상 기술력이 부족해서 솔루션이나 외주를 맡겨야하는 도메인이라면, 어떤 도메인으로 봐야되는건가요? 이렇게 어떤 도메인으로 봐야하는 게 의미 없는 건가요?
   2. 만약에 일반 도메인이었는데, 고객이 생각보다 좋아해서 이부분을 좀더 깊게 비즈니스적으로 차별화 점을 찾아내서 서비스를 한다면, 일반 도메인이었던 도메인이 핵심 도메인이 될 수 있는건가요?
   3. 어떻게 보면, DDD를 잘한다는 거는 도메인 전문가와 협력을 잘하고, 코드로 표현할 수 있는 정보들을 잘 뽑아내는 커뮤니케이션 능력도 중요할 수도 있는거라고 생각하는데 맞을까요?

1. 일반도메인이 아닐까요?

2. 네 가능하다고 생각합니다.

3. 네 그렇죠