유연한 설계

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

---

 

• Intention Revealing Interface : 의도를 드러내는 인터페이스
  • 방법에 관해서는 언급하지 않고, 목적과 결과를 표현하는 이름을 부여한다.
  • 방법이 아닌 의도를 표현하는 추상적인 Interface 뒤로 모든 메커니즘을 캡슐화한다.
  • 의미를 추측할 수 있도록 Ubiquitous Language에 포함된 용어를 사용한다.
  • 개발자가 내부를 이해해야 할 필요성이 줄어든다.
• Side Effect Free Function : 의도하지 않은 부수 효과
  • 계산이 많거나 복합하면 Side Effect나 결과를 예측하기 힘들어지기 때문에 Interface 추상화로 얻을 수 있는 이점이 줄어든다.
  • 명령과 질의는 서로 다른 연산으로 분리하여 수행한다.
  • 변경을 발생시키는 Method는 단순하게 유지한다.
  • 명령과 질의를 분리하지 않는다면 Value Object를 Immutable로 관리한다.
  • 책임에 적합한 개념이 나타나면 복잡한 로직을 Value Object로 옮겨서 Side Effect를 통제한다.
• Assertion : 단언
  • 명확한 Input / Output을 명시한다.
  • 코드로 Assertion을 명시할 수 없다면, Unit Test로 표현한다.
• Conceptual Contour : 개념적 윤곽
  • 변경되는 부분과 그렇지 않은 부분을 식별한다.
  • Domain의 설계 요소(Interface, Class, Aggregate)를 응집력 있는 단위로 분해한다.
  • Ubiquitous Language를 사용하여 개념적으로 의미 있는 기능의 단위를 찾는다.
• Standalone Class
  • Dependency가 많아질수록 설계를 파악하기 힘들어진다.
  • 현재 상황과 무관한 개념을 제거하여 Module을 이해하는데 부담을 줄인다.
• Closure of Operation : 연산의 닫힘
  • "실수와 실수를 곱하면 항상 실수이다" -> "실수는 곱셈에 대해 닫혀있다" 라고 표현한다.
  • Input과 Output의 Type이 동일한 연산을 의미한다.
  • 연산의 닫힘은 다른 개념을 사용하지 않고도, 고수준의 Interface를 제공할 수 있다.
  • 연산의 닫힘은 읽고, 이해하고, 작성하기 쉽다.
• Specification
  • Domain Logic을 "AND", "OR", "NOT" 의 논리 연산으로 추상화하여 Specification으로 정의한다.
  • 각 Specification을 "AND", "OR", "NOT" 논리 연산으로 연결한다.