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

안녕하세요. 답변이 늦어 죄송합니다.

계속 다른 일을 진행하고 있어서 신경을 쓰지 못하고 있었습니다.

질문을 답변하기 앞서 문의 주신 내용 중에 “Presentation, Business, Domain, Persistence” 라고 말씀 주신 내용이 있기에 아차 싶었습니다. 혹시 강의 내용 중에 진짜 이렇게 표기한 자료가 있는 건가 싶어서 찾아봤는데, 보강인 헥사고날 PPT에 그렇게 적혀있더군요. 😭

이는 잘못된 표기입니다. 정확히는 “Presentation, Application, Domain, Persistence”라고 표현해야 하는 것이 맞습니다. 왜냐하면 Business 레이어와 Domain 레이어가 같이 표기되어선 안 되기 때문입니다.

도메인은 비즈니스(Businesss)가 해결하려는 문제 영역(Domain)입니다. 그렇기 때문에 엄밀히 말해 도메인은 비즈니스 레이어에 포함되는 개념입니다. 강의에서도 도메인 레이어를 새롭게 만든다고 표현했지만, 더 정확히는 비즈니스 레이어에서 도메인을 드러내도록 분리한 것이 맞습니다. 비즈니스 레이어라고 통칭해서 부르니 도메인이 눈에 안 들어오고 이로인해 다양한 오해가 생겼기 때문입니다.

그러므로 비즈니스 레이어 / 도메인 레이어를 하나의 도표에 같이 표기하는 것은 잘못된 설명입니다.

아무튼 그렇게 도메인 레이어를 분리하기로 결정했다면, 비즈니스 레이어에서 도메인이 사라지고 남은 레이어를 뭐라고 불러야할지 고민이 됩니다. 그래서 부르기로 한 명칭이 애플리케이션 레이어가 되는 겁니다. 애플리케이션 레이어에는 애플리케이션 구성하는 데 필요한 컴포넌트들이 모입니다. 예를 들어 애플리케이션 서비스 같은 스프링의 서비스 컴포넌트 같은 것들이 이곳으로 모입니다.

이는 Businsess layer = Application layer + Domain layer라고 봐도 된다는 의미이기도 합니다.

강의 자료를 만드는데 조금 더 신중을 기하겠습니다. 상기 내용은 지금부터라도 첨부 자료를 변경해 두고 어딘가에 보강 설명을 적어두기라도 해야겠네요. 감사합니다.

다시 질문의 내용으로 돌아와서

• @Entity가 붙은 Class는 Persistence에 두고 @Entity가 붙지 않은 Domain Class는 Domain에 둬서 클래스를 2개를 만드는 건가요?

강의의 의도는 질문해 주신 것이 맞습니다. 다만 아래 내용은 다릅니다.

• Service Class에서 Repository를 이용해서 MemberEntity를 가져온 다음에 MemberEntity를 MemberDomain으로 변환한 다음에 비즈니스 로직을 작성하면 되는 건가요?

교정하면 Service Class에서 Repository를 이용해서 Member를 가져옵니다. Repository는 MemberEntity를 Member로 변환한 도메인 모델을 반환해야 합니다. 서비스는 MemberEntity를 알지 못해야 합니다.

상세한 내용이 궁금하다면 아래 레포를 참고하심이 좋을 듯 합니다. 테스트에 관한 강의로 만든 hexagonal 예시입니다.

https://github.com/kok202/test-code-with-architecture/tree/test/practice-part-2

답변이 조금이라도 도움 되었길 바랍니다. 강의의 오류를 잡을 수 있게 해주셔서 감사합니다. :)

안녕하세요, 인프런 AI 인턴이에요.

도메인 객체의 구조에 대한 질문이시군요. 심폐소생술 PPT에 나와있는 Presentation, Business, Domain, Persistence는 일반적인 소프트웨어 아키텍처 패턴입니다.
일반적으로 @Entity 어노테이션이 붙는 클래스는 데이터베이스와 연관된 영속성(Persistence) 계층에서 사용되는 엔티티 클래스입니다. 이러한 클래스들은 데이터베이스의 테이블과 매핑되어 동작하며, 주로 데이터베이스로부터 데이터를 가져오거나 저장하기 위해 사용됩니다.

반면 @Entity 어노테이션이 없는 도메인 클래스는 비즈니스 영역에서 사용되는 클래스입니다. 이 클래스들은 비즈니스 로직을 포함하며, 엔티티 클래스와 상호작용하여 비즈니스 처리를 수행합니다. 엔티티 클래스와의 변환 작업도 가능합니다.

따라서, 보시는 것처럼 도메인 클래스와 엔티티 클래스를 나눠서 사용할 수 있습니다. 엔티티 클래스는 Persistence 패키지에 위치하고 @Entity 어노테이션을 사용하여 데이터베이스와 매핑되도록 설정합니다. 도메인 클래스는 Domain 패키지에 위치하며, 비즈니스 로직을 포함하고 엔티티 클래스와의 상호작용을 수행합니다.

Service 클래스에서 Repository를 사용하여 MemberEntity를 가져온 다음, 이를 MemberDomain으로 변환하여 비즈니스 로직을 작성하는 방법은 일반적으로 사용되는 방식입니다. Repository에서 데이터를 가져온 후, 비즈니스 로직을 수행하기 위해 도메인 클래스로 변환하는 것이 일반적인 구조입니다.

이렇게 도메인 객체를 구성함으로써 역할과 책임을 명확하게 분리하여 코드의 가독성과 유지보수성을 높일 수 있습니다.

간단한 예시를 들어 설명해드렸는데, 추가적으로 궁금한 점이 있으시다면 언제든지 물어보세요. 좋은 하루 보내세요!