인프런 커뮤니티 질문&답변

백린이님의 프로필 이미지

작성한 질문수

Microservice 내부 아키텍처 와 EventStorming 설계

DDD 현실적 적용

작성

·

489

1

DDD 공부하면서 느낀 점이 현실적으로 완전한 DDD를 하는 것은 어렵지만 부분적으로도 적용시켜볼 수 있겠다라는 생각이 들었습니다. 예를 들면 전략적 설계는 MSA 로 전환할 때, 전술적 설계는 JPA를 사용할 때 활용해 볼 수 있겠다 싶은데 맞게 이해한 걸까요?

답변 3

1

han jeong heon님의 프로필 이미지
han jeong heon
지식공유자

아 네 대부분 그렇게 적용하는 듯하네요 😀

조직의 성숙도나 역량에 따라 적용하는 것이 맞는 것 같아요

백린이님의 프로필 이미지
백린이
질문자

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

 

han jeong heon님의 프로필 이미지
han jeong heon
지식공유자

아 넵 맞아요

0

백린이님의 프로필 이미지
백린이
질문자

어쩌면, 핵심 도메인, 일반 도메인, 지원 도메인 용어보다 어떤 영역을 자체 개발하고, 어떤 영역을 솔루션으로 개발하고, 어떤 영역을 외주로 개발할 것인지 판단하는게 중요하고, 그리고 그렇게 나누는 기준에 대한 해답은 도메인 자체, 회사 사정, 개발팀 사정에서 찾을 수 있겠네요?ㅎㅎ

0

백린이님의 프로필 이미지
백린이
질문자

  1. 그러면, 회사 프로젝트에 DDD를 적용하고 싶다고 했을 때, 프로젝트 에서 따로 독립적으로 바운디드 컨텍스트를 만들어 낼만한 도메인 또는 특정 기능을 발견해서 바운디드 컨텍스트를 만들어서 그 부분만 Aggregate 등으로 전술적 설계를 한다고 하면, DDD 했다고 볼 수 있는건가요?

  2. 어쩌면, DDD를 잘한다고 하는 것은 진흙덩어리에서 독립적으로 떼어낼 수 있는 부분을 가시 바르듯 잘 발라내는 것도 중요한 역량이겠네요?

     

han jeong heon님의 프로필 이미지
han jeong heon
지식공유자

네.

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

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

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

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

백린이님의 프로필 이미지
백린이
질문자

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

han jeong heon님의 프로필 이미지
han jeong heon
지식공유자

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

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

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

백린이님의 프로필 이미지
백린이
질문자

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

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

han jeong heon님의 프로필 이미지
han jeong heon
지식공유자

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

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

  3. 네 그렇죠