DDD, 핵사고날에서 도메인끼리의 협력에 대해

Question

현재 DDD와 핵사고날을 혼자 공부하며, 스타트업에서 적용시켜보고있는 주니어 개발자입니다. 현재 Spring boot를 사용하면서 Jpa 기반으로 연관관계(@ManyToOne, @OneToMany 등) 지양하며, 단순 id만을 컬럼으로 가지고 있는 엔티티를 설계했는데요.저는 물리적 데이터베이스(mysql, redis, mongo 등)의 테이블 도큐먼트와 매핑되는 객체를 엔티티, 그리고 어플리케이션 내부에서 사용하게 되는 객체를 도메인이라고 지정해서 엔티티와 도메인의 분리를 해놨습니다. 현재 패키지 구조또한 각각의 도메인 별로 구성해서 나눴습니다. (User, Card, Bike 등등) 여기서 궁금한게 만약 다른 도메인끼리의 협력이 필요한 경우, 예를 들어서 user의 어떠한 usecase에서 현재 타고있는 bike의 이름이 궁금하다던지, 이런 다른 도메인끼리의 협력이 command 혹은 query로 필요한 경우 usecase를 구현한 서비스에서 다른 도메인의 usecase를 호출해도 되는지가 궁금합니다. 저는 이러면 안된다고 생각을 했고, 그럼 패키지 별로의 약한 결합이어도 나중에 모듈화 할때 문제가 된다고 생각했습니다위의 예시를 들면, user의 어떠한 Usecase에서 bike의 도메인에 이름이 궁금해서 이름을 반환해주는 usecase가 있다고 했을때, user패키지에는 bike 패키지 안에있는 usecase를 가져갈수밖에 없다. 라고 생각을했습니다. 그래서 저는 이경우에 bikeEntity와 1대1로 매핑이 되는 도메인은 도메인으로서 bike 그자체의 책임을 가지고 가고, user 패키지 안에 bike의 정보를 가져올수있는 엔티티를 만들어 필요한 정보를 제때제때 꺼내쓰는 방법을 생각했습니다. 즉, 하나의 테이블, 혹은 도큐먼트를 여러개의 엔티티에 매핑을 시키는 셈인거죠. 물론 command는 원본 엔티티에서만 가능하게 한다고 생각했습니다.그래서 지금 제가 내린 결론은 다른 도메인에서의 usecase의 협력이 필요하면 usecase를 조합하는 orchestrator를 만들어서 거기서 조합을 하자는 결론을 내렸는데, 문제는 이경우, 도메인의 협력이 많은 경우 결국 usecase의 '짬통,,?' 이 될것같습니다... 혹시 어떤게 맞는 방법일까요,,? 또한 현업에서는 어떻게 구현하는지 궁금합니다...긴글 읽어주셔서 감사합니다.

chytonpide · Answer

저는 물리적 데이터베이스(mysql, redis, mongo 등)의 테이블 도큐먼트와 매핑되는 객체를 엔티티, 그리고 어플리케이션 내부에서 사용하게 되는 객체를 도메인이라고 지정해서 엔티티와 도메인의 분리를 해놨습니다.UserEntity.toDomain() 이런식으로 도메인으로 변경하는건가요? 굳이 이렇게까지 할 필요가 있나 싶습니다.도메인 모델을 그대로 db에 저장하는 형태가 낫지 않을까요?repository를 interface 로 해 두면 db기술은 언제든 변경할 수 있습니다. (JPA 쓰면 도메인모델에 어노테이션이 남지만 어노테이션 정도야 뭐..)그래서 저는 이경우에 bikeEntity와 1대1로 매핑이 되는 도메인은 도메인으로서 bike 그자체의 책임을 가지고 가고, user 패키지 안에 bike의 정보를 가져올수있는 엔티티를 만들어 필요한 정보를 제때제때 꺼내쓰는 방법을 생각했습니다. 즉, 하나의 테이블, 혹은 도큐먼트를 여러개의 엔티티에 매핑을 시키는 셈인거죠. 물론 command는 원본 엔티티에서만 가능하게 한다고 생각했습니다.대충 아이디어는 맞습니다. 일단 쿼리랑 커멘드를 분리하셔서 생각하셔야 합니다. 쿼리의 경우 예를들어 어떤 화면에서 유저랑 바이크의 정보가 둘다 필요하다고 한다면,어떤 레이어에서 이것들을 조합해서 dto 로 돌려주는 형태가 됩니다. 보통작은 회사에서 찐으로 MSA를 사용하지는 않고 Modular Monolith 과 같은 아키텍처를 사용하기 때문에다른 서비스에 직접 의존해서 이것들을 조합하기도 하고, 명확하게 분리하기 위해서 엔드포인트를 두드려서 각 서버에 데이터를 요청해서 그것을 조합하기도 합니다.전자의 겨우 예를들어, quries 서비스는 downstream 서비스(각 서비스의 클라이언트가 되는 서비스)로 각 서비스에 직접 의존해도 된다고 정한 다음, 아래처럼 각 서비스에 직접 의존하는 코드를 작성하고 dto을 조합해서 되돌려주는 식 입니다.quries.getUserBikeDto(userId) // 호출// 쿼리즈 내부 val user = userRepository.findById(userId) val bike = bikeRepository.findByUserId(userId) val userBikeDto = UserBikeDto(user, bike)커멘드의 경우도 비슷합니다. 여러 서비스의 오퍼레이션을 실행함으로써 완성되는 유즈케이스는 orchestration 서비스를 만들고 이 안에 프로세스 형태로 위치시킵니다.이때 saga 와 같은 패턴이 사용되고요. 보통 기술은 apacheCamel 을 많이 씁니다.이렇게 하면 각 서비스는 비교적 단순한 엔드포인트만 가지게되고, 복잡한 화면을 위한 쿼리나, 유즈케이스는 quries 서비스, orchestration 서비스에 위치하게 됩니다.

집킨 · Answer

도메인 -> 도메인 의존은 DDD의 철학에서 벗어난 개념이고 이럴땐 도메인 서비스(질문자님이 생각하시는 오케스트레이터와 같은 개념이죠)에서 조합해야합니다

katastrophe · Answer

그래서 지금 제가 내린 결론은 다른 도메인에서의 usecase의 협력이 필요하면 usecase를 조합하는 orchestrator를 만들어서 거기서 조합을 하자는 결론을 내렸는데, 문제는 이경우, 도메인의 협력이 많은 경우 결국 usecase의 '짬통,,?' 이 될것같습니다... useCase 계층 자체를 생각해보시면 실질적으로 비즈니스로직이 일어나는 Domain 계층에 위임 전 단계인 Facade 역할을 하는 상위 계층입니다.이 Application 계층은 기본적으로 오케스트레이션 역할을하며 다른 도메인의 Query 가 필요할 때 값 타입을 불러오기위한 Port 를 usecase 계층에서 구성하는 방식으로, Command 일땐 도메인에서 이벤트를 발행하여 다른 도메인의 루트 어그리거트에서 받는식으로 처리 합니다.

장독깨기 · Answer

아,... 수단이 목적을 앞서면 안 되지 않을까요.Jpa 기반으로 연관관계(@ManyToOne, @OneToMany 등) 지양하며, 단순 id만을 컬럼으로 가지고 있는 엔티티를 설계특히, 비지니스 시스템은 데이터와 그 연관 관계가 굉장히 중요합니다.이게 다 이유가 있는 것이구요, 개발자는 이걸 잘해야 합니다.오지랖 같긴 하지만 ㅎ, 생각을 한 번 해보는 것이 좋을 거 같습니다.

Iswn · Answer

결국 각 도메인이 상호작용을긴밀한 협력(혹은 응집력 좋은)으로 볼 지 유연함이 떨어지는 결합으로 볼지 고민하신거같습니다현재 시스템의 주요 요구사항을 살펴보세요.그러면 다소 번거롭지만 유연하고 확장성 좋은 설계, 아니면 직관적이고 이해하기 좋은 코드적재적소에 선택할 수 있는 기준을 정하는데 도움이 됩니다.갠적으로 저는 요즘에 네카라쿠베 수준의 대규모시스템을 개발하는게 아니라면도메인 영역에선 직관적이고 이해하기 좋은 코드가 좋다고 생각합니다.시스템이 대박치면 그 때 유연하고 확장성 좋은 코드로 바꿔도 좋지 않을까요

namoda · Answer

최근에 카카오페이의 여신코어 DDD로 구축하기라는 글을 보았습니다.https://tech.kakaopay.com/post/backend-domain-driven-design/기술로그이다 보니 아무래도 기술 중심으로 내용이 흘러가는데 DDD의 본질보다는 DDD의 프랙티스를 수행하는 것 같아서 아쉬움이 느꼈습니다. 마치 우리는 애자일한다면서 "합시다 데일리 스크럼" 하는 느낌을 받았습니다.이 글도 DDD에 대하여 이야기하면서,Entity, Use Case, CQRS, Domain 등의 수준으로 그치는 것을 보면서 사람들이 생각하는 DDD는 과연 무엇일까 생각을 했습니다.Jiuuuunnii 님은 DDD가 무엇이고 DDD를 한다는 것은 어떤 의미일까요?

skrevolve · Answer

모든 논리를 각설하고 얘기 드리자면 디자인패턴은 정해진게 없습니다.제대로된 디자인패턴 외국 서적 읽어보세요.잠이 올겁니다.결국 기술적인건 선택이고 환경에 따라서 디자인패턴을 만드는것이 궁긍적인 목표라고 볼수있습니다.패턴에 얽매이지 마세요.교과석적인 흐름에 얽매이지 마세요.이해하는 수간 간단하게 구성이 될수있고이해가 되지 않으면 수백가지 고민이 있을겁니다

호두까면주름생김 · Answer

@작성자에게예를 들어서 user의 어떠한 usecase에서 현재 타고있는 bike의 이름이 궁금하다던지, 이런 다른 도메인끼리의 협력이 command 혹은 query로 필요한 경우 usecase를 구현한 서비스에서 다른 도메인의 usecase를 호출해도 되는지가 궁금합니다. 답변:- 안됌. 도메인끼리의 협력은 각 도메인이 객체로서 자신이 할 수 있는 관심사만 처리해야함. 만약 user 가 bike usecase 를 알고 있는 시점(바이크를 직접 불러와 사용)은 유저가 bike 의 관심사를 내포하고 있다고 생각하게 될거임. 메세지를 보내셈. 메세지를.지금 상황:철수: 영희야. 니네집 김치가 필요해.영희: (영희네 김치 냉장고를 철수에게 주며) 여기서 너가 꺼내먹어.발생할 수 있는 문제점:영희: 어? 오늘 사온 배추 어디갔지?실제: (철수가 배추가 보이길래 걍 집어먹음)DDD 도메인간 협력 관계:철수: 영희야. 니네집 김치가 필요해.영희: 잠시만! (김치를 꺼내며). 얼마나 필요해?철수: 한포기영희: (두 포기를 다시 냉장고에 집어넣으며) 여기. 택배로 보낼게!

DDD, 핵사고날에서 도메인끼리의 협력에 대해

8개의 답변

Q&A 목록