DDD - 유연한 설계

Intention-revealing interface

개발자가 컴포넌트를 사용하기 위해 컴포넌트의 구현 세부사항을 고려해야 한다면 캡슐화의 가치가 사라진다. 도메인 내의 개념을 클래스나 메서드 형태로 명확하게 모델링하여 인터페이스로 전달해야 한다.

주의할 점은 수행 방법에 관해서는 언급하지 말고 오직 결과와 목적만을 표현하도록 클래스와 연산의 이름을 부여해야 한다. 

Side-effect-free function

CQRS가 중요하다. comand-query responsibility segregation. 즉 명령과 질의는 엄격하게 분리되어야 한다는 것을 의미한다. 다수의 규칙에 따라 상호작용하거나 여러가지 계산이 조합되면 극도로 예측하기가 힘들어진다. 이 의미는 연산을 호출하는 개발자가 연산 자체의 구현을 이해해야 한다는 것이다. 그러므로 우리는 안전하게 예측할 수 있는 추상화를 제공해야 한다. 

또한 우리는 기존의 객체를 변경하지 않고도 문제를 완화할 있도록 대안적인 모델과 설계를 해야 한다. 항상 결과값은 연산의 결과를 대표하는 새로운 VO를 생성해서 반환해야 한다. 생명주기를 신중하게 통제해야 하는 엔티티를 외부로 노출하지 말하야 한다. 

Assertion

단언을 사용하면 엔티티의 부수효과를 명확하고 다루기 쉬워진다. 

우리가 만약에 상위수준의 명령을 사용한다고 하면 그 명령이 호출하는 다른 명령의 부수효과까지 이해를 해야 하며 이렇게 하면 캡슐화가 무너진다. 이럴 경우 클라이언트가 해당 메소드를 이용할 수 있게 확실히 단언을 해줘야 한다. 단언에는 절차를 기술하지 않고 상태만 기술해서 분석을 용이하게 해야 한다. 

프로그래밍 언어에서 단언을 명시할 수 없다면 자동화된 단위테스트를 작성해서 단언의 내용을 표현하라. -> 밥 아저씨는 코드안에 너무 많은 단언을 넣지말라고 했다. 단언이 너무 복잡해서 내용의 이해를 흐릴수 있다고 했음.

Conceptual contour

모델 또는 설계를 구성하는 요소가 너무 집적되어 있으면 각 요소의 기능이 중복된다. 반면 클래스와 메서드를 너무 잘게 나누면 클라이언트 객체가 무의미하게 복잡해진다. 클라이언트가 작은 부분들의 협력 방식까지 모두 이해를 하고 있어야 하기 때문이다. 높은 응집도와 낮은 결합도는 개별 메서드부터 클래스, 모듈, 전체 구조까지 모든 규모의 설계에 중요하다. 도메인을 중요 영역을 직관을 감안해서 설계요소를 응집력 있는 단위로 분해하고, 계속적으로 리팩토링하라.

Standalone class

각 클래스간의 의존성이 증가할수록 설계를 파악하는데 어려움이 가파르게 올라간다. 이는 개발자에게 정신적 과부하를 줘서 개발자가 다룰수 있는 설계의 복잡도를 제한한다. 낮은 결합도는 객체 설계의 기본 원리다. 가능한 한 결합도를 늘 낮추고자 노력하라. 현재 상황과 무관한 모든 개념은 제거하라. 그러면 클래스가 완전 독립적으로 바뀌고 단독으로 검토하고 이해할 수 있다.

선언적 설계

선언적 설계의 배경에는 몇가지 동기가 있다. 선언적 설계는 대상에 따라 다양한 의미를 지닐 수 있지만 일종의 실행가능한 명세로서 프로그램 전체 혹은 일부를 작성하는 방식을 의미한다. 특성을 매우 정확하게 기술함으로써 소프트웨어를 제어하는 것이다. 선언적 설계를 하지 않을 경우 개발자들은 프레임워크의 한계에 갇힌 체 먼가를 인도하게 위해 설계에서 우선적으로 처리해야 할 문제를 위주로 프로세스를 재편하게 된다.

선언적인 형식을 취하는 흥미로운 접근법으로 도메인 특화 언어가 있다. 특정 모델에 맞게 조정된 프로그래밍 언어를 사용해 클라이언트 코드를 작성한다. 그러나 단점도 또한 지니고 있다. 모델을 개선하려면 개발자가 언어를 수정할 수 있어야 한다. 언어를 수정하려면 기반 클래스 라이브러리뿐 아니라 문법을 선언하는 방식과 언어를 번역할때의 특징까지도 변경해야 할지도 모른다.

다른 방법으로 제시하는 것이 SPECIFICATION을 선언적인 형식으로 확장하는 것이다. SPECIFICATION은 술어의 한 예이며, AND, OR, NOT 연산을 통해서 조합될 수 있다.