개발자와 도메인 전문가 소프트웨어 설계의 단계에서는 소프트웨어가 모델링할 실세계의 영역을 잘 알고 있는 '도메인 전문가'의 존재를 전제한다. 지식 탐구 설계의 전 단계에서 개발자와 도메인 전문가는 활발히 논의해야 한다. 개발자는 도메인 영역에 대해, 도메인 전문가는 기술적인 측면에 대해 서로가 모르거나 다르게 알고 있는 부분에 대해서 끊임없이 소통해야 하...
ubiquitous language (보편 언어) 1장에서 다루었듯이 도메인 전문가와 개발자 간, 혹은 개발자와 개발자 간의 지식 탐구는 매우 중요하다. 그리고 이 지식탐구를 통해 풍부한 지식을 설계에 담아내기 위해서는 다양한 상황에서 사용할 수 있는 팀의 '공유 언어'가 필요하다. 그리고 이 언어는 그 가치에 대한 활발한 실험이 필요하다. 도메인 전문가...
model driven design 코드는 그것의 기반이 되는 모델과 긴밀하게 연결되어 있어야 하며, 그러한 코드는 의미를 갖게 된다. 분석을 위한 모델과 설계를 위한 모델 지나치게 이론적이고 분석만을 위한 모델은 실제 설계에 적용하기에 부적합할 것이고 설계만을 위한 모델은 지식 탐구 과정에서 얻은 지식들을 온전히 반영하지 못할 가능성이 높다. 모델 주...
LAYERED ARCHITECTURE 우리는 시스템에서 도메인과 관련이 적은 기능으로부터 도메인 객체를 분리할 필요가 있다. 도메인의 격리는 도메인 지식을 그와 상관이 없는 기술적인 부분과 혼동하거나, 애플리케이션에서 도메인 지식이 흐려지는 것을 방지할 수 있다. 얼마 전 공부했던 클린 아키텍쳐 또한 layered architecture의 일종으로 볼 수...
도메인 모델을 표현하는 세 가지 패턴(entity, value object, service)에 대해 알아본다. ENTITY 객체를 '식별성'에 의해 정의하는 경우, 이러한 객체를 entity라고 부른다. entity에는 모델링과 설계상의 특수한 고려사항이 포함돼 있다. entity는 생명주기동안 형태와 내용이 급격하게 바뀔 수도 있지만 핵심은 '연속성'을...
도메인 객체를 관리하면서 신경써야 하는 문제는 크게 아래 2가지이다. 도메인 객체의 생명주기 동안 무결성 유지하기 생명주기 관리의 복잡성으로 모델이 난해해지는 것을 방지하기 1번 문제를 해결하기 위한 방법으로 Aggregate 패턴을 알아볼 것이고, 2번 문제를 해결하기 위한 방법으로는 Repository와 Factory 패턴에 대해 알아볼 것이다. ...
심층 모델이란 도메인의 피상적인 측면은 배제하고 도메인 전문가의 주요 관심사와 가장 적절한 지식을 알기 쉽게 표현하는 모델이다...
개발자들이 토의 중에 단서를 얻거나 설계상에 암시적으로 존재하는 개념을 인지하면 도메인 모델과 관련 코드를 대량으로 변환하게 되며, 그 후 하나 이상의 객체와 객체 간의 관계를 활용해 모델 내에 해당 개념을 명확하게 표현하게 된다.
소프트웨어는 1차적으로 사용자를 위한 것이지만, 다른 의미에서 개발자를 위한 것이기도 하다. 개발이 진행될수록 현재의 레거시 코드로 인한 중압감에 시달리지 않고 프로젝트 진행을 촉진하려면 변경을 수용하고 즐겁게 작업할 수 있는 설계가 필요하다. 이것이 바로 유연한 설계
지금껏 연구되어 왔던 수많은 디자인 패턴들은 기술적인 측면에 좀 더 초점을 맞춘다. 하지만 그 중 일부는 도메인에서 마주치는 의미 있는 개념에 사용할 수 있다. 이번 장에서는 개념적인 차원에서 도메인 주도 설계 과정에 적용할 수 있는 디자인 패턴을 소개한다.프로세스 모
도메인 모델은 단일화(unification)을 유지해야 한다. 단일화란 모델에서 사용하는 각 용어가 모호하지 않고 모순되는 규칙이 없는 일관성 있는 상태를 뜻한다. 모델의 단일화는 소프트웨어 개발 과정에서 여러 요인에 의해 흔들릴 수 있다. 대규모 시스템을 개발할 때는
디스틸레이션(distilation)은 혼합된 요소를 분리해서 본질을 좀더 값지고 유용한 형태로 뽑아내는 과정이다. distilation이라는 단어의 사전적 의미처럼 도메인 모델은 여러 번의 증류 과정을 거쳐 중요한 부분과 중요하지 않은 부분을 명확히 구분할 수 있게 된
큰 시스템에 해당 시스템의 요소를 전체 설계에 걸친 패턴에서의 역할 측면에서 해석하게 할 수 있는 지배적인 원칙이 없다면 개발자들은 나무만 보고 숲을 보지 못한다. 우리는 전체의 세부사항을 깊이 파고들지 않고도 전체의 각 부분이 담당하는 역할을 이해할 수 있어야 한다