[keyword] 12-13장 모델과 디자인 패턴의 연결 및 더 심층적인 통찰력을 향한 리팩터링

emiling commented 1 year ago

주제

'12장 모델과 디자인 패턴의 연결'과 '13장 더 심층적인 통찰력을 향한 리팩터링' 을 읽고 내용을 요약하거나,
중요✨ 하다고 생각하는 키워드 및 관련 설명을 코멘트로 달아주세요

연관 챕터

https://github.com/caffeine-library/Domain-Driven-Design/issues/53

emiling commented 1 year ago

12. 모델과 디자인 패턴의 연결

일부 디자인 패턴의 경우 도메인에서 접하게 되는 일반적인 개념과도 부합하기 때문에 도메인 설계시에도 활용 가능
도메인 주도 설계에서 디자인 패턴을 활용하기 위해선 아래 두 가지 관점에서 패턴을 바라봐야 한다
- 코드 내에 포함된 기술적인 측면을 다루는 디자인 패턴
- 모델 내에 포함된 개념 패턴

STRATEGY

알고리즘군을 정의하고 각 알고리즘을 캡슐화하여 알고리즘들을 상호교환하게끔 만든다. (Gamma et al.1995)

디자인 패턴 관점 : 각기 다른 알고리즘 간에 상호 대체할 수 있는 능력에 중점
도메인 패턴 관점 : 프로세스 또는 정책적인 규칙과 같은 하나의 개념을 표현하는 능력에 중점
- 프로세스의 중심 개념(프로세스의 규칙)과 변경되는 부분(프로세스를 제어하는 행위)을 분리

COMPOSITE

부분과 전체의 계층을 표현하기 위해 객체들을 모아 트리 구조로 구성한다. 사용자로 하여금 개별 객체와 복합 객체를 모두 동일하게 다룰 수 있도록 한다. (Gamma et al.1995)

중첩된 복합 객체간의 관련성을 모델에 반영하지 않는 경우 계층구조상의 각 수준에 공통적인 행위를 중복시킬 수 밖에 없고, 중첩에 대한 유연성이 손실된다
도메인 패턴 관점에서 사용할 때 정말 적합한지 생각해봐야 함
- 도메인 개념 간의 부분/전체 계층 구조가 존재하는가?
- 하부의 모든 부분이 실제로 동일한 유형의 개념으로 구성되는 추상화를 발견했는가...

emiling commented 1 year ago

13. 더 심층적인 통찰력을 향한 리팩터링

앞 장들의 내용 요약한 챕터이므로 기억에 남는 문장 위주로 정리

도입

리팩터링 수행 전 아래 세 가지 핵심 사항을 통합해보는 것이 도움이 된다.

활동의 근거지를 도메인으로 삼는다

현상과 사물을 다른 방식으로 바라보도록 한다.

도메인 전문가와 지속적으로 얘기한다.

여기서 말하는 "활동의 근거지"는 무엇을 말하는 것 일까요?

시작

새로운 요구사항을 자연스럽게 수용할 수 없다면 리팩터링을 시작해야할 순간이라 생각할 수 있다. (p.346)

리팩터링은 도메인을 더욱 심층적으로 이해한 개발자가 더 명쾌하고 유용한 모델로 개선할 수 있는 여지를 발견하는 과정에서 얻게 된 학습의 결과다 (p.346)

개발자를 위한 설계

유연한 설계는 설계의 의도를 전달한다. 유연한 설계는 실행중인 코드의 영향을 쉽게 예측할 수 있게 만들어주므로 설계 변경의 결과 역시 쉽게 예상할 수 있다. 유연한 설계를 토대로 의존성과 부수 효과를 감소시킴으로써 정신적인 부담이 많이 생기지 않도록 제한할 수도 있다. 유연한 설계는 사용자에게 가장 핵심적인 부분만을 세밀하게 표현하는 심층적인 도메인의 모델에 기반을 둔다. 이것은 변경이 가장 빈번하게 발생하는 부분은 유연하게 유지하고 그 밖의 자주 변경되지 않는 부분은 단순하게 만드는데 도움이 된다. (p.348)

타이밍

도메인의 핵심을 찌르지 못하면서 단지 기술적인 기교를 뽐내기 위한 용도로 "유연한 설계"를 도입해선 안된다 (p.349)

kth990303 commented 1 year ago

13. 더 심층적인 통찰력을 향한 리팩터링

변경을 완벽하게 정당화할 수 있을 때까지 기다린다면 지나치게 오랫동안 기다린 셈이다. (p.349)

소프트웨어 개발은 변경의 이익과 변경을 하지 않음으로써 입게 되는 손실을 정확하게 계산할 수 있는 예측 가능한 프로세스가 아니다. (p.349)

리팩터링을 두려워하여 계속해서 미루는 데엔 여러 가지 이유가 있을 듯합니다. 시간적 자원 부족, 변경 여파 확인의 어려움. 이 두 가지가 가장 크지 않을까 싶은데, 이러한 이유로 리팩터링을 미루게 되면 미룬 기간동안 개발자들은 간접적으로 고통이 더해진다고 생각합니다. (물론 우리는 이상이 아닌 현실에서 살기 때문에 시간적 자원이 정말 부족한 경우는 어쩔 수 없다고 생각합니다.)

이런 적극적인 태도가 모든 변경에 대해 항상 정당화되는 것은 아니다. 출시 전날에는 리팩터링을 해서는 안된다. 도메인의 핵심을 찌르지 못하면서 단지 기술적인 기교를 뽐내기 위한 용도로 "유연한 설계"를 도입해서는 안 된다. 우아한 정도와 상관없이 도메인 전문가가 납득하지 못하는 "더 심층적인 모델"을 도입해서는 안 된다. (p.349)

다만 앞에서 말한 적극적인 리팩터링이 적당한 범위에서 이루어져야 한다고 생각합니다. 따라서 책의 해당 문장이 공감이 많이 됐습니다.

leejaeseung commented 1 year ago

도메인 패턴과 디자인 패턴

→ 디자인 패턴은 구현에 관련한 패턴이다. 디자인 패턴이 모델에도 적용 가능한 개념이라면 도메인 패턴이라고 할 수 있다.

FLYWEIGHT 패턴이 도메인 패턴이 아닌 이유?

→ FLYWEIGHT 패턴은 VALUE OBJECT 의 인스턴스 갯수를 좀 더 효율적으로 사용하게 해주는 패턴이다. 이 패턴을 적용한다고 해서 모델이 변경되거나 하진 않는다. (모델의 입장에선 VALUE OBJECT 의 인스턴스 갯수가 몇 개던지 상관이 없다.)

caffeine-library / Domain-Driven-Design