05장_소프트웨어에서 표현되는 모델(Entity, VO, Service, Module)

• 여러 모델 요소 가운데 모델을 표현하는 세가지 패턴, 즉 Entity, Value Object(VO), Service를 구분하는 데 초점을 맞춰 설명하겠다 - p83
• 어떤 객체가 연속성(Continuity)과 식별성(Identity)을 지닌것을 의미하는가?
  아니면 다른 뭔가의 상태를 기술하는 속성에 불과한가?
  이것은 Entity와 VO를 구분하는 가장 기본적인 방법이다.
  ...
  Service는 Client요청에 대해 수행되는 뭔가를 의미한다.
  ...
  기술적인 측정 수단으로 여겨지는 높은 응집도(High Cohesion)와 낮은 결합도(Low Coupling)라는 개념은 도메인 개념에도 적용할 수 있다. MDD에서 Module은 모델의 한 부분이므로 도메인의 개념을 반영해야 한다 - p84

Entity (참조객체라고도 함) p91	- 수많은 객체는 본질적으로 해당 객체의 속성이 아닌 연속성과 식별성이 어이지느냐를   기준으로 정의됨 - (예) 사람은 출생에서 죽음까지, 그리고 죽은 다음에도 이어지는 식별성은 지닌다.   사람의 물리적인 속성은 변형되어 결국에는 사라진다. 사람의 이름은 바뀔수도 있다.   사람에게 변하지 않는 속성은 단 한 가지도 없지만 식별성은 여전히 지속된다. - 객체 모델링을 할 때 우리는 객체의 속성에 집중하고 하는데,   Entity의 근본적인 개념은 객체의 생명주기 내내 이어지는 추상적인 연속성이며,   그러한 추상적인 연속성은 여러 형태를 거쳐 전달된다는 것이다. - 어떤 객체를 일차적으로 해당 객체의 식별성으로 정의할 경우 그 객체를 Entity라 한다. - Entity는 자신의 생명주기 동안 형태와 내용이 바뀔수도 있지만 연속성은 유지해야한다. - Entity를 추적하려면 Entity에 식별성이 정의돼 있어야 한다. - 자바의 == 연산자와 같이 두 객체의 메모리 주소, 두 객체 참조가 같은 객체를 가리키고 있는지 판단. 이러한 점에서 보면 모든 객체 인스턴스는 식별성을 지녔다고 볼 수 있다. - (예) 지정석의 경우 입장권에는 좌석번호가 적혀 있을 것이므로 좌석은 Entity 다.   좌석의 식별자는 좌석번호이며 경기장내에서 유일하다.   빈좌석을 찾아 아무데나 앉을 수 있는 좌석이 고정되지 않은 일반석의 경우   좌석은 Entity가 아니며 식별자는 필요하지 않고 좌석의 갯만이 중요하다.
Value Object (값 객체) p99	- 개념적인 식별성을 갖지 않으면서 도메인의 서술적 측면을 나타내는 객체 - '주소'는 VO인가요? 누가 묻는 거죠? (상황에 따르 다르다) 예1) 주문의 속성으로 사용되는 주소는 VO 예2) 우편서비스의 계층구조 형태의 주소는 Entity 예3) 전기설비회사의 점검목적지인 경우 주소는 Entity, 거주지Entity의 속성인 주소는 VO - VO가 Entity를 참조할 수도 있다   지도서비스에서 두지점간의 경로 객체, 그 객체가 고속도로 등의 Entity를 참조한다해도 VO - 모델에 포함된 어떤 요소의 속성에만 관심이 있다면 그것을 VO로 분류하라 - VO를 구성하는 속성은 개념적 완전성   (Conceptual Whole, 워드 커닝햄의 WHOLE VALUE패턴)을 형성해야한다   예 p102 고객과 주소   도, 시군구, 읍면동, 우편번호와 같은 속성은 고객 객체에서 개별 속성이 되어서는 안되고   별도의 주소 객체로 만들고 연결   (이렇게 분리함으로 고객은 단순해지고 고객과 주소 각 객체는 응집력 있는 VO를 만듬)
Service p107	- 객체로는 모델에 어울리지 않는 것이 있다   도메인 기능을 Entity나 Value에서 억지로 맡게하면   모델에 기반을 둔 객체의 정의가 왜곡되거나, 또는 무의미하고   인위적으로 만들어진 객체가 추가될 것이다 - Service는 모델에서 독립적인 인터페이스로 제공되는 연산으로   Entity나 VO와 달리 상태를 캡슐화하지 않는다. - 다른 객체와의 관계를 강조 - Entity나 VO와 달리 순전히 Client에 무엇을 제공할 수 있느냐에 있다 - Service는 주로 활동으로 이름을 짓는다 - Service는 적절히 사용해야하고 Entity와 VO의 행위를 모두 가져와서는 안됨 - Serivce 3가지 특징  1) 연산이 원래부터 Entity나 VO의 일부를 구성하는 것이 아니라 도메인 개념과 관련  2) 인터페이스가 도메인 모델의 외적 요소의 측면에서 정의     (도메인 바깥으로 노출되는 성격)  3) 연산이 상태를 갖지 않음 - 도메인의 중대한 프로세스나 변환과정이 Entity나 VO의 고유한 책임이 아니라면   연산을 Service로 선언되는 독립 인터페이스로 모델에 추가 - 모델의 언어라는 측면에서 인터페이스를 정의하고   연산의 이름을 UL의 일부가 되게끔 구성 - Service와 Domain계층   Domain Service와 Application Service는 Infrastructure Service와 협업   Domain Service와 Application Service 구분이 어려울 수 있다   예) Banking Application Service 자금이체후 통지(Notification)까지의 책임   잔고확인 등의 실제 이체관련 업무는 계좌 Domain 객체의 책임   통지 Notification 은 Infrastructure 의 책임   기술과 관련된 Service에는 업무와 관련된 어떤 것도 포함돼서는 안됨 - 서비스를 여러 계층으로 분할하기 p111 Application 자금이체 응용 서비스   XML요청과 같은 입력 내용의 암호화   이체 처리를 위한 도메인 서비스로의 메세지 전송   이체 확인 대기   Infrastructure 서비스를 이용한 통지 결정   Domain 자금이체 도메인 서비스   금액 인출/입금에 필요한 계좌와 원장 객체간의 상호작용   이체 결과 확인 정보 제공(이체 수락 여부 등) Infrastructure 통지 서비스   Application에서 지정한 곳으로 이메일이나 우편 등을 보냄 - 서비스는 단순환 인터페이스 너머에 중요한 기능을 캡슐화하여 재사용 용이
Module(패키지라고도 함) p113	- (모듈 분리시 장점)   전체에 압도되지 않고도 모듈에 들어 있는 세부사항을 보거나   모듈에 들어있는 세부사항을 배제한 상태에서 모듈간의 관계를 볼 수 있음   (큰 덩어리를 모듈로 분리해서 개별 구현/테스트 및 전체 관계 파악 등 용이) - 모듈간에는 결합도가 낮아야 하고, 내부는 응집도가 높아야 함(두말하면 잔소리)   한번에 생각해 낼 수 있는 양에는 한꼐가 있으며(그래서 결합도를 낮춰야 하고)   일관성이 없는 단편적인 생각 등을 ... 섞어놓은 것처럼 이해하기 어렵다   (그래서 응집도는 높여야함) - 모듈로 쪼개기는 것은 코드가 아닌 개념 - UL를 구성하는 것으로 모듈의 이름을 부여하고   모듈과 모듈의 이름은 도메인에 통찰력을 줄 수 있어야 함