IT Paradigm/DDD

도메인 주도 설계 3부 독서 후기 Part.1 (feat. DDD)

yeTi 2023. 10. 23. 14:08

안녕하세요. yeTi입니다.
오늘은 도메인 주도 설계 의 3부의 읽은 후기를 기록하려고 합니다.

3부는 내용이 많이서 2편으로 나눠서 기록합니다.

지속적인 리팩터링을 통해 심층모델로 도약할 수 있다.

리팩터링이란 소프트웨어의 기능을 수정하지 않고 설계를 다시 하는 것을 의미합니다.

관건은 사전에 모든 설계 결정을 내리기보다는 기존의 기능은 유지한 채 끊임없이 코드를 변경하면서 설계를 좀 더 유연하게 개선하거나 이해하기 쉽게 만드는 과정이라는 것이죠.

#XP 에서는 점진적 설계를 말하고 #TDD 에서는 작은 목표를 기반으로한 지속적인 리팩토링을 말합니다. (모두 켄트 벡의 저서입니다.)

DDD에서는 리팩터링의 수준에 대해 이야기 합니다.

리팩터링의 목표는 개발자가 단순히 코드가 수행하는 바를 이해하는 것뿐만 아니라 왜 그렇게 수행되는지를 이해하고 도메인 전문가와의 의사소통에 이를 연관시키는 것이다.

도메인 전문가와 의사소통을 위해 리팩터링을 한다고 말합니다.

실무에서도 코드를 유의미한 비즈니스 단위로 구성하기 위해 리팩토링을 해나가고 있는데 사람의 인지적인 측면에서 이해도를 높일 수 있어 도움이 된다고 느끼는 부분입니다.

추상화란 불필요한 정보를 제거하여 정보의 복잡성을 줄이는 활동입니다.

모델은 지식을 선택적으로 단순화하고 의식적으로 구조화한 형태이다. - p.185 객체지향의 사실과 오해

심층 모델이 추상화를 의미하지 않는다고 말한 이유가 도메인 전문가의 주요 관심사와 가장 적절한 지식을 표현하는 모델이기 때문인거 같습니다.

추상화를 했다면 표면적인 속성에서 유의미한 속성만 선택했을 텐데 그러한 차원을 넘어 적절한 지식을 표현하기 때문에 추상화를 의미하지 않는다고 말했다고 느낍니다.

그리고 심층 모델은 설계에 표현력을 제공합니다. 이러한 표현력에 유연하고 명확인 설계가 주어진다면 반복적인 리팩터링으로 선순환의 피드백 고리를 만들 수 있습니다.

우리가 리펙터링을 하는 이유는 복잡도를 줄이기 위함입니다.

Kent beck은 Tidy First 를 말하고 있습니다.

TDD에서도 말했듯이 작은 단위의 리펙터링을 해나가며 XP 에서 말하는 점진적 설계를 달성해야 합니다.

그러다보면 모델의 융통성과 표현력이 높아지는 사건이 발생합니다. 여기서 사건이라는 단어가 중요합니다. 발생되어지는 것이죠.

최근 재사용성을 나름대로 정의한 사건이 떠오릅니다. 흔히 재사용성을 말할 때 모델의 융통성이 일순간에 생기기를 바랍니다.

이러나 이처럼 모델의 융통성은 특정시점에 발현되는 사건에 의해 생기는 것이기 때문에 재시용성이라는 특성도 지속적인 리펙터링을 통해 특정 시점에 가질 수 있는 것입니다.

결국 심층 모델이란 업무 지식의 깨달음에서 온다고 느낍니다.

문제는 깨달음이란 초기에 오지 않고 뒤늦게 찾아온다는 것입니다.

우리는 이미 시간과 노력을 투입해서 개발 활동을 해왔는데 깨달음에서 온 심층 모델을 과감하게 적용할 수 있을까요??

8장의 제목인 도약이라는 단어로 설명이 가능해 보입니다.

우리가 비즈니스를 수행함에 있어 지금의 모델도 충분하다면 도약은 필요없습니다.

그러나 지금의 모델이 우리의 비즈니스를 충분히 반영하지 못한다면 도약이 필요합니다.

도약에는 시의적절함이 요구되 보입니다.

설계는 지속적으로 암시적인 개념을 명확하게 하는 활동이다.

아무리 이상적인 모델이라도 정제되지 않은 형태로 인식하는 것에서부터 출발합니다.

지속적인 지식 탐구와 리펙터링이 정제되지 않은 모델을 심층 모델로 도약할 수 있도록 도와줍니다.

일단 시작하라는 의미죠.

개발자는 현실의 복잡한 문제를 해결하기 위해서 암시적인 의미의 단서나 개념을 주고받는 언어속에서 찾아야 합니다.

추가적으로 도메인 지식을 쌓기 위해 관련 자료를 검토하고 조사하기를 마다하지 않아야 하며 명확한 모델인지를 실험을 통해 확인해야 합니다.

고로 현실 세계에 관심이 많아야 한다는 얘깁니다.

흔히 개발자라면 기술적 해결에 집중하는 경향이 있습니다만 현실의 문제를 해결하기 위해서는 현실에 관심이 많아야 합니다.

만일 우리가 복잡하게 뒤얽힌 개념들을 간결하게 표현하는 용어를 찾는다면 의사소통 또한 간결해지고 명확해질 것입니다.

의사소통이 간결해지고 명확해지면 모델 또한 그렇게 될 가능성이 높아집니다.

개념을 도출하는데 있어 도메인 전문가의 지식을 활용할 수 있는데요.

도메인 전문가의 지식에 기반한 개념을 모델에 적용함으로써 보다 도메인 모델에 적합한 표현력을 가진 모델로 개선할 수 있습니다.

같은 맥락으로 개발을 함에 있어 복잡성이 높아질 수록 구현이 난해해진다는 느낌을 받습니다.

우리는 이러한 난해함을 실마리로 명확한 개념을 도출하기 위한 활동을 진행할 수 있습니다.

더 나아가 해당 도메인을 알 수 있는 서적이나 해당 도메인을 개발했던 개발자의 서적을 참고하는 것은 즉시 이용할 수 있는 지식을 얻을 수는 없더라도 시도해볼 만한 출발점 정도는 가질 수 있습니다.

실험은 유용한 것이 무엇이고 유용하지 않은 것이 무엇인지를 배우는 방법이다. - p.231

XP 에서 말하는 점진적 설계가 떠오릅니다.

소프트웨어에서 점진적 설계가 가치있는 이유 가운데 하나는 우리가 어떤 애플리케이션을 최초로 작성하는 경우가 많다는 것이다. - XP

방향의 선회는 갈팡질팡만 한 것이 아니라 유용성에 대한 실험을 진행한 것입니다.

설계 과정에서 실수를 피하려고 발버둥친다면 더 적은 경험을 바탕으로 설계를 해야 하는 탓에 품질이 더 낮은 결과물을 얻게 될 것이다. 그리고 어쩌면 여러 번의 신속한 실험을 거쳐 설계를 하는 것에 비해 시간이 더 오래 걸릴 수도 있다. - p.232

중요한것은 개념을 찾으려고 발버둥만 칠 것이 아니라 구현에 반영하면서 모델의 효용성을 실험적으로 느껴야합니다.

제약조건은 암시적인 상태로 존재하며, 이를 명시적으로 표현하면 설계를 대폭 개선할 수 있다. - p.233

도메인 규칙이 엔티티가 수용할 수 있는 범위를 넘어선다면 명세(specification) 를 이용해서 단순화 하면 좋습니다.

명세(specification) 를 이용하면 어떤 객체가 특정 기준을 만족하는지를 서술적으로 표현할 수 있고 이는 설계가 모델을 더욱 명확하게 반영할 수 있도록 합니다.

SPECIFICATION을 활용하면 검증(validation), 선택(selection), 요청 구축(building to order)을 서술할 수 있습니다.

유연한 설계는 팀의 지속가능성을 강화시킨다.

소프트웨어의 궁극적인 목적은 사용자를 만족시키는 것이다. 하지만 우선 그 소프트웨어는 개발자를 만족시켜야 한다. - p.257

생각이 프로덕트팀으로 확장이 됩니다.
프로덕트팀 혹은 개발자가 궁극적으로 추구해야하는 가치는 소비자의 만족입니다.

그러나 재밌는것은 소비자는 만족하지만 내부 구성원들이 만족하지 못하면 그 서비스는 지속성을 위협받는다는 것입니다.

왜냐하면 구성원들의 만족도가 떨어짐으로서 서비스의 애착이나 업무 만족도 또한 떨어질 것이기 때문입니다. 이 시간이 유지되거나 악화되어갈수록 소비자 만족도와는 상관없이 각자 나를 위해 떠나갈 것입니다.

이어서 XP에서 말하는 인간성의 원칙이 떠오릅니다.

결국 서비스나 개발은 인간이 하는 것이기 때문에 각자의 만족도나 동기부여도 업무를 진행함에 있어 중요합니다.

또 다른 이유가 있습니다.

가장 작은 시스템에서조차 이러한 취약성(fragility)은 구축 가능한 행위의 풍부함을 제약하는 요인으로 작용한다. 취약성은 리팩터링과 반복적인 정제를 방해한다. - p.258

개발자의 확신이 결여될 수록 코드를 수정하는 범위와 빈도가 낮아질 수 있습니다.

이는 결국 변경 비용의 증가로 이어집니다.

마침 어제 읽은 점진적 설계와 연결됩니다.

만약 변경 비용이 꾸준히 올라가지 않는다면, 이 점이 소프트웨어를 개발하는 최선의 방법에 대한 논의에는 어떤 영향을 주게 될까? - p.94 XP by Kent Beck

변경 비용이 증가하는 한 예시로 무수한 중복과 확신을 할 수 없는 스파게티 코드가 만드는 불확신입니다.

이를 TDD 에서는 다음과 같이 말합니다.

단순한 설계와 확신을 불어 넣는 테스트 슈트를 만들도록 격려한다. 당신이 천재라면 당신에게 이런 법칙은 필요 없다. 또 당신이 멍청이라면 역시 이런 법칙이 도움이 되지 않을 것이다. 그 사이에 존재하는 대다수의 사람들은 다음 두 가지 단순한 법칙을 따름으로써 잠재력을 한껏 발휘할 수 있다. - p.37 TDD by Kent Beck

확신을 가진다는 것은 변경 비용 예측가능하게 만들어준다고 느낍니다.

TDD 에서는 확신을 가지는 방식을 테스트 슈트로 설명을 하는데 DDD 에서는 MODEL-DRIVEN DESIGN 으로 설명합니다.

무수히 많은 과도한 엔지니어링이 유연성이라는 명목으로 정당화되어 왔다. <중략> 정교한 시스템을 만들 목적으로 조립 가능하고 그럼에도 이해하기가 어렵지 않은 요소를 만들어내려면 MODEL-DRIVEN DESIGN을 적당한 수준의 엄밀한 설계 형식과 접목하고자 노력해야 한다. - p.258

유연성 혹은 재사용이라는 명목으로 구성 요소를 잘게 쪼개는것이 정당화 되어왔지만 이러한 행위가 지속되면 과도한 추상 계층과 간접 계층이 만들어지면서 오히려 유연성에 방해가 됩니다.

따라서 적정 수준으로 구성 요소의 경계를 가져갈 필요가 있는데 이의 기반이 모델이어야 합니다.

클라이언트 개발자는 느슨하게 결합된 개념들의 최소 집합을 유연하게 사용해서 도메인 내의 일련의 시나리오를 표현할 수 있다. 각 설계 요소는 서로 자연스럽게 조화를 이루며 맞물리고, 그 결과 예상 가능하고 명확하게 특성을 파악할 수 있으며, 견고해진다. - p.259

구성 요소의 경계가 모델 수준으로 정의되면 개발자는 개념의 최소 집합으로 시나리오를 표현할 수 있게 됩니다.

그리고 시나리오로 표현할 수 있다는 것은 예상 가능하고 명확하게 특성을 파악할 수 있다는 것이며 견고하게 짜여진다는 의미입니다.

INTENTION-REVEALING INTERFACE

클라이언트 개발자가 객체를 효과적으로 사용하는 데 알아야 할 정보를 인터페이스로 부터 얻지 못한다면 세부적인 측면을 이해하고자 객체 내부를 깊이 파고들 수밖에 없다. - p.261

유비쿼터스 언어를 기반으로 INTENTION-REVEALING INTERFACE 를 만들어야 하는 이유는 인지 과부하(cognitive overload)와의 힘겨운 투쟁을 수월하게 하기 위해서 입니다.

개발자가 컴포넌트를 사용하기 위해 컴포넌트의 구현 세부사항을 고려해야 한다면 캡슐화의 가치는 사라진다. - p.261

조영호님의 객체지향의 사실과 오해에서도 객체의 상태보다 메시지에 집중하라고 말하는 부분이 떠오릅니다.

수행 방법에 관해서는 언급하지 말고 결과와 목적만을 표현하도록 클래스와 연산의 이름을 부여하라. 이렇게 하면 클라이언트 개발자가 내부를 이해해야 할 필요성이 줄어든다. 이름은 팀원들이 그 의미를 쉽게 추측할 수 있게 UBIQUITOUS LANGUAGE에 포함된 용어를 따라야 한다. 클라이언트 개발자의 관점에서 생각하기 위해 클래스와 연산을 추가하기 전에 행위에 대한 테스트를 먼저 작성하라. - p.262

실무에서 지속적으로 하는 노력의 방향성이 틀리지 않았다는 위로를 주는 문단입니다.

TDD를 적용하여 클라이언트 개발자의 관점에서 생각하기 위해 행위에 대한 테스트를 먼저 작성하려는 노력과

수행 방법에 관해서는 언급하지 말고 결과와 목적만을 표현하도록 클래스와 연산의 이름을 부여하도록 노력하는 부분은 개발자의 인지 과부하를 줄이기 위한 노력입니다.

SIDE-EFFECT-FREE FUNCTION

SIDE-EFFECT-FREE FUNCTION 이란 용어가 매우 이상향적인것처럼 느껴집니다. SIDE-EFFECT-FREE 를 달성할 수 있다면 개발자로써 얼마나 뿌듯할까요?

개발자가 결과를 예상하려면 연산 자체의 구현뿐 아니라 연산이 호출하는 다른 연산의 구현도 이해해야 한다. - p.266

조영호님의 객체지향의 사실과 오해에서 협력을 믿어라 고 얘기하는데 연산의 구현뿐 아니라 연산의 내부 구현도 이해해야하는 상황이 협력을 믿지 못하는 상황에서 나오는거 같아 동일한 맥락에서 이야기하고 있다고 느껴집니다.

이어서 INTENTION-REVEALING INTERFACE 에서 언급했던 부분이 다시 한번 떠오릅니다.

개발자가 컴포넌트를 사용하기 위해 컴포넌트의 구현 세부사항을 고려해야 한다면 캡슐화의 가치는 사라진다. - p.261

결국 우리가 객체지향에서 말하는 메시지에 집중하고 협력을 설계하기 위해서는 협력을 믿을 수 있는 SIDE-EFFECT-FREE FUNCTION 을 만들어가야 한다는 생각이 들었습니다.

(근데 SIDE-EFFECT-FREE FUNCTION 에서 말하는 부수효과를 일으키지 않으면서 결과를 반환하는 연산을 함수(function)라고 한다. 를 조합하자는 것이 FP(Functional Programming) 의 기본 개념 아닌가?)

가능한 한 많은 양의 프로그램 로직을 관찰 가능한 부수효과 없이 결과를 반환하는 함수 안에 작성하라. 명령(관찰 가능한 상태를 변경하는 메서드)을 도메인 정보를 반환하지 않는 아주 단순한 연산으로 엄격하게 분리하라. 한 걸음 더 나아가 책임에 적합한 어떤 개념이 나타난다면 복잡한 로직을 VALUE OBJECT로 옮겨서 부수효과를 통제하라. - p.267

명령과 질의를 분리하기 위해 명령을 도메인 정보를 반환하지 않는 아주 단순한 연산으로 엄격하게 분리하라는 말은 이해가 갑니다.

그런데 복잡한 로직을 VALUE OBJECT로 옮기라는 말은 복잡한 도메인 지식이 엔티티와 애그리게이션 단위로 묶여야 하는거 아닌가라는 생각에 살짝 의아한 생각이 들었습니다.

한편으로 엔티티외에는 VALUE OBJECT로 볼 수 있겠다는 생각에 수긍이 가기도 합니다.

결국 우리는 명령과 질의를 나누고 복잡한 연산은 VALUE OBJECT에 위임함으로써 SIDE-EFFECT-FREE 를 달성할 수 있습니다.

ASSERTION

연산의 부수효과가 단지 구현에 의해서만 함축적으로 정의될 때 다수의 위임(delegation)을 포함하는 설계는 인과 관계로 혼란스러워진다. 프로그램을 이해하려면 분기 경로(branching path)를 따라 실행 경로를 추적하는 수밖에 없다. 이렇게 되면 캡슐화의 가치가 사라지고, 구체적인 실행 경로를 추적해야 한다는 필요성으로 추상화가 무의미해진다. - p.272

객체지향 프로그래밍을 하면서 함정에 빠지는 순간을 잘 묘사해줬다는 느낌을 받았습니다.

객체지향 프로그래밍의 주요 개념인 캡슐화, 추상화, 다형성이라는 개념이 인과 관계로 혼란스러워지면 캡슐화의 가치가 사라집니다.

실제로 협력을 믿지 못하고 구현에 관심이 많아지는 이유가 프로그램을 이해하려면 분기 경로(branching path)를 따라 실행 경로를 추적해야하기 때문이라는 생각이 들었습니다.

그리고 동일한 인터페이스를 구현하는 두 개의 하위 클래스를 사용하는 개발자가 결과를 예측하려면 어떤 하위 클래스를 사용하고 있는지 알아야 하는 불신에 의해 추상화와 다형성도 무용지물이 됩니다.

그렇다면 어떻게 캡슐화와 추상화, 다형성의 가치를 유지할 수 있을까요?

내부를 조사하지 않고도 설계 요소의 의미와 연산의 실행 결과를 이해할 수 있는 방법이 필요하다. - p.272

프로그램 코드에 직접 ASSERTION을 명시 <중략> 자동화된 단위 테스트를 작성해
서 ASSERTION의 내용을 표현 <중략> 적절한 문서나 다이어그램으로 ASSERTION을 서술 … - p.273

개발자가 코드의 내부 구조를 보지 않고도 이해할 수 있도록 다양한 방식으로 기록하라고 말합니다.

테스트 코드를 서비스 사양서로 활용하는 활동의 쓰임새가 개발자들이 이해할 수 있는 문서라는 것을 한번 더 느낄 수 있는 부분입니다.

하지만 에릭 에반스는 궁극적으로 사람은 술어를 이해할 수 없기 때문에 명확한 모델을 발견하는 것이 중요하다고 말합니다.

9장 암시적인 개념을 명확하게 설계에서 가장 어색한 부분을 조사해야한다고 했던말이 일맥상통하다는 느낌을 받았습니다.

복잡성이 증가한 곳은 문제가 있을 가능성이 높습니다.

CONCEPTUAL CONTOUR

모델 또는 설계를 구성하는 요소가 모놀리식 구조에 묻혀 있을 경우 각 요소의 기능이 중복된다. <중략> 반면 클래스와 메서드를 잘게 나누면 클라이언트 객체가 무의미하게 복잡해진다. - p.277

설계를 하다보면 자주 부딪치는 난관중 하나입니다. 중복을 제거하자니 구성 요소의 단위가 원자적이 되어 응집되는 느낌이 적어지고 오히려 인지적 혼란을 주는 경우가 있기 때문입니다.

도메인에는 잠재적인 일관성이 존재하므로 도메인의 일부 영역에서 적절한 모델을 발견하면 이 모델이 나중에 발견되는 다른 영역과도 일관성을 유지할 가능성이 높다. - p.277

즉, 반복적인 리팩터링을 통해 유연한 설계를 얻게 되는 이유 중 하나는 도메인에는 잠재적인 일관성이 존재하기 때문입니다.

앞서 구성 요소의 적절한 단위를 정의하는 것은 도메인에서 유의미한 단위를 찾는 순간입니다. 그 전에는 기술적인 리팩토링만 할 수 있습니다.

STANDALONE CLASS

의존성이 증가할수록 설계를 파악하는 데 따르는 어려움이 가파르게 높아진다. 이는 개발자에게 정신적 과부하 (mental overload)를 줘서 개발자가 다룰 수 있는 설계의 복잡도를 제한한다. - p.283

우리가 객체지향을 하고 도메인 주도를 하는 이유 중 하나는 인간의 인지 과부하를 줄이기 위한 노력입니다.

이어지는 맥락으로 개념적으로 적절한 경계가 나눠졌다고 하더라도 상호 의존성의 증가는 정신적 과부하 (mental overload)를 줄 수 있습니다.

현재 상황과 무관한 모든 개념을 제거하라. 그러면 클래스가 완전히 독립적(self-contained)으로 바뀌고 단독으로 검토하고 이해할 수 있을 것이다. 그러한 독립적인 클래스는 MODULE을 이해하는 데 따르는 부담을 상당히 덜어준다. - p.284

이에 현재 상황과 무관한 모든 개념을 제거하라고 말합니다. 의존성이 없는 독립적인 클래스는 이를 이해하는데 따르는 부담이 줄어들기 때문입니다.

하지만 의존성을 제거하라고해서 모델에 포함된 모든 요소를 원시 타입(primitive)으로 격하시키는 것에는 주의해야합니다.

이는 직전에 나왔던 개념적 윤곽에서도 절반의 우라늄 원자는 우라늄이 아니다 라고 표현한 것과 같이 과도한 분리는 주의해야합니다.

CLOSURE OF OPERATION

실수 집합에 포함된 임의의 두 수를 결합한 결과 역시 항상 실수 집합에 포함된다. - p.286

CLOSURE OF OPERATION(연산의 닫힘) 은 은유입니다.

함수에 대해서 반환 타입과 인자 타입이 동일하다면 인스턴스 집합에 닫혔다고 표현할 수 있는데, 이는 부차적인 개념을 사용하지 않고도 고수준의 인터페이스를 제공하는 효과가 있습니다.

부차적인 개념을 사용하지 않는다는 것은 개발자에게 정신적 부담이 되지 않기 때문에 보다 편안하게 접근할 수 있습니다.

소프트웨어를 분명하고, 예측 가능하며, 전달력 있게 만든다면 추상화와 캡슐화의 목표를 효과적으로 달성할 수 있다. - p.288

잘 짜여진 소프트웨어란 분명하고 예측가능하며 전달력이 있다는 것입니다. 사람이 분명하고 예측가능하며 전달력 있게 느낀다는 것은 적절한 추상화와 캡슐화로 인지적인 범위내에 존재한다는 의미입니다.

어떻게 보면 좋은 설계라는 것의 궁극적인 목표는 분명하고 예측가능하며 전달력이 있게 만드는 것이라는 생각이 듭니다.

이전에 독서 모임에서 유영모님이 소프트웨어 개발에서 싸워야하는 것은 예측 가능성이라고 언급하신게 떠오르기도 하며 중요한 관점이라는 생각이 듭니다.

이어지는 생각으로 현재 스스로 좋은 설계를 추종하는 이유도 좋은 제품을 만들어 회사의 비즈니스를 달성하기 위함입니다.

좋은 제품이란 궁극적으로 회사에 돈을 벌어다주는 제품이라고 생각하고 있고

좋은 설계의 역할은 회사의 니즈를 적절한 실체로 만들어내는 요소라고 생각합니다.

따라서 좋은 설계가 기반이 된다는 것은 적절한 실체를 예상한 기간에 예상한 품질로 예상한 기능을 만들 수 있다는 것입니다.

좋은 설계란 분명하고 예측가능하며 전달력있게 표현하는 것입니다.

누구에게 표현할까요? 제품을 함께 만드는 사람들에게.

마무리

3부의 대주제가 더 심층적인 통찰력을 향한 리팩터링 입니다.

리팩터링이라는 활동으로 심층적인 통찰력에 도달할 수 있도록 한다는 것이지요.

그런 의미에서 부주제인 도약, 암시적인 개념을 명확하게, 유연한 설계 는 보다 나은 설계를 위한 활동이라는 것입니다.

켄트 벡이 XP, TDDBE 에서 말하는 유용한 설계 활동의 방향성이 에릭 에반스의 DDD 에서도 표현되는 것을 보면서 확실히 설계라는 활동은 프로젝트 초기에 완료하는 단일 활동이 아니고 서비스의 생명 주기가 다하는 날까지 이어지는 활동이라는 생각이 듭니다.

이러한 맥락에서 에릭 에반스는 좋은 설계(?), 유연한 설계를 달성하기 위해서는 도메인 지식에 기반한 통찰력과 통찰력을 기록할 수 있는 모델을 설계의 중심에 둡니다.

특히 INTENTION-REVEALING INTERFACE 부터 CLOSURE OF OPERATION 까지 제시하는 유연할 설계를 달성하기 위한 기법은 단순하게 규칙으로 떠도는 형식들의 근본적인 이유를 제공해서 보다 이해의 폭을 넓히는데 도움이 되었습니다.

아무튼 가장 중요한 것을 개발의 중심에 있는 개발자(사람) 입니다. 에릭 에반스도 언급했듯이 개발자가 만족하는 설계가 되어야 합니다.

지난 기록