Domain Driven Design/Eric Evance - 4. Isolating the Domain

객체 지향 프로그램에서 UI, 데이터베이스 및 기타 지원 코드는 종종 비즈니스 객체에 직접 작성됩니다. 추가 비즈니스 로직은 UI 위젯 및 데이터베이스 스크립트의 동작에 포함됩니다. 이것은 단기간에 작업을 수행하는 가장 쉬운 방법이기 때문에 발생하는 이슈 입니다. 

도메인 관련 코드가 이렇게 많은 양의 다른 코드를 통해 확산되면 보고 추론하기가 매우 어려워집니다. UI에 대한 피상적인 변경은 실제로 비즈니스 로직을 변경할 수 있습니다. 비즈니스 규칙을 변경하려면 UI 코드, 데이터베이스 코드 또는 기타 프로그램 요소에 대한 세심한 추적이 필요할 수 있습니다. 일관된 모델 기반 개체를 구현하는 것은 비실용적입니다. 자동화된 테스트는 어색합니다. 각 활동에 관련된 모든 기술과 논리로 인해 프로그램은 매우 단순하게 유지되어야 하며 그렇지 않으면 이해할 수 없게 됩니다.

 

 

복잡한 프로그램을 계층으로 분할합니다. 각 레이어 내에서 응집력 있고 아래 레이어에만 의존하는 디자인을 개발하십시오. 표준 아키텍처 패턴을 따라 위의 레이어에 느슨한 결합을 제공합니다. 도메인 모델과 관련된 모든 코드를 하나의 레이어에 집중하고 사용자 인터페이스, 애플리케이션 및 인프라 코드에서 분리합니다. 스스로를 디스플레이하고, 스스로를 저장하고, 응용 프로그램 작업을 관리하는 등의 책임으로 부터 자유로운 도메인 개체는 도메인 모델을 표현하는 데 집중할 수 있습니다. 이를 통해 모델은 필수 비즈니스 지식을 캡처하고 작동할 수 있을 만큼 충분히 풍부하고 명확해집니다.

Architecture Framework
최고의 아키텍처 프레임워크는 복잡한 기술 문제를 해결하는 동시에 도메인 개발자가 집중할 수 있도록 합니다. 그러나 프레임워크는 도메인 디자인 선택을 제한하는 너무 많은 가정을 하거나 구현이 너무 무거워 개발 속도를 늦추는 방식으로 쉽게 방해가 될 수 있습니다. 

LAYERED ARCHITECTURE는 오늘날 대부분의 시스템에서 다양한 계층화 방식으로 사용됩니다. 많은 개발 스타일도 레이어링의 이점을 얻을 수 있습니다. 그러나 도메인 기반 설계는 하나의 특정 레이어만 있으면 됩니다. MODEL-DRIVEN DESIGN에서 도메인 계층의 소프트웨어 구성은 모델 개념을 반영합니다. 도메인 논리가 프로그램의 다른 관심사와 혼합될 때 해당 대응을 달성하는 것은 실용적이지 않습니다. 도메인 구현을 격리하는 것은 도메인 주도 설계의 전제 조건입니다.

Userinterface와 Model이 결합된경우(이 책에서는 Anti Pattern이라고 Model Driven이 적용이 안되는 패턴을 뜻함)
장점 
• 생산성이 높고 간단한 응용 분야에서 즉각적입니다. 
• 능력이 부족한 개발자는 약간의 교육만으로도 이러한 방식으로 작업할 수 있습니다. 
• 요구 사항 분석의 결함도 사용자에게 프로토타입을 출시한 다음 요청에 맞게 제품을 신속하게 변경하여 극복할 수 있습니다. 
• 응용 프로그램이 서로 분리되어 있으므로 작은 모듈의 배송 일정을 비교적 정확하게 계획할 수 있습니다. 추가의 간단한 동작으로 시스템을 확장하는 것은 쉽습니다. 
• 관계형 데이터베이스는 잘 작동하며 데이터 수준에서 통합을 제공합니다. 
• 4GL 도구는 잘 작동합니다. 
• 응용 프로그램이 전달되면 유지 관리 프로그래머는 파악하지 못한 부분을 빠르게 다시 실행할 수 있습니다. 변경 효과가 각 특정 UI에 국한되어야 하기 때문입니다. 

단점 
• 데이터베이스를 통하지 않고는 응용프로그램의 통합이 어렵다. 
• 행동의 재사용과 비즈니스 문제의 추상화가 없습니다. 비즈니스 규칙은 적용되는 각 작업에서 복제되어야 합니다. 
• 추상화의 부족으로 인해 리팩토링 옵션이 제한되기 때문에 신속한 프로토타이핑 및 반복 작업은 자연스러운 한계에 도달합니다. 
• 복잡성은 당신을 빨리 묻히기 때문에 성장 경로는 엄격하게 단순한 추가 애플리케이션으로 향합니다. 더 풍요로운 행동으로 가는 우아한 길은 없습니다.