juniors-dev-study / domain-driven-design

1 stars 0 forks source link

5장 소프트웨어에서 표현되는 모델 #5

Closed y2o2u2n closed 3 years ago

y2o2u2n commented 3 years ago

엔티티 VS 값 객체

어떤 객체가 연속성 & 식별성 을 지녔다면 전자, 단순히 뭔가의 상태를 기술하는 속성에 불과하다면 후자

연관관계

연관 관계를 쉽게 다루려면 아래 3가지를 고려해라

현실 세계에서는 양방향으로 보이는 관계가 애플리케이션 요구사항에서는 그렇지 않을 수 있다. 요구사항에 없는 관계라면 제거하면 의존성이 줄고 설계가 단순해진다.

엔티티

자신의 생명주기 동안 형태와 내용이 바뀔 수도 있지만 연속성은 유지하며, 추적할 수 있게 식별성이 정의되어 있는 객체

값 객체

식별성이 없는 객체. 사물의 어떤 특징을 묘사함. 모델에 포함된 어떤 요소의 속성에만 관심 있다면 값 객체. 불변적으로 다루고 식별성을 부여하지 말아라. 값 객체에게 양방향 관계는 의미가 없다.

서비스

도메인의 개념 가운데 엔티티 또는 값 객체에 어울리지 않는 활동 또는 행동이 있을 때, 이를 무리하게 엔티티 또는 값 객체에 넣지 않고 서비스에서 사용한다.

잘 만들어진 서비스는 아래와 같다.

  1. 연산이 원래부터 엔티티나 값 객체의 일부를 구성하는 것이 아니라 도메인 개념과 관련이 있다.
  2. 인터페이스가 도메인 모델의 외적 요쇼의 측면에서 정의된다.
  3. 연산이 상태를 갖지 않는다.

서비스는 응용, 도메인, 인프라스트럭처 계층으로 나뉠 수 있다.

0 2

모듈

모듈 간 결합도가 낮아야 하고 모듈 내부는 응집도가 높아야 한다. 일련의 응집력 있는 개념들을 한 모듈에 담고 낮은 결합도가 달성되도록 노력해야 한다. 모듈의 이름은 보편 언어로 구성해라.


생각

chanhyeong commented 3 years ago

각자가 생각하는 이상적인 MODULE 구조? (조금 오래 걸릴 것 같아서 시간이 되면 보고 안되면 다음 시간)

하나의 개념적 객체를 구현하는 코드는 모두 같은 MODULE 에 두어야 한다

chanhyeong commented 3 years ago

SERVICE

(spring 의 @Service 도 여기서 가져옴)

도메인 개념 중 객체로는 모델에 어울리지 않는 것 SERVICE 는 layer 각각에 속할 수 있다

(4장에서의 개념을 같이 보면서) 각 layer 아래에는 기존 구현이 왜 이렇게 들어갔는지에 대한 의문

  1. application
    • controller 는 여기가 아닌가? 왜 infra 에 들어가있는지
  2. domain
    • commands, queries 는 여기가 아닌가? 왜 application 에 들어가 있는지
    • repository 도 interface 이긴 하고 실제 구현은 infra 긴 하지만, 애초에 infra 로 들어가야 하는거 아닌지
  3. infra
bearics commented 3 years ago

p111 응용 서비스, 도메인 서비스를 다른 package로 분리?

application-service
                   .a.service
                   .b.service

domain.
       account
                     .infra
                     .service
       person
                   .infra
                   .service

조금 다를 내용일 수도 있는데, 멀티모듈 예시 입니다. https://techblog.woowahan.com/2637/

youngvly commented 3 years ago