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

배유수

작성한 질문수

제미니의 개발실무 - 지속 성장 가능한 소프트웨어를 만들어가는 방법

Layer

비즈니스 계층 동일 레이어 서로 참조 금지와 관련하여

해결된 질문

작성

수정됨

통상의 Presentation - Business - Data Access에서 구현 계층이 추가됐고 구현 계층은 동일 레이어 간 상호 참조를 가능하게 한 부분이 있으니 비즈니스 계층은 상호 참조를 금지하는 것은 이해가 됐습니다.

기존에 제가 짜던 코드는 비즈니스 계층 + 구현 계층이었으니 비즈니스 계층을 나누는 기준이 기존 방식과 달라져야 그게 가능하겠다 까지는 생각이 들었고

기존에는 도메인으로 서비스를 만들었다면

비즈니스 흐름 별로 서비스를 만들어야 되겠다 라고 생각이 들었습니다.

어떻게 보면 서비스가 중복되고 세분화 된다고 볼 수도 있을거 같지만 단순 기능의 나열이 아니라 비즈니스와 일치하게 코드가 짜지겠다 생각이 드네요

여기까지 제가 말한 게 어떤지 하고 간단한 예시도 알려주시면 정리하는데 도움이 될 것 같습니다.

다른 강의도 잘 듣고 있습니다~ 감사합니다

아래 질문을 보고 추가한 내용입니다.

https://inf.run/QjDgU

리뷰와 포인트 서비스에 대한 예시였고

제 생각에는 비즈니스는 리뷰 작성이고

리뷰 작성에 따른 포인트 관리는 구현 단계에서 연결하면 되겠다 라고 생각이 들었습니다.

뭔가 더 생각해야 할 것들이 있을지 궁금하네요

소프트웨어-설계 business-logic layers modules

답변 2

제미니

지식공유자

안녕하세요 질문 감사드립니다

먼저 비즈니스 레이어 자체는 강의에서 설명한 기준 처럼 비즈니스 로직을 잘 나타내는 것을 기준으로하는게 좋다고 생각합니다.

그런데 이 부분에서 약간 생각을 포괄적으로 하시면 좋은게 이는 개념(도메인)에 대하여 로직을 작성하는 기준이 되어도 문제가 있지는 않습니다

일반적으로 개념이 갖고 있는 코어 로직 = 비즈니스 로직이 될 가능성이 높으니 딱 한가지로만 정하여 생각하지 않으셔도 괜찮을 것 같습니다!
예제 코드는 해당 강의에서 보여드리는 예제와 신규 강의 코드를 참고하시면 충분할 것 같습니다!

추가로 적어주신 부분은 구현 단계에서 연결하는 것이 항상 정답은 아닙니다!
(저 질문 답글에도 구현단계에서 연결하기보단 비즈니스 로직에서 잘 나타나게 하자는 의미였습니다)

ReviewService {
    addReview(..) { // 비즈니스 레이어
        reviewWriter.write(...)
        pointManager.add(...)
    }
}

리뷰 개념의 리뷰 작성이라는 비즈니스가 포인트라는 개념과 맞닿아 있기 때문에
ReviewService 에서 PointManager 를 아는 것은 타당하다고 볼 수 있는 것이죠

다른 방식으로는 (적어주신 느낌일듯 합니다)

ReviewService {
    addReview(..) { // 비즈니스 레이어
        reviewWriter.write(...)
    }
}

ReviewWrite {
    write(...) { // 도구 레이어
        pointManager.add(...)
    }
}

이 방식이라면 개념간 연결보다는 리뷰의 구현에 직접적으로 포인트 개념이 연결되어버리기 때문에 두 개의 개념이 상당히 가깝고 결합이 높다라고 정의한다면 타당하다고 볼 수 있을것 같습니다

이렇듯 결론적으로 비즈니스의 크기 개념간의 결합과 응집을 어떤식으로 구축 할 것인가를 고민하면 좋을 것 같습니다!

모쪼록 도움이 되길 바랍니다! 감사합니다!

인프런 AI 인턴

안녕하세요, 인프런 AI 인턴입니다. 배유수님.

질문해주신 내용을 자세히 살펴보면, 기존의 코드 스타일에서 새로운 비즈니스 계층을 분리하고 이에 따라 서비스의 구조가 변화해야 함을 고민하신 것으로 보입니다. 또한, 비즈니스 흐름을 기준으로 서비스를 정의하며 코드가 더 명확하고 비즈니스 로직에 부합하게 작성될 수 있음을 언급하셨습니다.

비즈니스 레이어와 구현 레이어의 분리

비즈니스 레이어의 역할: 주로 비즈니스 로직을 처리하며, 비즈니스의 흐름과 맞물린 서비스를 제공합니다. 여기서는 비즈니스 관련 규칙과 흐름을 명확히 반영할 수 있어야 합니다.
구현 레이어의 역할: 데이터 접근이나 외부 시스템과의 통신 등 비즈니스 로직과는 별개의 세부적인 구현을 처리합니다. 비즈니스 로직의 구현을 지원하며, 동일 레이어 간의 참조가 허용될 수 있습니다.

예시 적용

기존 코드가 도메인 중심으로 작성되어 있다면, 이를 비즈니스 흐름에 맞추어 코드의 구조를 재구성해보세요. 예를 들어, 사용자 관리는 사용자의 조회, 생성, 수정, 삭제와 같은 도메인별 서비스로 구성될 수 있지만, ‘사용자 등록 처리’와 같은 비즈니스 흐름에 초점을 두어 관련 작업을 하나의 서비스로 묶을 수 있습니다.

참고 URL

보다 심도 있는 논의를 위해서는 다음의 유사한 질문 및 답변을 참고하세요:
- 비즈니스 로직 재사용에 관한 접근
- Service 간 의존하는 경우

이 링크들은 서비스를 어떻게 구성하고 관리해야 하는지에 대한 실질적인 가이드를 제공할 것입니다.

저는 질문자님의 이해를 돕고자 지식공유자님과 관련된 기존 답변을 참고하여 유사한 답변 링크를 추천해 드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.

배유수

작성한 질문수

전체 Q&A

질문하기