1. 들어가기 앞서
Evolving Order(진화하는 질서)는 경직된 아키텍처의 문제점과 완전한 자유 속의 혼란 사이에서 균형을 잡으며, 도메인 모델의 복잡성을 관리하기 위한 대규모 구조(Large-Scale Structure)를 어떻게 점진적으로 발전시켜 나가야 하는지에 대한 통찰을 제공합니다.
1.1. 핵심 문제 인식
•
구조 없는 설계의 혼란
◦
많은 개발자들이 구조화되지 않은 설계로 인해 발생하는 비용(유지보수 어려움, 이해도 저하 등)을 경험합니다.
•
경직된 아키텍처의 폐해
◦
혼란을 피하고자 미리 엄격한 아키텍처(기술적이든, 도메인 주도적이든)를 부과하는 경우가 많습니다.
•
기술적 아키텍처의 한계
◦
네트워킹, 데이터 영속화 등 기술적 문제는 해결하지만, 도메인 모델 계층까지 침범하면 오히려 방해가 될 수 있습니다. 개발자가 특정 문제에 맞는 효과적인 설계를 하지 못하게 막거나, 심지어 개발자의 프로그래밍 능력 발휘를 저해할 수도 있습니다.
•
요구사항 변경의 어려움
◦
미리 정의된 아키텍처는 요구사항이 바뀌거나 도메인 이해도가 깊어짐에 따라 오히려 개발을 속박하는 족쇄가 될 수 있습니다.
•
기회비용 발생
◦
더 나은 설계 기회를 놓치거나, 아키텍처에 맞추기 위해 차선책을 택하거나, 아키텍트와 협상하느라 개발 속도가 느려집니다. 관리자는 아키텍처가 완성되었으니 문제없다고 생각할 수 있어 오해가 발생하기 쉽습니다.
2. Evolving Order(진화하는 질서)의 핵심 아이디어
문제는 규칙의 존재 유무가 아니라, 규칙의 엄격함과 그 규칙이 어디서 유래했는지입니다. 상황에 정말 잘 맞는 규칙은 개발을 방해하지 않고 오히려 도움을 주며 일관성을 제공합니다.
따라서, 도메인 계층의 대규모 구조(Large-Scale Structure)는 다음과 같은 특징을 가져야 합니다.
2.1. 애플리케이션과 함께 진화
•
처음부터 완벽한 구조를 만들기보다, 개발이 진행됨에 따라 애플리케이션과 함께 구조가 발전하고 변화할 수 있도록 해야 합니다. 심지어 완전히 다른 형태의 구조로 바뀔 수도 있습니다.
•
세부 설계 제약 최소화: 대규모 구조는 세부적인 도메인 지식을 바탕으로 내려야 할 구체적인 설계 및 모델링 결정을 과도하게 제약해서는 안 됩니다.
2.2. 전체와 부분의 균형
•
개별 부분(예: 특정 BOUNDED CONTEXT 내의 모델)에는 전체에 적용되지 않는 자연스럽고 유용한 구성 방식이 있을 수 있습니다. 전역적인 규칙을 너무 강하게 부과하면 개별 부분의 최적화를 해칠 수 있습니다.
•
대규모 구조를 사용한다는 것은 개별 부분의 최적화보다는 전체 모델의 관리 용이성에 더 무게를 두는 결정입니다. 따라서 약간의 타협(trade-off)이 필요합니다.
•
타협 최소화: 이 타협은 실제 도메인 경험과 지식을 바탕으로 구조를 신중하게 선택하고, 너무 속박하는 구조를 피함으로써 줄일 수 있습니다. 도메인과 요구사항에 잘 맞는 구조는 오히려 많은 대안을 빠르게 제거하여 세부 모델링을 더 쉽게 만들 수도 있습니다.
2.3. 일관성 및 관리 용이성 증진
•
대규모 구조는 개별 객체 수준에서 발견하기 어렵거나 시간이 오래 걸리고 일관성 없는 결과를 낳을 수 있는 설계 결정에 대한 가이드라인을 제공할 수 있습니다.
•
지속적인 리팩터링은 여전히 필요하지만, 대규모 구조는 이 과정을 더 관리하기 쉽게 만들고 여러 개발자가 일관된 해결책을 찾도록 돕습니다.
2.4. BOUNDED CONTEXT 간 적용 및 추상화
•
대규모 구조는 일반적으로 여러 BOUNDED CONTEXT에 걸쳐 적용될 필요가 있습니다.
•
개발 주기를 거치면서 구조는 특정 모델에 묶인 구체적인 특징을 잃고, 해당 도메인의 개념적인 윤곽(Conceptual Contours)에 부합하는 더 추상적인 특징을 발전시켜야 합니다.
•
이는 모델에 대한 가정을 전혀 하지 않는다는 의미는 아니지만, 특정 국소적 상황에 맞는 아이디어를 전체 프로젝트에 강요하지 않아야 함을 의미합니다.
•
각 CONTEXT 개발팀이 자신의 요구사항을 가장 잘 다룰 수 있도록 모델을 다양하게 구성할 자유를 부여해야 합니다.
2.5. 현실적인 제약 조건 수용
•
대규모 구조는 외부 시스템, 레거시 하위 시스템 등 통제할 수 없는 현실적인 제약 조건을 수용해야 합니다.
•
이를 위해 구조 자체를 외부 요소에 맞게 변경하거나, 외부와의 상호작용 방식을 명확히 정의하거나, 구조를 충분히 느슨하게 만들어 부자연스러운 현실에 대응할 수 있도록 해야 합니다.
3. 대규모 구조의 적용 원칙
•
선택 사항 (Optional)
◦
CONTEXT MAP과 달리 대규모 구조는 필수가 아닙니다.
•
비용-편익 분석
◦
구조를 도입함으로써 얻는 이점(명확성, 관리 용이성 등)이 비용(제약, 복잡성 증가 등)보다 클 때, 그리고 적합한 구조를 발견했을 때 적용해야 합니다.
•
단순하다면 불필요
◦
시스템이 MODULE 분해만으로 충분히 이해될 정도로 단순하다면 대규모 구조는 필요 없습니다.
•
명확성 vs. 부자연스러운 제약
◦
구조가 모델 개발에 부자연스러운 제약을 강제하지 않으면서 시스템을 굉장히 명확하게 만들 때 적용해야 합니다.
•
"적을수록 좋다 (Less is More)"
◦
맞지 않는 구조는 없는 것보다 못합니다. 포괄적인 구조를 추구하기보다, 당면한 문제를 해결하는 최소한의 구조 집합을 찾는 것이 가장 좋습니다.
•
예외 처리
◦
구조에 예외는 발생할 수 있으며, 이러한 예외는 쉽게 파악할 수 있어야 합니다. 개발자들은 별도 언급이 없으면 구조를 따라야 한다고 가정할 수 있어야 합니다. 예외가 너무 많아지면 구조를 변경하거나 폐기해야 합니다.
4. 결론 및 향후 논의
개발자에게 필요한 자유를 주면서 동시에 혼란을 방지하는 균형 잡힌 구조를 만드는 것은 어렵습니다. 기술적 아키텍처 분야는 많은 발전이 있었지만, 도메인 계층의 대규모 구조화는 아직 미개척 분야에 가깝습니다.
저자(에릭 에반스)는 다양한 프로젝트에서 관찰된 대규모 구조의 일반적인 패턴 4가지를 이어서 논의할 것이라고 언급합니다. 이 패턴들이 독자의 필요에 맞거나, 프로젝트에 맞는 구조를 고안하는 데 아이디어를 제공할 수 있기를 기대합니다.
요약하자면, Evolving Order(진화하는 질서)는 경직된 사전 설계의 함정을 피하고, 도메인의 복잡성을 효과적으로 관리하기 위해 대규모 구조를 점진적으로, 유연하게, 그리고 목적에 맞게 발전시켜 나가야 한다는 중요한 원칙을 제시합니다.