05 - 소프트웨어에서 표현되는 모델
ENTITY
어떤 객체를 일차적으로 해당 객체의 식별성(CI, 주민등록번호 등등...) 으로 정의할 경우 그 객체를 ENTITY 라고 한다.
ENTITY 는 자신의 생명주기 동안 형태와 내용이 급격하게 변경될 수 있지만, 연속성 은 유지해야 한다. (식별자를 통해 고유성이 유지된다는 의미)
ENTITY 는 속성보다는 식별성에 초점을 두어야 한다.
사람이나 도시, 자동차, 복권 티켓, 은행 거래와 같은 것들이 ENTITY 가 될 수 있다.
식별자로 동일성을 구별할 수 있다.
ENTITY 설계
객체를 모델링 할 때 속성에 관해 생각하는 것은 자연스러운 일이며, 특히 객체의 행위에 관해 생각해 보는 것은 매우 중요하다!
하지만 ENTITY 의 가장 중요한 포인트는 속성이나 행위에 집중하기보다는 식별성을 확립하는 것이다.
ENTITY 는 개념의 필수적인 행위만 추가하고 행위에 필요한 속성만을 추가한다.
VALUE OBJECT
ENTITY 의 식별성을 관리하는 일은 매우 중요하지만 그 밖의 객체에 식별성을 추가한다면 시스템의 성능이 저하되고 분석 작업이 별도로 필요하며, 모든 객체를 동일한 것으로 보이게 해서 모델이 혼란스러워 질 수 있다.
소프트웨어 설계는 복잡성과의 끊임없는 전투다. 그러므로 우리는 특별하게 다뤄야 할 부분과 그렇지 않은 부분을 구분해야 한다.
식별자를 가지지 않는 객체는 바로 객체를 서술하는 객체이다.
식별자를 가지지 않으면서 도메인의 서술적 측면을 나타내는 객체를 VALUE OBJECT 라고 부른다.
모델에 포함된 어떤 요소에 속성에만 관심이 있다면 그것을 VALUE OBJECT 로 분류하자. 또한 VALUE OBJECT 는 불변(immutable) 하게 관리하자. VALUE OBJECT 에는 아무런 식별성도 부여하지 말고 ENTITY 를 유지하는 데 필요한 설계상의 복잡성을 피하라.
값으로 동일성을 비교할 수 있다.
VALUE OBJECT 설계
VALUE OBJECT 는 식별성을 가지지 않기 때문에, 안전하게 공유할 수 있도록 설계하는 것이 중요하다.
이를 위해, 불변(immutable) 적으로 설계하는 것이 중요하다.
재사용과 캐싱에서 이점을 얻을 수 있다.
SERVICE
오늘날 흔히 하는 실수는 행위를 적절한 객체로 다듬는 것을 너무나도쉽게 포기해서 점점 절차적 프로그래밍에 빠지는 것이다. 하지만, 객체의 정의에 어울리지 않는 연산을 강제적으로 객체에 포함시킨다면 해당 객체는 자신의 개념적 명확성을 잃어버리고 이해하기 힘든 객체가 되어 버린다.
SERVICE 는 다른 객체와의 관계를 강조한다.
ENTITY 가 주로 명사, 동사로 이름 짓는것과 달리 SERVICE 는 주로 활동으로 이름을 짓는다.
SERVICE 는 무분별하게 사용되어서는 안되고, ENTITY, OBJECT VALUE 의 행위를 모두 가져와서는 안된다.
SERVICE 는 무상태로 설계해 확장성, 유지보수성 측면에서 유리하도록 설계해야 한다. (계층간의 경계를 분명하게 해야 한다)
SERVICE 와 격리된 도메인 계층
SERVICE 는 도메인계층에서 대부분 사용하고 있지만, 각각의 계층을 구분하여 분명한 책임을 나누는 것이 중요하다. (팀의 역량에 차이가 있을 수 있기 때문에, 초기라면 하나의 계층으로부터 시작하고 점진적으로 분리하는 것이 좋은 방법일 것 같다)
SERVICE 는 대부분 순수하게 기술적이며, 인프라스트럭처 계층에 속한다.
서비스를 여러 계층으로 분할한 예제는 다음과 같다. (관점에 따라서 계층의 구성은 달라질 수 있다)
어플리케이션(자금 이체 어플리케이션 서비스)
입력 내용의 암호화
이체 처리를 우히한 도메인 서비스로의 메시지 전송
이체 대기 확인
인프라스트럭처 서비스를 이용한 통지 결정
도메인(자금 이체 도메인 서비스)
금액 인출 / 입금에 필요한 Account(계좌), Ledger(원장) 객체 간의 상호 작용
이체 결과 확인 정보 제공(이체 수락 여부 등)
인프라스트럭처(통지 서비스)
애플리케이션에서 지정한 곳으로 이메일이나 우편 등을 보냄
Last updated