2부-모델-주도-설계의-기본-요소

p67

p70

• 사용자 인터페이스 = 표현 계층

  • 사용자에게 정보를 보여주고, 사용자의 명령을 해석

• 응용

  • 도메인 객체가 문제를 해결하게 한다

  • 다른 시스템의 응용 계층과 상호 작용

  • 업뮤 규칙이나 지식은 포함되지 않는다

• 도메인

  • 업무 개념, 업무 상황에 정보, 업무 규칙 포함

• 인프라스트럭처

  • 상태 저장과 관련 기술적인 세부사항

• 왜 분리?

  • 각 계층을 명료하게 설계할 수 있음.

p84 어떤 객체가 연속성(continuity)과 식별성(identity)을 지닌 것을 의미하는 가? 아니면 다른 뭔가의 상태를 기술하는 속성에 불가한다? 이것이 Entity와 Value Object를 구분하는 가장 기본적인 방법이다.

• 연속성, 식별성을 가졌으면 Entity

• 그게 아니면 Value Object

p85 현실세계에서는 수많은 다대다(many to many) 연관 관계가 있으며, 그 중 상당 수는 애초 부터 양방향(bidirectional) 으로 나타낸다. ... 애플리케이션 요구사항에서 두 방향을 모두 탐색할 필요가 없다면 탐색방향을 추가해서 상호 의존성을 줄여 설계를 단순하게 할 수 있다

• 양방향 보단 단방향이 낫다.

• 왜?

  • 복잡도가 올라간다

  • 하나의 객체 변화에 따라 다른 객체가 어떻게 변화된지 예측하기 어렵다.

• 탐색 방향을 제약하면, 도메인 관계를 파악하기 쉬워진다.

• 그리고 연관관계가 필요하거나 의미가 없다면, 제거하는게 나을지도

p93 어떤 객체를 일차적으로 해당 객체의 식별성으로 정의할 경우 그 객체를 Entity라 한다. .. Entity는 자신의 생명주기 동안 형태와 내용이 급격하게 바뀔 수도 있디만 연속성은 유지해야한다

• 은행 계좌는 Entity

• 은행 계좌 안에 담긴 돈은 Value Object

p101 모델에 포함된 어떤 요서의 속성에만 관심이 있다면 그것을 Value Object 로 분류하라.

• 식별이 아닌 속성에만 관심이 있다 -> 값 객체

p108 Service는 모델에서 독립적인 인터페이스를 제공하는 연산으로서 Entity나 Value Object 와는 달리 상태를 캡슐화 하지 않는다. ... 서비스라는 이름은 다른 객체와의 관계를 강조한다

• 도메인 서비스가 있고, 인프라 서비스도 있을 수 있는듯

• 인프라 서비스?

  • 은행에서 계좌 잔고가 일정 금액 아래로 떨어지만 고객에게 이메일을 발송하는 애플리케이션

    • 이때 이메일 시스템과 통지 수단을 캡슐화하는 인터페이스

p131 Aggregate 는 우리가 데이터 변경의 단위로 다루는 연관 객체 묶음을 말한다. 각 Aggregate에는 root 와 boundary 가 있다. 경계는 Aggregate에 무엇이 포함되고 포함되지 않는지를 정의한다. Root는 단 하나만 존재하면, Aggregate에 포함된 특정 Entity를 가르킨다.

- Car는 Aggregate의 Root - Customer는 Aggregate 밖의 Entity 이므로 root (Car)를 통해서만 조회할 수 있고 Tire 와 같은 객체는 참조할 수 없다 - 왜? - 시스템의 안정성을 위해 - 객체는 서로 참조할 수밖에 없는 데, 변경의 범위를 한정하지 않으면 의도치 않는 결과를 발생시킬 수 있다.

p142 복잡한 객체와 Aggregate의 인스턴스를 생성하는 책임을 별도의 객체로 옮겨라 .. 전체 Aggreate를 하나의 단위로 생성해서 그것의 불변식이 이행되게 하라

• Factory

  • factory method or abstract factory or builder

• Factory는 객체 생애 초기 단계를 다루는 반해, Repository는 중간단계와 마지막 단계를 관리하는데 도움을 주는듯

p163 Factory가 새로운 객체를 만들어 내는 데 반해, Repository는 기존 객체를 찾아낸다.

• 역할의 차이

• 내가 이해하고 있는 관계

참고

• https://product.kyobobook.co.kr/detail/S000001514402