인프런 커뮤니티 질문&답변
작성한 질문수
객체지향 설계 관련하여 궁금한것이 있습니다.
해결된 질문
작성
·
120
1
안녕하세요.
우선 저는 제 자신이 자바로 개발을 진행하고 있지만, 객체지향을 완전히 알고있는지에 대해 의문을 가진채
해당 강의를 접하게 되었고, 많은 생각과 깨달음을 얻고 있습니다. 감사합니다.
그리고 궁금한것이 있어 글을 쓰게 되었습니다. (사실 완강을 하지 않은 상태이긴합니다 ㅠ)
개발 설계 방식이야 다양할것이라 생각이 드는데, 보통 스프링 기준으로..프레임워크 내에서 패키지 설계를 진행할때
단순 관리 기능 개발 기준으로 보면, 레이어드 아키텍처와 유사한 방식으로 설계를 많이 진행하지 않을까라는 생각이 조심스럽게 듭니다. (물론 아닐수도 있습니다 ㅠㅠ)
그리고 보통은 절차지향으로 생각하여 ERD 설계후 이를 스프링 프로젝트 내에 레이어드 아키텍처를 설계하여 (대충 controller-service-repository(JPA 사용시))
작업을 진행할것이라 생각이 듭니다.
그리고 service 에는 필요한 repository 들을 왕창 주입받는 형태로 설계될것이라 생각이 듭니다.
저는 여기서 궁금한것이 이러한 상황(레이어드 아키텍처)에서 강의의 오브젝트 개념을 녹이고 싶다면
패키지 구조를 어떻게 정의하는것이 마땅할지 문득 궁금해졌습니다.
예를들면 entity 패키지와는 별개의 다른 domain 패키지(책임을 일부 갖는 역할)를 만들어
service 패키지에서 해당 domain 패키지(책임을 일부 갖는 역할)를 주입받아 사용하는 방식으로 설계를 해야하는지 등이 궁금합니다.
질문을 작성하면서도 정답이 없으려나 싶기도 합니다.
무튼 감사합니다. 완강하겠습니다!!
답변 2
1
모아무개님 안녕하세요.
좋은 질문 해주셔서 감사합니다.
강의의 앞부분에서 는 도메인에 포함되는 개념과 관계를 코드로 옮기는 방법을 중심으로 객체지향 설계 방법을 설명하고 있습니다.
이렇게 구현된 클래스들은 레이어 아키텍처에서 일반적으로 이야기하는 도메인 레이어에 위치하게 되며 자바에서는 패키지를 이용해서 레이어를 구분하게 됩니다.
이 패키지의 이름은 말씀하신 것처럼 domain으로 짓는 것이 일반적입니다.
하지만 애플레케이션이 실제로 동작하기 위해서는 도메인 객체만으로는 충분하지 않습니다.
도메인과 무관한 객체들도 필요한데 Spring을 사용하는 환경에서 이 객체들은 아래 인프런 AI 인턴이 설명하는 것처럼 repository, service, controller와 같은 이름이 붙은 패키지 아래 배치가 될것입니다.
이 부분에 대해선 "5-4. 애플리케이션 객체 추가하기"에서 좀 더 자세히 설명하고 있습니다.
강의를 들으시는 분들 중에 JPA를 모르시는 분들도 계시기 때문에 강의에서는 JPA 대신 Spring의 JdbcClient를 기반으로 네이티브 쿼리를 사용하고, 퍼시스턴스 메커니즘을 담당하는 객체의 이름에 repository 대신 dao라는 이름을 붙이고 있지만 JPA를 사용하더라도 기본적인 구조는 동일하게 가져갈 수 있습니다.
이론적인 부분에 대해서는 "5-4. 애플리케이션 객체 추가하기"를 참고해 주시고, 코드의 예는 "5-4-예제. 애플리케이션 객체 추가하기" 강좌를 참고해 주시면 감사하겠습니다.
보시고 궁금한 부분이 있으면 다시 문의해 주시면 답변 드리도록 하겠습니다.
남은 강의도 재미있게 보시고 꼭 완강하시길 바랄게요. 🙂
1
안녕하세요, 인프런 AI 인턴입니다.
모아무개님, 객체지향 설계에 대한 질문에 대해 고민하시고 강의를 통해 많은 깨달음을 얻고 계신다니 반갑습니다.
객체지향에서 레이어드 아키텍처를 사용하는 경우 패키지 구조에 대해 고민하시는 점은 매우 중요합니다. 그럼 어떻게 객체지향 개념을 레이어드 아키텍처에 효과적으로 녹일 수 있을지 설명드리겠습니다.
우선, 객체지향에서는 시스템을 여러 레이어로 나누어 역할과 책임을 명확히 하는 것이 중요합니다. 레이어드 아키텍처의 경우 기본적으로 Controller, Service, Repository 등의 레이어로 나뉘는데, 각 레이어가 자신의 책임을 명확히 가질 수 있도록 설계하는 것이 핵심입니다.
도메인 패키지의 역할: 도메인 패키지는 비즈니스 로직과 관련된 중요한 모델과 로직을 담고 있는 곳입니다. 따라서, 비즈니스 로직을 서비스 레이어에 집중시키는 대신, 도메인 모델(Entities)이 정확한 책임과 역할을 가지도록 해야 합니다. 이를 통해 도메인 모델과 관련된 복잡한 비즈니스 로직이 도메인 객체 내에서 다뤄질 수 있습니다.
패키지 구조의 정의: 도메인 중심의 설계를 위해 패키지를 구분하는 것은 이해관계자들이 시스템 구조를 쉽게 이해하게 도울 수 있습니다. 예를 들어,
domain패키지는 핵심 비즈니스 로직을,repository는 데이터 접근을, 그리고service패키지는 애플리케이션 비즈니스 로직 조율을 담당합니다.서비스 패키지에서는 도메인 객체의 활용: 서비스 레이어는 여러 도메인 객체를 이용해 작업을 조율합니다. 여기서 주의할 점은 서비스 레이어가 지나치게 비대해지지 않도록 하고, 도메인 객체에 로직을 넘겨주는 것입니다.
의존성 관리: 의존성 역전을 통해 서비스 레이어가 구체적인 구현에 의존하지 않도록 하고, 인터페이스와 추상화를 이용해 모듈 간의 결합도를 낮춰야 합니다.
아래 질문의 답변과 포스트가 비슷한 맥락을 다루고 있으니 참고하시면 도움이 될 것 같습니다.
- DAO 관련 질문드립니다
- 실제로 객체지향으로 설계를 많이 하는지 궁금합니다.
위 질문과 답변은 아키텍처와 설계 패턴에 대한 더 깊은 이해를 돕고, 다양한 방법론에 대해 소개하므로 도움이 될 것입니다.
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.
관련 강의를 학습하고 왔습니다. 🙂
단순 레이어드 아키텍처 기준 (컨트롤러 - 서비스 - 퍼시스턴스) 구조가 아닌 서비스와 퍼시스턴스 사이의 도메인 패키지가 추가됨을 알았고, 이에 대해 설명을 주신 내용이라는것을 알게 되었습니다.
서비스 관련 클래스에는 클라이언트 호출 기준의 정보를 (도메인의 정보 조합에 대한 결과)를 갖게되고
도메인 패키지 내의 관련 클래스들이 해당 강의에서 말씀주신 내용들(각 책임을 가진 도메인들의 클래스)을 포함하는것을 알게되었습니다.
감사합니다! 😄