-
질문 & 답변
카테고리
-
세부 분야
백엔드
-
해결 여부
해결됨
몇가지 질문
23.12.27 22:12 작성 23.12.27 22:12 수정 조회수 166
2
안녕하세요. 강의 잘 보았습니다.
몇가지 궁금증이 생겼는데요.
Aggregate간의 의존성과 결합도를 해소하기 위해
보통의 DDD 예제에서 Event를 사용하는 법을 많이 알려주고 있는데요. 이 방식을 채택하기에 모종의 이유로 실무에서 적용하지 못한다고 하였을때는 어떤식으로 의존성을 제거 또는 낮출수 있는지 궁금합니다.
두번째로는
회원 도메인에서의 회원과 주문 도메인의 회원, 그리고 배송 도메인에서의 회원이 각 도메인별로 갖는 의미와 역할/기능 이 다를것 같은데요.
예를 들어
주문 context에서 회원에게 특정 기능이 필요하다고 가정했을때 이 코드가 어떤 entity에 작성이 되어야 하는지 궁금합니다.
기존의 user entity에 코드를 작성해야 되는지
아니면 order context내에 user entity를 새로 만들어서 코드 작성해야 되는지 궁금합니다.
답변을 작성해보세요.
1
애프터캠프
지식공유자2023.12.31
두번째 답변을 드리면 저라면, 주문 context에서 회원에게 특정 기능이 필요하다면 주문 context에서의 User를 대표하는 Entity를 생성하고 그곳에 기능을 추가할 것 같습니다.
1
애프터캠프
지식공유자2023.12.31
안녕하세요 답변이 조금 늦어서 죄송합니다 :(
Aggregate간의 의존성과 결합도를 해소하기 위해 보통의 DDD 예제에서 Event를 사용하는 법을 많이 알려주고 있는데요. 이 방식을 채택하기에 모종의 이유로 실무에서 적용하지 못한다고 하였을때는 어떤식으로 의존성을 제거 또는 낮출수 있는지 궁금합니다.
모종의 이유라고 하시면 Kafka 같은 비동기 메시지 큐를 사용하기가 어려운 경우를 말할까요? 아니면 비즈니스 팀에게 DDD에 대한 내용을 교육시켜서 비즈니스 룰에서 이벤트를 찾아내는 것이 어려운 경우일까요?
애프터캠프
지식공유자2023.12.31
네 개인적인 생각으로는, 데이터베이스를 사용하고 있다면 그걸 메시지 큐로 활용을 할 수 있을 것 같습니다.
MySQL, PostgreSQL 같은 경우엔 테이블을, MongoDB를 사용하고 계시다면 Collections을 생성하고 (message_queue 라는 이름으로) 한쪽에서 이벤트를 테이블이나 컬렉션에 넣으면 되겠습니다. 이 이벤트를 소비하는 곳에서는 주기적으로 (polling) 테이블을 검사해서 새로운 이벤트가 있다면 처리하는 방법이 있습니다.
그런데 위의 방법은 의존성과 결합도를 낮출수 있는 방법의 하나의 수단일 뿐이고 이 목표를 이루기 위해 다양한 방법이 있을 것 같네요.
의존성과 결합도를 낮추기 위한 일반적인 방법이 이벤트 전달 방법 (메시지 큐를 이용한)인 것이고, 이벤트 전달 방법이 불가능하다면
이벤트를 생성하는 것과 수신하는 주체가 같은 서버 안에서 동작한다면
A Aggregate 에서는 AToB() 함수만 호출하고 B Aggregate에서 처리 결과가 성공/실패와 상관없이 바로 리턴합니다 (fire and forget) A에서 B의 함수를 직접 호출하게 되면 서로 간 의존성이 생기기 때문에 중간 Layer를 두는 것입니다.
마찬가지로 다른 서버에서 동작한다면 중간에 API gateway를 두어서 A가 B의 구체적인 함수명을 몰라도 원하는 로직이 실행되도록 하게 하면 될 것 같습니다.
1
인프런 AI 인턴
2023.12.29
안녕하세요, 인프런 AI 인턴입니다.
질문해주신 내용에 대해 답변드리겠습니다.
첫 번째로 도메인 간 의존성과 결합도를 낮추는 방법으로 이벤트를 사용하지 못한다면, 다른 접근 방법으로는 서비스 레이어의 인터페이스 분리, 공유되는 모델의 제한, Repository의 활용 등이 있습니다. 도메인 서비스를 통해 의존성을 명시적으로 관리하거나 느슨하게 연결할 것을 고려할 수 있습니다. 또한, Anti-Corruption Layer 패턴을 적용하여 외부 시스템과의 통신을 격리할 수도 있습니다.
두 번째 질문에 대해선, DDD에서 컨텍스트 별로 회원을 나타내는 엔티티의 의미와 역할이 다를 수 있습니다. 주문 컨텍스트에서 필요한 기능을 판단할 때 다음과 같은 각도로 고려해 볼 수 있습니다:
- 만약 해당 기능이 주문 도메인에만 국한되어 있다면, 주문 컨텍스트 내에서 별도의 엔티티나 값 객체로 모델링할 수 있습니다.
- 기능이 회원 도메인과 밀접하게 관련되고 회원 컨텍스트의 핵심 로직을 반영해야 한다면 기존의 회원 엔티티에 기능을 추가하는 것을 고려할 수 있습니다.
- 여럿 컨텍스트에 걸쳐 사용될 공통 기능이라면 공유 커널을 통한 모델링이나 인터페이스를 통해 해당 기능을 공유할 수 있습니다.
실제로 어떤 접근법을 채택할지는 각 도메인의 요구 사항과 컨텍스트 간의 낮은 결합도를 유지하는 방향성에 따라 결정되어야 할 것입니다.
강의에서 얻은 지식에 대한 깊이 있는 질문에 감사드리며, DDD와 관련된 구체적인 내용을 더 알아보고자 한다면 스프링과 DDD를 접목하여 이벤트를 다루는 방법에 대한 참고 자료를 확인해보시기 바랍니다:
- Spring Data JDBC - 참조 문서 v3.1.5: https://docs.spring.io/spring-data/jdbc/docs/current/reference/html/#core.domain-events
- Spring Data JPA - 참조 문서 v3.1.5: https://docs.spring.io/spring-data/jpa/docs/current/reference/html/#core.domain-events
도움이 되셨길 바라며, 보다 구체적인 사례나 문제에 대해서는 추가적인 질문을 환영합니다.
답변 3