"규칙 4. 동일 레이어 간 참조 금지" 관련 질문

Question

제미니 선생님, 안녕하세요. 이해가 잘 되도록 설명해주셔서 감사드립니다. 다름이 아니라 비즈니스 레이어에서도 동일 레이어 간 참조 금지 규칙이 적용되는 것으로 보입니다. 담당자들이 특정 업무 A, B, C를 진행할 때는 공통적으로 특정 업무 절차 D를 따라야 하는 상황을 생각해보았습니다. 가장 단순하게 구현하면 비즈니스 레이어에 A -> D, B -> D, C -> D의 의 존성이 생길 것 같은데, 이를 어떤 식으로 해결하면 좋을지와 그 이유가 궁금했습니다. 감사합니다!

제미니 · Answer

안녕하세요 질문 감사드립니다! 적어주신 예시가 명확하지는 않지만 예시를 기준으로 상상해보면 일단 요구사항과 비즈니스 본질 자체를 잘 이해해보면 좋을 것 같습니다! A -> D, B -> D, C -> D 의 패턴이라면 D는 언제나 자주 호출이 되어야하는 것인데 그러면 이게 비즈니스 적인 목적이 진짜 맞는 것인지 판단해볼 수 있을 것 같습니다 추가로 만약 명확하게 비즈니스 로직이 맞다면 그럼에도 구현상 D가 계속 호출해야하니 도구 레이어 쪽의 클래스로 내려서 처리하게 되면 (D를 도구화 시킨다면) 비즈니스 레이어의 동일 레이어 참조는 발생하지 않을 수 있습니다 이게 말장난 같은 부분이기도하지만 결국 개발 시에 어느 규칙을 지키기로 했다면 이런식으로 위상을 조절하여 규칙을 지킬 수 있을 것 같습니다! 모쪼록 답이 되었길 바랍니다! 감사합니다!

인프런 AI 인턴 · Answer

안녕하세요, 인프런 AI 인턴입니다. scorbiclife님. 동일 레이어 간 참조 금지라는 규칙은 소프트웨어 아키텍처에서 모듈 간 결합도를 낮추고 책임을 명확히 하여 유지 보수성을 높이기 위한 것입니다. 비즈니스 레이어에서도 이러한 규칙을 적용하는 것이 좋습니다. 만약 비즈니스 로직 중에서 재사용하고 싶은 업무 프로세스가 있다면, 다음과 같은 방법을 고려할 수 있습니다: 도메인 서비스 도입 : 개별 도메인 로직이 아니라 여러 도메인 객체를 조합하여 하나의 업무 프로세스를 구현해야 한다면, 이를 담을 도메인 서비스를 도입할 수 있습니다. 이 서비스는 비즈니스 로직을 담되 도메인 간의 결합도를 최소화하여 구현합니다. 유틸리티 클래스 사용 : 특정 로직이 여러 곳에서 반복해서 사용된다면, 유틸리티 클래스를 구현하여 해당 로직을 재사용하는 것도 고려할 수 있습니다. 다만, 유틸리티 클래스 사용 시 비즈니스 컨텍스트를 벗어난 일반적인 기능 제공에 중점을 둬야 합니다. 모듈화 전략 : 관련 비즈니스 로직들을 모듈화하여 패키지 또는 서브모듈 형태로 관리할 수 있습니다. 이렇게 하면 관련 기능을 한곳에서 관리하고 재사용성도 높일 수 있습니다. 관련해서 더 깊이 있는 논의는 아래의 유사한 질문과 답변에서 확인하실 수 있습니다: - 코드 구조와 재사용성에 관련된 질문 - 비즈니스 로직 재사용에 관한 접근 저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.