어지러운 현실에도 불구하고, 소프트웨어 구현을 명확하게 유지하고, 모델에 발맞추는 것은 모델링과 설계에 있어서 모범 사례(best practice)를 적용해야만 한다.

Domain-driven design은 어떤 전통적인 아이디어에서 강조하는 바를 바꾼다.

비록, 그 중요도가 크기와 균형이 맞지 않더라도, 특히 도메인에서 문제를 해결하는 소프트웨어의 일부분은 일반적으로 단지 전체 소프트웨어 시스템의 작은 부분으로 여겨진다.

Object-Oriented Program에서 UI, Database, 다른 Code는 종종 Business Object에 직접적으로 쓰여 진다. 추가적인 Business Logic은 UI Widget이나 Data기반 스크립트에 동작하도록 포함된다(embedded). 단기적으로 동작하도록 하는 가장 쉬운 방법이기 때문에 이런 경우가 발생하게 된다.

Domain과 연관된 Code는 많은 양의 다른 Code를 통해서 확산되고, 극도로 그것을 보거나 추론하기가 어렵게 된다. UI를 피상적으로 변경하는 것은 실제로 Business Logic을 변경하는 것이다. Business Rule을 변경하기 위해서는 UI Code, Database Code, 혹은 다른 프로그램 요소들을 세밀하게 추적해야 한다. 일관성있게 Model-Driven Object를 구현하는 것은 비현실적이다. 자동화된 테스트는 어색하다. 개별 Activity에 포함된 모든 기술과 로직으로 인해 프로그램은 매우 단순하게 유지되어야 하고, 그렇지 않은 경우 이해하는 것이 불가능하다.

소프트웨어 시스템을 여러 가지 방법으로 나눌 수 있다. 그러나 경험과 협약으로 인해 산업계에서는 Layered Architecture로 수렴하고 있다. 대부분의 개발자들이 이해하기 쉽기 때문이다.

필수적인 원칙은 레이어의 모든 요소는 동일한 레이어의 다른 요소나 "아래에 있는" 레이어 요소에만 의존한다는 것이다.

위로 향하는 커뮤니케이션은 나중에 간략하게 설명할 간접적인 메커니즘을 통과해야 한다.

레이어의 가치는 각각의 레이어가 컴퓨터 프로그램의 특별한 측면을 다룬다는 것이다.

물론, 가장 중요한 응집력있는 설계 측면을 격리하는 레이어를 선택하는 것이 중요하다.

복잡한 프로그램을 레이어로 나눈다. 응집력 있고, 아래에 있는 레이어에만 의존하는 각 레이어를 디자인하고 개발한다. 표준 아키텍처 패턴을 따라 위에 있는 레이어와 느슨한 결합을 제공하고, 하나의 레이어에서 도메인 모델과 관련된 모든 코드를 집중화하고, User Interface, Application, Infrastructure Code와 격리한다. 도메인 객체는 자체를 표시하고, 저장하고, Application Task를 관리하는 등등의 책임이 없고, 도메인 모델을 표현하는 것에만 집중할 수 있다. 이를 통해 모델은 필수적인 비즈니스 지식을 포작하고, 동작하도록 풍부하고 명확하게 진화할 수 있다.

도메인 레이어를 Infrastructure와 User Interface로부터 분리하는 것은 각 레이어를 명확하게 설계할 수 있게 한다. 격리된 레이어는 각 레이어별로 다른 요구사항과 비율로 진화할 수 있기 때문에 유지보수에 덜 비싸다. 또한, 이러한 분리는 커뮤니케이션 Overhead를 최소화하고, 성능을 개선하기 위해서 다른 레이어에 다른 서버나 클라이언트를 유연하게 위치시킬 수 있기 때문에 분산 시스템에서 배포에 도움이 된다.

레이어는 한 방향에 대한 의존성을 가지도록 느슨하게 연결되어야 한다. 위에 있는 레이어는 Public Interface를 단도직입적으로 호출하여 (최소한 일시적으로) 참조를 가지고 아래에 있는 레이어 요소를 사용하거나 다룰 수 있고, 일반적으로 전통적인 상호작용의 수단을 사용할 수 있다.

하지만, 하위에 있는 Object는 (쿼리에 대한 직접적인 응답으로) 위와 커뮤니케이션할 때 콜백이나 Observer와 같은 연결된 레이어에 댛나 아키텍처 패턴을 그리는 다른 메커니즘이 필요하다.

UI와 어플리케이션, 도메인 레이어를 연결하는 할아버지격 패턴은 MVC(Model-View-Controller) 패턴이다.

많은 Infrastructure의 요구사항을 통합하는 Framework는 종종 Framework 클래스의 하위 클래스나 구조화된 메소드 시그니처(method signature)와 같은 매우 특별한 방식으로 다른 레이어들을 구현해야 할 필요가 있다.

최고의 Architectural Framework는 복잡한 기술 문제를 해결하는 동시에 도메인 개발자는 모델을 표현하는데 집중할 수 있다.

하지만, Framework는 도메인 설계 선택을 제한하는 너무 많은 가정을 만들거나 구현이 너무 무거워서 개발이 느려지게 함으로써 쉽게 방해가 될 수 있다.

일반적으로는 Architectural Framework의 일부가 필요하다. (때때로 팀에서는 잘 제공하지 않는 Framework를 선택한다.)

Framework를 적용할 때, 팀은 도메인 모델을 표현하고 중요한 문제들을 해결하는데 사용하는 구현을 작성하는 것과 같은 목표에 중점을 두어야 한다.

팀은 비록 Framework의 모든 기능을 사용하지는 않더라도 그러한 목적에 Framework를 사용할 방법을 찾아야만 한다.

예를 들면, 초기 J2EE 어플리케이션은 종종 "Entity Bean"으로 모든 도메인 객체를 구현했다.

이러한 접근 방식은 성능과 개발 속도를 모두 저하시켰다.

대신에, 현재의 가장 좋은 사례(best practice)는 더 큰 grain object에 J2EE Framework를 사용하고, 일반적인(generic) Java Object로 대부분의 비즈니스 로직을 구현하는 것이다.

Framework의 많은 단점은 두루두루 적용되는 솔루션을 찾지 않고도 어려운 문제를 해결하기 위해서 선택적으로 적용함으로써 피할 수 있다.

Framework의 가장 가치있는 기능을 의도적으로 적용하면, 구현과 Framework의 결합이 감소하고, 이후 설계 의사결정에 유연성을 부여할 수 있다.

더 중요한 것은, 현재 많이 사용하는 Framework가 얼마나 복잡한지를 고려하면, 이러한 미니멀리즘(최소한의 표현주의)은 비즈니스 객체를 읽고 표현력 있게 유지하는데 도움이 된다.

Architectural Framework와 다른 도구들은 계속 발전할 것이다.

더 새로운 Framework는 어플리케이션의 기술적 측면을 점점 더 많이 자동화하거나 사전에 미리 만들것이다.

만약 이것이 올바르게 완료되면, 어플리케이션 개발자는 핵심 비즈니스 문제를 모델링하는데 시간을 집중하고, 생산성과 품질을 크게 향상시킬 것이다.

하지만, 우리가 이런 방향으로 나아갈 때, 기술적인 솔루션에 대한 열정을 경계해야 한다. 정교한 Framework는 또한 어플리케이션 개발자들을 구속할 수도 있다.

Layered Architecture는 다양한 레이어링 스키마 하에서 오늘날 대부분의 시스템에서 사용되고 있다. 또한, 많은 개발 스타일이 레이어링을 통해서 유익함을 얻을 수 있다.

하지만, Domain-Driven Design에서는 하나의 특정한 레이어만 존재하면 된다.

Domain Model은 개념들의 집합이다. "Domain Layer"는 모델과 직접적으로 관련되어 있는 모든 설계 요소들의 표현이다.

설계와 비즈니스 로직의 구현은 Domain Layer를 구성하고 있다. MODEL-DRIVEN DESIGN에서 Domain Layer를 구성하고 있는 소프트웨어는 모델 개념을 반영하고 있다.

도메인 로직이 프로그램의 다른 관심사와 섞여 있을 때, 연관성을 달성하는 것은 실용적이지 않다. 도메인 구현을 격리하는 것은 Domain-Driven Design에서 전제 조건이다.

만약 단순한 프로젝트를 수행하는 정교하지 않은 팀에서 Layered Architecture로 Model-Driven Design을 시도하기로 결정하면, 어려운 학습 곡선(learning curve)에 직면하게 될 것이다.

팀 구성원들은 복잡한 새로운 기술을 숙달해야 하고, 객체 모델링 학습 프로세스로 휘청거려야 한다. (이 책의 도움을 받더라도 도전적이다.)

Infrastructure와 Layer 관리의 오버헤드로 인해 매우 단순한 작업이 더 오래 걸린다.

간단한 프로젝트에는 짧은 시간대와 겸손한 기대가 있다. 팀에 배정된 과제를 완료하기 전에 접근 방식의 흥미로운 가능성을 훨씬 덜 설명하기 때문에 프로젝트는 취소될 것이다.

심지어 팀에 더 많은 시간이 주어지더라도, 팀 구성원들은 전문가의 도움없이 기술을 마스터하는 것에 실패할 것이다.

그리고 결국, 이러한 도전을 극복한다면, 간단한 시스템을 만들어낼 것이다.

풍부한 기능은 결코 평가조차 받지 못했다.

Domain-Driven Design은 야심찬 프로젝트에 가장 적합하고, 강력한 skill을 필요로 한다. 모든 프로젝트가 야심차지도 않고, 모든 프로젝트 팀이 그러한 skill을 발휘하지도 않는다.

따라서, 모든 비즈니스 로직을 User Interface에 배치한다.

어플리케이션을 작은 기능으로 잘라서 비즈니스 규칙을 해당 기능에 포함시켜 별도의 User Interface로 구현한다.

관계형 데이터베이스를 데이터 공유 저장소로 사용한다.

자동화된 UI 빌드 및 이용 가능한 시각화 프로그래밍 도구를 사용하라.