entity postfix 추가

[daehwan2da]

entity 와 service layer 의 object 를 구분하기 위함

• entity 를 service layer 에서 핸들링하지 않도록 하기 위함
  • repository 에서 읽어온 data 는 pure 하게 처리하기 위함
• service logic 에서는 entity 를 service object 로 치환해 로직상에서 사용하도록 구성
  • service layer 에서 활용되는 내부 DTO

주의

• repository layer 에서는 service layer 의 내부 dto 를 참조하지 않도록 한다.
  • AccountEntity 는 Account 를 몰라야한다.

example

• AccountEntity 는 Repository 에서 읽어온 그대로의 데이터, Account 는 Entity 를 바탕으로 서비스 로직상에서 핸들링되어질 내부 DTO
  • AccountEntity read 시
  • AccountEntity read -> AccountEntity to Account 치환 과정 -> Account 를 Service 에서 활용
  • AccountEntity write 시
  • Account 생성 -> Account To AccountEntity 치환 과정 -> AccountEntity save
  • AccountEntity update 시
  • AcccountEntity 그대로 update
  • AccountEntity delete 시
  • AccountEntity 그대로 delete

[daehwan2da]

@oownahcohc 님

해당 이슈 관련해서 질문 드릴게 있어서 언급했습니다. 저는 도메인을 pure 하게 가져가기 위해서는 도메인 엔티티가 영속성 엔티티를 몰라야 한다고 생각해서, StudioEntity 내부에 toStudio 메서드를 두어 매핑해주는 형태로 가져갔는데요, 어떻게 생각하시나요?!

repository Layer 가 가장 바닥 layer 일텐데요, 그렇게되면 layer 간 상호 의존되는 형태가 되지 않을까요?

• domain model 에서 entity 로 convert 하는 방향이 top-down 으로 파싱되는 방향이 될것같습니다

[oownahcohc]

@daehwan2da 님

위의 그림은 해당 글 에서 발췌한 것인데요, 의존성의 방향이 인프라스트럭처 레이어에서 도메인 레이어를 향하고 있습니다. 이런 관점에서 본다면 변환 로직을 인프라 계층에 두는 것이 좀 더 DDD 에 맞는 설계라고 생각했습니다.

도메인 엔티티 생성 시, 영속성 엔티티를 인자로 받아 getter 를 통해 접근하면 아무래도 영속성 엔티티의 내부 상태를 알게되고, 이때 의존성의 방향이 도메인 레이어 -> 영속성 레이어 가 된다고 생각했습니다. 그래서 위에 말씀 드린것과 같은 제안을 한 것인데요.

repository Layer 가 가장 바닥 layer 일텐데요, 그렇게되면 layer 간 상호 의존되는 형태가 되지 않을까요?

그런데 또 말씀 주신 부분도 완전 맞는 말씀이라고 생각이 듭니다. 제가 제안드린 방식을 생각해보면, 도메인 모델에 새로운 필드가 추가되면 인프라 계층의 변환 로직도 이에 맞추어 변경되어야 하는 등의 계층간 결합도가 발생할 것 같아서 이 방법도 이상적이라고 생각되지는 않는 것 같습니다.

그래서 그냥 UserRetriver 와 같은 구현 레이어에서 new User(Entity.getA(), Entity.getB()) 형식으로, 아예 서로 간 발생할 수 있는 의존성 자체를 끊어내는 방식을 생각해봤는데요, 이런 방식은 어떻게 생각하시나요?!

[daehwan2da]

좋은 의견인것같습니다~