Albothyl 정리노트.

DDD를 공부하면서 느낀 점 객체지향 5원칙이 있다. DDD는 이 5원칙을 개념적으로 더 구체화시키는 설계 기법이라고 생각되었다. "어떻게 하면 더 객체지향스럽게 만들 수 있을까?", "어떻게 하면 좀 더 의사소통을 쉽게 할 수 있을까?", "어떻게 하면 유지보수의 비용을 줄일 수 있을까?" 등등.. 결국 DDD는 프로젝트를 객체지향답게 개발하는 방법이다. SRP(단일 책임 원칙) OCP(개방-폐쇄 원칙) LSP(리스코프 치환 원칙) DIP(의존 역전 원칙) ISP(인터페이스 분리 원칙) TDD에 관해서 부정적으로 생각했었던 부분이 바뀌었다. TDD에 대해서 부정적이 었던 이유는 TDD를 도입해야 한다고 말하는 사람들 중 왜 TDD가 실패하는지에 대해서 말해주는 사람이 없었다. 내가 생각하는 TDD의 실..

1. 상호작용 - 종합적인 계획은 전체주의적인 질서를 만들어 내기 때문에 너무 경직되어 불가피하게 일어나는 자연스럽고 예측 불가능한 변화에 유연하지 못하다. 때문에 Context, Distillation, 대규모 구조를 조합하여 상호작용을 이끌어 내야 한다. - 대규모 구조와 Bounded Context와의 결합 - 대규모 구조는 1 ~ N개의 Bounded Context에 영향을 주면서 Context Map을 구성할 수 있다. - Responsibility Layer는 N개의 Bounded Context에 적용될 수 있다. - 대규모 구조는 Core Domain안의 여러 관계와 Sub Domain 사이의 관계를 설명할 수 있다. 2. 평가 일관된 Context Map을 그릴 수 있는가? Ubiquito..

큰 시스템에서 해당 시스템의 요소를 전체 설계에 걸친 패턴에서의 "역할" 측면에서 해석하게 할 수 있는 지배적인 원칙이 없다면 개발자들은 나무만 보고 숲을 보지 못한다. 우리는 전체의 세부 사항을 깊이 파고들지 않고도 전체의 각 부분이 담당하는 역할을 이해할 수 있어야 한다. 때문에 전체 시스템을 포괄하고 각 부분의 책임을 자세히 알지 못해도 전체적인 관점에서 해당 부분의 위치를 어느 정도 이해하는데 도움을 주는 규칙이나 관계의 패턴을 고안해야 한다. Evolving Order : 발전하는 질서 프로젝트에서는 다양한 방법으로 개발을 제약하는 Architecture가 적용되는데 이런 Architecture가 Application과 Doamin까지 내려간다면 해당 아키텍처만의 문제가 발생할 수 있다. 개념적..

Distillation은 혼합된 요소를 분리해서 Domain Model의 본질을 좀 더 값지고 유용한 형태로 뽑아내는 과정이다. 이 과정은 가장 중요한 Domain Model에 초점을 맞춤으로써 시스템의 전체 설계를 파악과 리펙토링, 의사결정을 돕니다. Core Domain Business Domain을 대표하는 업무와 관련된 Model을 찾고 요약한다. 가장 가치 있고 전문화된 개념을 부각해야 한다. Core Domain을 찾는 일은 반복 주기를 거치면서 발전한다. Domain Vision Statement Application이 조직에 가져올 기본 개념과 가치를 전달하는 문서를 작성한다. Domain Model의 본질에 집중하여 짧게 작성한다. 팀 내에서 방향성을 공유하게 만들어준다. 팀의 의사소통 ..

많은 Model이 사용되는 코드는 버그가 발생할 확률이 높고, 이해하기 힘들다. 이런 문제점을 개선하기 위해서 Team, Application, Database 등의 기준으로 Context를 정의하고, 해당되는 Model을 정의한다. 이 Context를 Bounded Context라고 부르며 이 Context안의 Model은 일관된 상태로 유지하고, 다른 Context의 이슈 때문에 영향을 받아서는 안된다. ** Bounded Context는 Module이 아니다. -> Moudle도 일종의 경계를 제공할 수 있기 때문에 헷갈릴 수 있지만 둘은 서로 동기가 다른 패턴이다. Module은 단일 Model 내에 포함된 요소를 구성하는 데도 사용되며, 꼭 개별 Context에 의도를 전달하는 것은 아니다. C..

분석 패턴은 업무 모델링 과정에서 발견되는 공통적인 구조를 표현하는 개념의 집합이다. 분석 패턴은 단 하나의 도메인에 대해서만 적절할 수도 있고 여러 도메인에 걸쳐 적용이 가 능할 수도 있다. [Fowler 1997, p. 8] 예를 들면 Lamdba Architecture처럼 추상화되어 실제 프로젝트에 적용할 수 있는 아키텍처라고 이해하면 될 것 같다.

많은 Over-Engineering이 유연성이라는 명목으로 정당화되어 왔다. 그러나 과도한 추상 계층과 간접 계층이 존재하면 오히려 유연성에 방해가 된다. 또한 설계 요소가 Monolithic으로 구성돼 있을 경우 코드 중복이 발생할 가능성이 높고, 각 부분을 재결합하기가 힘들어진다. 재사용성을 높이고자 Class와 Method를 분리할 수는 있지만 분할된 작은 부분들이 무슨 일을 하는지 파악하기가 어려워진다. 소프트웨어가 깔끔하게 설계돼 있지 않다면 개발자들은 엉망진창으로 꼬여버린 코드를 보는 것조차 두려워하며, 혼란을 악화시키거나 예측하지 못한 의존성 탓에 뭔가를 망가트릴지도 모르는 변경을 덜 하게 될 것이다. 이런 취약성은 리팩터링과 반복적인 정제를 방해한다. Intention Revealing I..

1. Project Structure - 회사, 팀 등 개발 목적과 규모에 따라서 틀려진다. 때문에 무조건 DDD가 좋다고 할 수 없다. 2. DDD Detail (3-2 기준) 1. Interface - 사용자나 컴퓨터 시스템에게 정보를 보여주고 사용자의 명령을 해석하는 일을 책임진다. 2. Application - 소프트웨어가 수행할 작업을 정의하고 표현력 있는 도메인 객체가 문제를 해결하게 한다. 이 계층에서 책임지는 작업은 업무상 중요하거나 다른 시스템의 응용 계층과 상호작용하는 데 필요한 것들이다. 이 계층은 얇게 유지된다. 여기에는 업무 규칙이나 지식이 포함되지 않으며, 오직 작업을 조정하고 아래에 위치한 계층에 포함된 도메인 객체에게 작업을 위임 한다. 업무 상황을 반영하는 상태가 없지만, ..

Entity 식별성을 정의한다. 동일하다는 것이 무슨 의미인지 정의한다. 유일한 결과를 반환하는 연산을 정의한다. 속성으로 일치 여부를 판단하는 요구사항에 주의한다. 모델링과 설계상의 고려사항이 포함되어 있다. Class 정의, 책임, 속성, 연관관계는 특정 속성보다는 Entity의 정체성에 초점을 맞춰야 한다. 자주 변형되지 않거나, 복잡하지 않더라도 의미에 따라 Entity를 분류한다면 Model은 투명해지고 구현은 견고해질 수 있다. Value Object 식별성을 정의하지 않는다. 불변적(immutable)으로 다뤄야 한다. 불변성은 값의 의미에 있어서도 일관성을 지닌다. 불변성은 공유와 객체 참조 전달을 안전하게 만들어 구현을 상당히 단순하게 만들어준다. Model에 포함된 어떤 요소의 속성에만..

복잡한 Domain Logic을 좀 더 이해하기 쉽게 "AND", "OR", "NOT" 의 논리 연산으로 추상화 한다. 복잡한 Logic을 하나 하나 풀어 각각의 Specification으로 정의하고, 각 Specification을 위 "AND", "OR", "NOT" 논리연산으로 연결한다. public interface Specification { Specification and(Specification other); Specification or(Specification other); Specification not(); boolean isSatisfiedBy(Object candidate); } public abstract class AbstractSpecification implements Spe..