인프런 커뮤니티 질문&답변
작성한 질문수
도메인 패키지의 격벽 범위와 레이어 간 경계에 대한 질문
해결된 질문
작성
·
31
·
수정됨
1
안녕하세요. 제미니님! 강의 잘 들었습니다. 완강을 한 이후 다음 강의를 수강하기 전 프로젝트 구조를 다시 살펴보며 역할과 책임, 레이어의 책임에 대해 고민을 해보고 있습니다. 고민하던 중 궁금증이 생겨 질문 남깁니다!
격벽은 도메인 혹은 개념 간의 경계를 구분하는 것으로 이해했습니다. 그런데 현재 domain/ 패키지 내부에 존재하는 클래스도 이 격벽을 지켜야 하는 것 아닌가요? 현재 구조에서는 비즈니스 레이어와 구현 레이어 모두에서 다른 도메인의 리포지토리에 접근하고 있어 도메인 패키지 안에서 격벽이 유지되지 않는 것처럼 보입니다.
예를 들어:
- PaymentService가 OrderRepository, OwnedCouponRepository에 직접 접근
- ReviewPolicyValidator가 OrderItemRepository에 직접 접근
- CancelService가 PaymentRepository, OrderRepository, OwnedCouponRepository에 직접 접근
현재는 flat한 패키지 구조라 눈에 잘 드러나지 않지만, 만약 도메인별로 패키지를분리한다면(domain.order, domain.payment 등) cross-domain
의존성이 명시적으로 드러나게 됩니다. 격벽을 세웠다면 PaymentService는
OrderRepository를 직접 사용하는 대신 OrderService를 통해 접근하는 것이 격벽의
취지에 맞는 것 아닌지 궁금합니다.
비즈니스 레이어가 도메인 패키지 내부에 있는 이유가 궁금합니다. 비즈니스 레이어는 여러 도메인을 조합해 비즈니스 로직을 수행하는 레이어라고 이해했는데요. 그렇다면 비즈니스 레이어는 도메인 패키지 내부가 아니라 외부에 위치하는 것이 더 적절하지 않나요?
혹시 제가 강의 내용을 잘못 이해하고 있는 부분이 있다면 바로 잡아주시면 감사하겠습니다. 다음 강의도 빠르게 수강해보겠습니다!
감사합니다.
답변 2
0
안녕하세요 질문 감사드립니다!
[질문1]
우선 적어주신 예제들도 격벽은 잘 지켜지고 있는 상태입니다, 개념(일반적으로 모호하게 쓰는 도메인이란 용어랑은 다름)에 대한 격벽이 둘러져있고, 격벽을 통과할 수 있는 허용 된 개념을 관리하고 있고, 적어주신 대상들이 모두 격벽을 넘는데 허용이 된 협력 관계의 개념들 때문에 격벽은 잘 유지되고 있는 상태입니다.
예를들면 개념정리 내용을 보면 Payment 개념은 격벽을 통과하여 Order, Point, OwnedCoupon 와 관계를 맺고 있습니다
그 상태 자체로 Repository를 접근하거나 도구 레이어에 접근해서 도구 클래스를 사용하는 것이 격벽을 지키지 않는 것은 아닙니다
(아래도 적었지만 Repository 를 접근할수 있게 하냐는 다른 관점의 문제입니다, 격벽의 참조 허용은 A개념이 B개념을 알아도 되는가? 허용할 것인가? 가 전부입니다, 방화벽(Allow/Disallow)을 생각해보셔도 좋습니다)
추가로 당연하지만 Service가 Service를 사용하는 방식 등에 대해 전략을 정하기 나름입니다만 제 경우는 비즈니스 로직 클래스가 다른 비즈니스 로직 클래스를 접근하는 것을 선호하지 않습니다
그렇지만 Repository 를 직접 접근하는 것은 또 레이어 규칙을 어떻게 가져가야할지 전략을 선택해야하는 부분이긴합니다
(관련 내용은 지속 성장 가능한 소프트웨어를 만들어가는 방법(동명의 인프런 무료 강의도 존재)에 있으니 궁금하시면 참고 부탁드립니다)
패키지을 나눴을 때 참조하고있는 다른 개념이 보여지게 된다면 그것 자체가 관계가 있다는 것을 보여주는 것이고, 그런 참조 상태를 보면서 격벽을 누구나 너무 쉽게 넘나드는지, 누가 넘을것인지, 어느 방향으로 넘길것인지 이런 것들을 고민하면 좋을 것 같습니다
[질문2]
비즈니스 레이어는 여러 도메인을 조합해 비즈니스 로직을 수행하는 레이어라고 이해했는데요.
이 부분에 대한 이해가 저의 의도와 다른 것 같습니다, 비즈니스 레이어는 지정 된 개념(결제, 주문 등)에 대한 비즈니스 로직을 수행하는 레이어라고 이해하는 것이 더 적절할 것 같습니다
그래서 단순히 여러 도메인을 조합 하는 관점 보다는 한 개념의 비즈니스 로직을 잘 나타내는 것이 주 목적이기 때문에 도메인 패키지에 있어도 괜찮다고 봅니다.
(그래서 격벽을 세우고 참조 관계를 어떻게 맺을지 관리해야하는 것이죠, 아무나 격벽을 막 넘나들면 안 되기 때문에)
제 경우 패키지는 다양한 전략으로 사용하지만 보통 비즈니스 로직을 조합해야할 때 를 별도 패키지를 구성하는 것을 고민+검토하는 편입니다.
이는 각각의 개념에 대한 비즈니스가 탄탄한 상태에서, 비즈니스와 비즈니스가 융합되는 형태가 보여질 때 사용하는 편입니다
강의 기준 적절한 예제가 안 떠오르는데..... 대략 포인트와 쿠폰이 융합된 포인트쿠폰이란게 생긴다면 한쪽의 비즈니스에 속해있는 것이 아니기 때문에 융합하는 고민을 해볼 것 같습니다
(복합결제 << 이런 것들도 있겠네요)
모쪼록 답이 되었길 바랍니다! 감사합니다!
0
안녕하세요, 인프런 AI 인턴입니다. xx님.
질문해 주신 내용은 격벽의 범위와 레이어 간의 책임에 대한 깊이 있는 고민을 담고 있습니다. 이러한 구조적 고민은 아키텍처 설계에 있어 매우 중요한 부분이며, 도메인 간의 명확한 경계를 설정하는 것이 유지보수성과 확장성에 큰 영향을 미칩니다.
1. 도메인 안에서의 격벽 유지
격벽은 도메인 간에 명확하게 역할을 나누고 해당 경계를 관리하는 방식입니다. 그러나 특정 서비스가 다른 도메인의 리포지토리에 접근하는 것은 자연스럽게 발생할 수 있는 의존 관계이며, 코드의 복잡도를 증가시킬 수 있습니다. 다만, 각 서비스가 여러 리포지토리에 직접 접근하는 것이 복잡성이 증가하는 중요한 원인이 될 수 있습니다. 이를 해결하기 위한 몇 가지 방법을 제안드립니다.
- 간접 접근 권장: 각 도메인의 리포지토리에 직접 접근하는 대신, 해당 도메인의 서비스 계층을 통해 필요한 데이터를 가져오는 방식을 사용해보세요. 이렇게 하면 도메인 경계에 일관성을 부여할 수 있습니다.
- 의존성 역전: 서비스 레벨에서 필요한 데이터를 노출하는 방식을 사용하여, 도메인의 경계가 잘 드러날 수 있도록 합니다.
2. 비즈니스 레이어의 위치
비즈니스 로직을 담당하는 계층은 도메인 내에 존재할 수 있으며, 도메인 간의 조합이 필요한 비즈니스 규칙을 잘 표현할 수 있습니다. 그러나 커다란 프로젝트에서는 비즈니스 레이어를 도메인의 외부로 위치시켜, 도메인별로 각자의 내부 로직이 잘 분리될 수 있도록 하는 것도 좋은 선택이 될 수 있습니다.
- 도메인 외부 위치: 비즈니스 로직이 여러 도메인의 데이터를 조합하는 경우 외부 비즈니스 레이어를 위치시킴으로써 각 도메인의 독립성을 유지할 수 있습니다.
- 모듈화 고려: 각 도메인을 모듈화하고, 특정 비즈니스 규칙이 여러 도메인에 걸쳐 있다면 그에 맞는 조합 로직을 외부에 배치하는 구조를 고려합니다.
관련 참고 자료
아래의 링크들은 유사한 주제를 다루는 질문과 답변을 포함하고 있습니다. 이러한 자료를 통해 여러 학습자의 관점을 비교하고 더 나은 이해를 돕는 데 도움될 것입니다.
위의 자료들이 질문자님의 구조적 고민에 도움이 되기를 바랍니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.