[PLoP] Rebecca Wirfs-Brock의 Nature of Order I.

11월 19, 2010 — arload

Rebecca Wirfs-Brock 국내에는 비교적 많이 알려져 있지 않지만, 정말 현실을 직시하는 몇 안되는 Architect입니다. 일전에 소개 드린것 처럼, 절대 어느 한가지 맞다고, 자기의 설계 기법이나, 방법을 따라야 한다는 몇몇 아키텍트와 달리. 여러가지 해결책을 펼쳐놓고, 주어진 상황에서 적합한 전략/솔루션을 선택하는 아키텍트 입니다.
아마도 패턴에 영향을 많이 받아서 그런거겠죠. 패턴 자체가 그러거니깐요.

패턴을 공부하다 보면 무엇이 맞다는 것 보다나는, 주어진 Context/Resulting Context를 심각히 고려하고 그중에 적합한 것을 선택하는 자세가 몸에 베이게 됩니다. 그게 아니면 제대로 패턴을 익힌거라고 할수 없으니깐요. 물론 저는 이제 아주 아주 조금 눈을 떠 가는 중이구요. (전 애벌레입니다. 🙂 – 몇몇 대단하게 보시는 분이 있어서. 오해를 하시지 마시기를…)

저도 많은 정보를 전달해 드리고 싶지만, 영어가 짧고, Nature of Order에 대한 선 지식이 없어서, 잘못된 내용이 있을수도 있습니다. (폭탄 발언?) 여튼 제가 이해하는 것이 잘못되었다고 생각하신 분은 댓글을 달아 주시면 바로 수정하겠습니다. 일단 잘못된 정보를 전달하면 안되기 때문에 글을 쓰지 말라는 분도 있지만, 누군가 정확한 의견을 전달해주면 그걸 수정하는 것이 맞지, 실패나 비난을 두려워해 아무것도 공유하지 않는 것은 정말 비겁한 자세라고 개인적으로 생각합니다. 전 정반합이 힘을 믿습니다.

Christopher Alexandar의 Nature of Order라는 서적은 크게 4가지 Volume으로 구성되어 있지만, Rebecca는 두권만 언급했습니다.

• 1st Volume은 the fifteen property of things (어떤 존재, 사물에 대한 15가지 속성)
• 2nd Volume은 Unfolding process for create“lively” things (살아있는 생명쳬를 만들기 위한 절차들)

오늘 Rebecca가 발표한 내용은 1st Edition에 나오는 15가지 속성을 기반으로 S/W에 빚대어 설명하는게 골자입니다. 1시간에 이런 무거운 내용을 전달하다 보니, 하고 싶은 얘기를 다 못껴내신거 같더라구요. 그리고 저 역시도 영어가 짧아서.. 이해를 다 하지는 못한거 같습니다.

Rebecca 아주머니는, Habitable Software라는 이야기를 꺼내며 화두를 시작했습니다. 사용하기 편하고, 경험하기 쉬운 소프트웨어를 말하는 데요. 이러한 시스템을 구성하기 위해 Alexandar가 말하는 15가지 속성으로 잘 구성되어야 된다고 얘기를 꺼냅니다.

Alexandar가 말하는생명체가 가지는 15개의 속성

• Levels of scale
• Strong centers
• Boundaries
• Alternating repetition
• Positive space
• Local symmetries
• Good shape
• Deep interlock and ambiguious
• Contrast
• Gradients
• Roughness
• Echoes
• The void
• Simplicity and inner calm
• No-separateness

LEVEL OF SCALE

유기적인 소통.

먼저 Chirstopher Alexandar가 언급한 이야기를 꺼내셨습니다.

“A good design has differing levels of scale, whereas ugly, lifeless designs don’t take into account the interplay between design elements at different levels of scale.”

잘 설계된 것은 Scale이 다양한 범위를 가진다. , 반면 , 생명력이 없는 설계(잘못된 설계)는 (Sacle의 다양한 범위를 가진 ) 설계 요소들간에 상호작용을 고려하지 않았다.

Josef Albers의 그림들을 설명하며, Chirstopher Alexandar가 좋지 않은 설계라고 말한 예라고 합니다. 크기가 서로 다른 범위를 가지고 있지만, 사각형간에 어떠한 상호 작용도 없습니다. 완전히 서로 독립적이며, 유기적인 대화를 하지 못하니 좋은 구조라 아니라는 거죠.

이걸 우리가 아는 예로 바꾸면, 거대한 아키텍쳐 속에서 무수한 설계들이 들어가 있습니다. 즉 Architecture 안에 수많은 Design들이 존재하고 , 이들 간 잘 유기적으로 엮어야 한다는 것입니다. 주구 장창 말씀 드린것 처럼, 어떤 하나의 요소를 선택해, 가지는 사이드 이펙트를 보완하기 위해 또 다른 요소가 필요하고 이들 간에는 서로 연관관계 . 소통을 해야 된다는 겁니다.

PLoP Bootcamp때 나온 IO GateKeeper의 단점을 극복하기 위한 IO Triage 그리고 이 Triage가 동작하기 위해 Timestamp가 필요한 것처럼, 서로 다양한 크기의 Element가 유기적으로 엮여 있어야 된다는 것이죠. 우리의 소프트웨어로 보면 Architecture안에 무수한 Design이 들어가 있으며, 이들간에 소통/Collaboration이 있어야 된다는 의미 입니다.

범위의 크기에 따라 구조의 크기도 결정되어 진다라는 말을 했습니다. 그리고 이들 크기가 다르면 접근하는 것도 달라야 된다고 말했습니다.

Rebecca는 스케일이 단위를 이렇게 나누어 설명했습니다.

Conceptual level – Specification level – Implementation level (이것은 Martin Fowler가 Analysis Pattern에서 언급한 내용입니다.)

• a conceptual level, where we speak of a class’s responsibilities;
• a specification level of operations, attributes,and test specifications; and
• an implementation level of class, method, and variable definitions.

이에 Rebecca는 다음과 같은 말을 했습니다.

• At a lower level of scale, individual methods shouldn’t be too big. (개별적인 메소드가 너무 커서는 안된다.)
• At the next higher level, we don’t want to pack too much behavior into any subsystem or component. (특정 subsystem이나 component가 너무 많은 behavior를 가져서는 안된다)
• 이런 각 레벨에 대한 기준을 다 알고 있어도, 각기 다른 level(크기)에 Center (뒤에 Strong Cent에서 언급)들이 가져야 하는 만족할만한 비율들을 찾기 어려웠다고 하네요.

Scale은 추상화를 기반으로 구축되어야 한다.

그래서 나온 결론이 추상화 입니다. 항상 우리가 디테일한 부분까지 결정을 하기 어렵기 때문에 추상화에 초점을 맞추어 전체의 흐름을 지배하라는 얘기를 했습니다.

“Scale in building upon Core Abstraction : an example found in the smalltalk collection hireachy.” Smalltalk에는 template method로 형태로 구현되어 있기 때문에 쉽게 메소드를 추가할수 있는 구조라며 설명을 했습니다. ( smalltalk은 제가 잘모르니 pass~~~ smalltalk에 대해서 아시는분이 좀 comment를 해주시면 될듯하네요.)

아시다시피 Template Method는 전형적으로 일반적인 클래스 흐름에 역행하는 방법(IoC)입니다. 자식이 부모를 호출하는게 일반적이네, 부모가 자식을 호출하게 되죠. 즉 Concrete Class에서 세부적인 메소드를 지정하고 전체적인 흐름은 부모 클래스에서 결정하죠. 즉 부모 큰래스는 전체적은 흐름을 관장하여 큰 추상화를 얻게 됩니다. Concrete Class는 단지 부모 클래스가 정한 흐름에 맞게 호출만 될 뿐입니다. 즉 강력한 제약으로 확장성/일관성을 얻어내는 좋은 방법입니다.

여튼 추상화 기법들을 잘 이용해서 확장성 있게 만들고 이것을 통해서 다른 레벨의 컴포넌트들과 잘 통신하게 만들라는 얘기였습니다.

STRONG CENTERS

살아있는 모든 것들은, 각기 다른 레벨의 구조를 가지고 있고, 이 각기 다른 구조들은 각기 개별적인 자기 고유의 초점을 가지고 있다는 겁니다 . 예를 든다면, 심장은 산소를 골고루 전달 하기 위해서, 대장은 영양분 흡수를 위해서, 각기 이렇게 다른 역할을 가지고 있다는 것을 의미하죠. 이들 각각 강력한 Center 를 가져야 된다고 말했습니다.

Software에서 Center

• Well-defined role and patterns of interaction
• Control centers
• Domain models : a network of entities, values, aggregate roots, Domain and relationships between them.
• ??? (그외 몇가지것을 더 언급했는데 못 적었습니다 .T_T)

그러면서, 자기가 만든 RDD (Responsibility Driven Design)이 이러한 철학으로 설계 되었다고 얘기합니다.

위가 RDD에 대한 예 인데, Strong Center와 맟 닿아 있는 것을 알수 있습니다. 하나의 생명체가 여러가지 유기적인 요소로 구성되어 있고, 각각 자신의 역할들을 가지고 있다는 것죠. 그리고 RDD에서 설명한 Streotype들을 보여주었습니다.

• Information holder – knows and provides information. (정보를 알고 제공한다)
• Structurer – maintains relationships between objects and information about those relationships. (객체간의 관계와 객체가 가지는 관계에 대한 정보들을 관리한다. )
• Coordinator – mechanically reacts to events. (event에 기계저으로 대응한다)
• Controller – makes decisions and closely directs others’ actions. (결정을 내리고, 다른 행위를 직접 지시한다.)
• Interfacer – transforms information and requests between distinct parts of a system (시스템의 구분되는 요소들간에, 정보를 변환하고, 요청을 한다.)
• Service provider – performs work on demand (요구되어지는 일을 수행한다.)

이러한 것들이 Strong Center가 되겠구나 알수 있었습니다. 이러한 것들을 하나씩 설명하면서 각기 다른 레벨마다, Controller 하나에서 모든 것을 관리해야 튼튼한 구조를 가질수 있다는 말을 했습니다.

그리고 RDD의 디자인 원칙들이 Christopher Alexandar의 원칙과 맞닿아 있는 것을 알수 있었습니다.

• Maximize Abstraction Initially hide the distinction between data and behavior. Think of objects responsibilities for “knowing”, “doing”, and “deciding”
• Distribute Behavior Promote a delegated control architecture Make objects smart— have them behave intelligently, not just hold bundles of data
• Preserve Flexibility Design objects so interior details can be readily changed

BOUNDARIES

경계는 center 그 자체의 고유성을 강화시키고, center와 center 주위의 연관되어 있는 것들을 결속시키는 것 둘다를 의미합니다.

Rebecca는 “인터페이스를 어떻게 정할건가가 곧 Contract가 되고 , 이것이 자연스럽게 경계가 된다”라고 말했습니다. 그럼 어떻게하면 경계를 잘 정하느냐에 대한 고민에 Rebecca는 Eric Evans의 DDD에서 언급한 Domain Aggregates를 좋은 예로 설명했습니다. (자세한 내용은 링크를 참고하세요. )

A domain aggregates is a cluster of associated objects that is treated as a unit for the purpose of data change.

이때 순간 저의 머리를 스쳐간게 .NET Framework의설계자인 Krysztof Cwalina의 Component (Framework Desing Guidelines 2nd)정의였습니다.

하나의 Unit으로써 배포되어질수 있고, 계속해서 요구사항들을 수용하며 진화, 발전할수 있는 타입들을 묶어놓은 집합이 Component 이다.

바로 유기적으로 묶여, 변화를 같이 흡수하고 , 어떠한 행위를 할때 같이 움직이는 단위들을 말하고, 곧 이게 경계가 된다는 의미로 받아들여 졌습니다. 또한 경계는 서로간의 구분을 짖는 요소입니다. 어떤 변화가 하나의 Boundary(경계)안에서 흡수되지, 다른 곳에 전파되지 못하도록 막는 좋은 예가 될거 같습니다.

물론 경계를 정하는 방법은 상황에 따라 유동적으로 정해질 것입니다. 저의 생각으로는 아마 다양한 XXX-Driven Design이 나오는 것들도 그리고 Zachman 스타일 처럼, 다양한 View를 봐야 하는 것도 이러한 이유라고 생각이 듭니다. 인터렉션의 기준이 될수도 있고, 배포가 기준이 될수도 있겠죠. 아마 현재의 시스템을 가장 잘 파악할 수 있고, 유지하기에 좋은 방식을 취하는 게 좋을것 같다는 생각이 듭니다.

이것 역시 해당 도메인의 경험이 쌓여야, 또는 배우고, 수련해야 가능한 일이겠죠 🙂 경계를 정해서 개별 Center의 응집성을 올리고, 서로간의 변화에 대한 전파를 상쇄시키는 관점으로 이해해 주시면 될듯 합니다.

ALTERNATIVE REPETITION (교차적으로 일어나는 반복)

시스템 요소간에, 상호보완적인 교차와 반복이, 단순한 Iterration의 반복이 아닌.., 시스템의 행위와 동적인 구조를 식별하고, 강화시키고, 견고하게 만든다는 것을 의미합니다.

Uncle Bob의 SOLID Principle이 이러한 좋은 예가 될수 있습니다.

• Single Responsibility Principle – A class should have one, and only one, reason to change.
• Open Closed Principle – You should be able to extend a classes behavior, without modifying it.
• Liskov Substitution Principle – Derived classes must be substitutable for their base classes.
• Dependency Inversion Principle – Depend on abstractions, not on concretions.
• Interface Segregation Principle – Make fine grained interfaces that are client specific.

OCP와 LSP는 확장성을 얻기위해 제약과 Concrete Class간에 Responsibility를 설명한 부분이며, ISP와 SRP는 객체와 인터페이스의 역할에 초첨을 맞쳐 너무 무겁지 않는 가벼운 객체를 만드는 겁니다. DIP는 좀 특수한 경우이지만, 굉장히 자주 사용되는 구조이죠. (좀더 관심이 있으신 분은 저희 스터디팀이 4년전쯤에 발표한 동영상 강의를 보시면 될듯 합니다. Uncle Bob의 원본 자료와 송치형/최상훈님의 마소 내용들을 버무려 무료 강의를 만들었습니다.)

디자인 패턴을 공부하시는 분이 가장 큰 실수를 하시는 것이 아 이러한 Structure를 가지고 있으면 Decorator 구나, Proxy구나 라고 이것을 하나의 단위로 인식할려고 하십니다. GoF 패턴 Template이 가져온 오해였죠.

여러분이 좀더 쉽게 GoF 패턴을 바라보는 방법은 위 5가치 원칙들이 이러 이러한 상황에 쓰이면 Decorator구나, 이러 이러한 상황에 쓰이면, Proxy구나 이렇게 받아 들이는 것이 좀더 패턴을 알수 있는 방법입니다. 바로 이러한 원칙들이 모여서 GoF 패턴이 만들어 진 것이고, GoF를 접착제로 해서, 더 큰 아키텍쳐 패턴들이 엮이게 됩니다.

좋은 구조라는 것은 이러한 SOLID 같은 원칙들(자원을 공유해서 쓸때, process와 thread의 scheduling 기법등..)이 지켜지며, 교차적으로 반복되어 견고한 구조 (strong center)를 만든다는 의미입니다.

또한 Rebecca는 반복되는 Collarboration Pattern들이 Software Control Center 부분의 설계를 강화시킨다는 이야기를 했습니다.

저의 경험상으로는 Broker를 예로 들수 있습니다. Fault Tolerance 한 시스템을 구축하기 위해 필요한 IO Gatekeeper , CORBA의 Object Request Broker, Android의 Binder가 바로 좋은 예가 될수 있습니다. Broker를 구축함으로써, 주고 받는 Client/Server는 많은 골치거리 일들을 Broker에게 맡기게 되어, 이로서 얻는 부수적인 이익들(모니터링, Collabration, Heterogeneouse한 환경 극복등..)은 엄청나죠.

POSITIVE SPACE

시스템을 구성하는 각각의 요소들(elements)은 완전하고, 잘 정의되어있어야 하며, 시스템 그 자체 역시 견고해야 합니다. 그리고 각각의 요소들이 전체적으로 시스템에 적합하게 구성되어 있어야 함을 의미합니다.

잘 설계되고, 구현된 소프트웨어 시스템들은 불필요한 Component나 Code들을 포함해서는 안되겠죠. 또한 불필요한 행위나 Dependency를 가지고 있어선 안됩니다. 제가 알기로는 Rebecca가 구체적으로 언급하지 않았지만 Xper의 글과 지금까지의 설계 방식을 보면 POSA1권에서 봤던 CRC(Class-Responsibility-Collaboration) Card, Diagramming , Code 를 통해 이러한 문제를 해결해 왔음을 알수 있습니다. 사실 Refactoring을 할때, 객체가 필요이상의 Responsibility를 가지고 있느냐가 좋은 기준이 됩니다.

Rebecca는 Refactroing을 할때 Responsibiities를 재할당 할것인지? Class간에 균형을 유지할 것인지 많은 고민을 한다고 합니다. 이때 중요한 기준이 positive space라고 말했습니다. 가장 간단한고 필수적인 기능을 가지고 있느냐? 각각의 Element가 하나의 목적을 위해 만들어졌는지 보라고 했습니다. Space를 구성하는 ( Level of Scale과 유사한 개념) 각각의 요소들이 이것을 보장한다면, 결국 Strong Center를 잘 준수한 상황으로 불수 있다고 합니다.

또한 DRY (Don’t Repeat Yourself – 모든 지식은 시스템 내에서 단일하고, 애매하지 않고, 정말로 믿을만한 표현 양식을 가져야 한다) 원칙을 준수하라고 말했습니다.

저는 개인적으로 Statci Analysis 방법중에서 DSM을 통해서 필요이상의 의존성이 갔는지, Code Metrics를 통해 너무 특정 Namespace/Class가 큰것이 아닌지 조사하면서 Refactoring의 기준을 잡고, 좋은 구조를 잡고 있는지 살펴봅니다. 물론 더 좋은 방법이 얼마든지 있을수 있지만, 저의 지식의 한계로 이 두개를 주로 사용합니다. 혹시 좀더 좋은 지표와 가이드라인을 아시는 분이 있으면 알려주시길 합니다.

LOCAL SYMMERIES

Relationship이 대칭적이며, 반대되는 Force(영향력 – 초점) 또는 Interaction에 균형을 맞출때, 연관된 설계 요소들의 그룹들은 더욱 강력하고, 더욱 높은 응집력을 가집니다.

Rebecca는 대칭을 통해 설계의 유사(친밀)성, 응집력, 이해력 향상을 가져 온다고 말했습니다. 장황한 메소드들을 작은 Helper Method를 이용해 추상화하여 서로 유사한 Step을 가질수 있도록 Refactoring 할수 있다고 말했습니다. 결국 이러한 대칭성을 통해서 작게는 학습 곡선을 줄이고, 나아가서는 Template Method 화 시켜서, 동일한 제어 흐름을 타게 만들고, Dependency Injection을 통한 유연성도 확보할수 있겠죠.

또한 우리 프로그래머는 별 생각없이 이렇한 대칭성을 유지할려는 습성을 가지고 있다고 말했습니다. 우리가 모든 Attribute에 setter와 getter를 정의할려고 하지요. 하지만 이런 방법이 좋은 접근 방법은 아니라고 말했습니다. 먼저 어떻게 Object가 사용될건지 고려하라고 말했습니다. 우리가 추가한 대칭성이 소프트웨어의 거대한 체계에 어떻게 적합하게 동작할건지 충분히 고려한 다음 반영되어야 된다고 말했습니다.

사실 이 이야기를 들을때 생각난 부분이 바로 .NET Framework 를 만든 Krysztof Cwalina가 제시한 Guideline들이 바로 확 떠올랐습니다다.

The Power of Sameness 그리고 You Need Feedbacks!! 입니다. 프레임워크의 생존 문제와 연관되어 있는 사용 용이성 (Usability) 문제죠. 얼마나 개발자가 직관적으로 쉽게 쓸수 있는 Framework를 만드냐는 관점에서 나온 대표적인 해결책이 바로 이 두 Guideline입니다.

• 동일함의 힘 – 한국에서 운전을 한 사람이, 미국에서 운전을 별 어려움 없이 하는 이유는 자동차의 인터페이스가(핸들, 제어법)등이 다 동일하기 때문입니다. 그렇기 때문에 유사한 목적을 가진 객체를 유사한 인터페이스로 만들어야 합니다. 개발자의 학습 곡선을 크게 감소시킬수 있습니다.
• 피드백을 받으세요 – 하지만 이러한 인터페이스 대칭성을 만들기 전에 가장 중요한 부분은 잘 만들어진 인터페이스 (객체 모델)를 만드는 것입니다. 나 혼자 이것저것 고생하는 것 보다는 다른 사람의 관점을 빌려, 몇몇 시나리오 별로 내가 만든 객체 모델을 사용한 Code Sample을 해당 분야에 경험이 많은 프로그래머 몇명들에게 나눠줘, 피드백을 받아 다듬은 다음 객체 모델을 정하라는 가이드라인입니다. 이러한 설계 가이드라인이 크게 대칭(Symmetry)에 모태를 두고 있다니 놀라웠습니다. 🙂

GOOD SHAPE

시간이 지나도 변경되지 않고 유지되는 컴포넌트들은 작고, 응집력이 강한 연관성있는 컴포넌트들로 구성되어 있습니다. 그리고 내부적인 대칭을 생성합니다.

견고한 시스템은 Prmitive Element (기본 요소)부터 거대한 구조의 시스템 아키텍쳐까지 잘 설계되고, 잘 구현되어 있어야 합니다.

Rebecca는소프트웨어가 Good Shape (좋은 모양)을 가지기 위해 우리가 고려해야 되는 부분들을 다음과 같이 열거했습니다.

• roles and patterns of collaboration – 패턴이라는 것은 개별적으로 동작하는 것이 아니라. 유기적으로 엮여 사용됩니다. 패턴들을 통해 소프트웨어의 상호작용하는 패턴들과 개별적인 객체간에 롤을 파악할 수 있습니다.
• layers – 고유성을 강화시키고, 서로간에 경계를 명확하게 만드는 것. 그래서 변화의 전파 충격을 흡수하게 만드는 등 여러가지 장점을 얻을 수 있습니다. 위에 언급한 Boundary가 바로 여기에 해당됩니다.
• sub-assemblies , modules – 더 작은 boundary로 볼수있는 단위다. 사견으로, 이때 dll과 같이 물리적으로 잘 나누어 재컴파일 없이 확장성을 얻게 만드는 것이 중요하다고 말씀 드리고 싶습니다.
• domain-specific business rules – Domain에 특화된 Rule들을 잘 정제시키고, 잘 소프트에어 넣는 것이 중요하다.

DEEP INTERLOCK AND AMBIGUITY

깊은 연관성을 가지는 컴포넌트들은 잘 정의된 경계(Boundaries)를 공유하고 있다. 경계를 통해 (컴포넌트간에 불필요한 의존성을 만들어내지 않는) 응집성을 생성해 낸다.

위에서 Ambiguity는 모호성이 아니라, 다중성 즉 다양한 성격을 가지게 만들라는 의미입니다. 확정성을 고려하라는 것이지요. 어려운 얘기입니다. 깊게 응집성을 가지면서도, 확장성을 가져야 된다는 의미입니다. 우리가 알고 있는 응집력은 높이고, 결합도는  낮추라는 격언과 일치합니다.

Rebecca는 “두 시스템의 Context를 파악하고, 이 시스템의  잘 감 쌀 수 있는 균형잡힌  Inteface 영역을 어디에 둘거냐?”에 초점을 맞추라고 했습니다.   거대한 시스템은 개발과 유지보수를 간단히 하기 위해 잘 모듈화 되어 있어야 합니다. 모듈은 또한 Tighting Coupling을 피하면서, 시스템의 goal을 달성할 수 있게 응집력있게 구성되어야 합니다.   이 원칙 또한 위에서 언급한 Boundaries와 깊은 연관성을 가지는데. 시스템의 part (부분 요소)간에 경계들이 어떻게 서로 상호작용하는지 정의하는데 초점을 맞추고 있습니다.

Rebecca는 우리 소프트웨어에서 어떻게 상호작용을 해야 되는지 가이드라인을 제공해 주었습니다.

• Collaboration between roles – 먼저 Role을구성하고, Role(Responsibility)간에 어떻게 Collaboration하는지를 고려해라!    POSA1 서적에 보면 패턴마다 CRC 가 있습니다. 서로간에 Responsilbity(Role)을 기술하고, 연관되는 요소를  기술하게 되어 있죠.  Xper의 Rebecca 인터뷰에서 나온 것처럼  Rebecca가 CRC를 즐겨쓰는 방법이랍니다.
• Interface and Contract Definition – 그후 Interface와 Contract를 정의해 어떻게 계약을 할지 정의해라.  Role(Responsibility) 기준으로 (객체, 모듈, 레이어 등..) 나누게 되고, 그 성격에 따라 Interface와 Contract(주고 받아야 하는 데이터 , 선행조건)등을 기술해야 합니다.
• Dynamic clients-supplier relationship – 동적으로 Client/Supplier관계를 가지는 것을 파악하고 다룰 방안을 고려해라.

또 다른 저의 경험으로는 Bottom Up 으로 가든, Top Down으로 가든, 아키텍쳐 레벨에서는 굉장히 추상적인 방식(Protocol 또는 Message 전달 )으로 통신하게 만들고, 디자인 레벨과 구현 레벨에서도 확장 가능한 형태로 Parameter Object 나 DTO 와 같은 것들을 이용해서 변화의 전파 즉 확장성을 가질수 잇는 형태로 가져가는게 바람직합니다.

여기서 추가적으로 더 고려해야 하는 것은 소프트웨어 전체가 recompile없이 쉽게 확장, 추가 할수 있게 물리적인 단위 (dll 등..)로 나누는 것도 중요합니다.  제가 아는 뭐 회사는, 소프트웨어 설계는 잘했지만, 물리적으로 나누지 않아, 전체를 컴파일을 하는 상황도 보았기 때문입니다.

또한 이 원칙과 굉장히 깊은 연관서잉 있는 Post가 있습니다.  Microsoft 수석 프로그래머인 Einar Landre가 작성한 “아키텍트의 초점은 경계와 인터페이스에 있다“를 보시길 바랍니다.  이러한 경계를 잘 정하기 위해 DDD에서 언급한 Context Map을 통해 객체의 Role과 Interface를 정하는 방법을  제안합니다.

NOO 를 정리하면서..

현재 Nature of Order 서적을 전혀 읽지 않고, Rebecca의 강의를 시작으로 여러자료를 찾아보면서 정리했습니다. 아마도 NOO를 읽으신 분들이 더 정확한 관점을 말씀해 주실수 있을거 같네요.

일단 제가 Rebecca의 강의를 들은 한도 내에서, 그리고 제가 이와 비슷한 케이스를 경험한 측면 내에서 한번 정의해 보겠습니다. 물론 2년후에 얼굴이 화들짝할만큼. 부족한 생각으로 쓴 글이 될수도 있지만, 그렇다고 2년동안 묵혀 둘수도 없잖아요.. 물론 안티가 양성될수 있겠지만요. 🙂

Rebecca의 강의 (주) + NOO를 Software 빛댄 몇몇 논문들 + Xper 에서 NOO에 대해 돌아다니는 이야기들을 읽고 조율해 보았습니다.  부디 이 글이 다른 분에게 설계에 대한 새로운 관점을 전달해 주고, 저 역시 저의 부족한 부분을 피드백을 받아 좀더 성장하는 계기가 되었으면 합니다.