대규모 구조

대규모 구조

권욱진

대규모 구조

• 모델 내의 복잡한 관계를 명확하게 하기 응집력 있는 모듈로 분해 => 굉장히 많은 모듈이 생김

• MODULAR 을 중심으로 분해하더라도 큰 모델은 파악하기에 너무 복잡함

• BOUNDED CONTEXT 에 의한 엄격한 분리역시 시스템이 전체적으로 보기 쉬워지는 것은 아님

대규모 구조

• 큰 시스템에 해당 시스템의 요소를 전체 설계에 걸친 지배적인 원칙이 없다면 개발자들은 나무만 보고 숲을 보지 못함

• 대규모 구조는 넓은 시각으로 시스템에 관해 토의하고 이해하게끔 돕는 언어이다 .

• 각 부분의 책임을 자세히 알지 못해도 전체적인 관점에서 해당 부분의 위치를 어느 정도 이해하는 데 도움을 주는 규칙 필요

대규모 구조에서의 패턴• EVOLVING ORDER ( 발전하는 질서 )

• SYSTEM METAPHOR ( 시스템 은유 )

• RESPONSIBILTY LAYER ( 책임 계층 )

• KNOWLEDGE LEVEL ( 지식수준 )

• PLUGGABLE COMPONENT FRAMEWORK

EVOLVING ORDER ( 발전하는 질서 )

• 구조화 되지 않은 설계 ? 비용이 많이 발생

• 혼란을 피하기 위한 아키텍처를 부과

• 아키텍처는 기술적 문제는 해결할 수 있지만 도메인 모델의 단계에서는 아키텍처만의 문제가 발생

• 아무나 설계 할 수 있다면 누구도 전체적으로 이해할 수 없는 시스템이 만들어짐 => 유지보수하기가 매우 어려움

EVOLVING ORDER ( 발전하는 질서 )

• 아키텍처는 사전 설계와 관련한 가정을 둠으로써 프로젝트를 속박할 수 있고 , 애플리케이션의 특정 부분에 대해 개발자 / 설계자의 권한을 너무 많이 앗아 갈 수 있음

• 개념적인 대규모 구조가 애플리케이션과 함께 발전하게 해서 발전 과정에서 전혀 다른 형식의 구조로도 변화할 수 있게 하라 .

• 반드시 세부적인 지식을 토대로 내려야 할 세부적인 설계 및 모델과 관련된 의사결정을 과도하게 제약해서는 안 된다 .

SYSTEM METAPHOR ( 시스템 은유 )

• 은유 ? 전체 시스템 개발에 질서를 부여한다는 방법을 의미

• 소프트웨어 설계는 매우 추상적이고 파악하기 힘든 경향이 있다 .

• 개발자와 사용자 모두 시스템을 이해하고 시스템을 전체적으로 바라보는 시각을 공유할 구체적인 수단 필요

• 어떤 시스템의 구체적인 비유가 나타나 팀원의 상상력을 포착하고 유용한 방향으로 사고를 이끄는 것으로 보인다면 그것을 대규모 구조로 채택하라 .

SYSTEM METAPHOR ( 시스템 은유 )

• 모든 은유는 부정확하므로 지속적으로 은유가 지나치거나 적절치 못한가를 재점검하고 방해가 된다면 언제든 버릴 준비를 한다 .

• 미숙한 은유 ? 도메인 모델 자체를 의미

• BUT 성숙한 도메인 모델은 미숙하지 않음 !

RESPONSIBILITY LAYER( 책임 계층 )

• 각 개별 객체에 손수 만든 책임이 할당돼 있다면 가이드라인도 없고 , 균일함도 없고 , 넓은 범위에 걸친 도메인을 동시에 다룰 능력도 없음

• 큰 모델에 응집력을 부여하려면 그러한 책임할당에 특정 구조를 도입하는 것이 도움이 됨

• 모델에 존재하는 개념적 의존성과 도메인의 여러 부분에 대한 다양한 변화율과 변화의 근원을 검토하라

• 도메인에서 자연적인 층을 식별하면 그것을 광범위한 추상적 책임으로 간주하라 .

• 이러한 책임은 시스템의 높은 수준에서의 목적과 설계에 관한 이야기를 들려줄 것이다 .


그림 16-3


그림 16-6


그림 16-7


그림 16-8


그림 16-11

KNOWLEDGE LEVEL( 지식 수준 )

• KNOWLEDGE LEVEL( 지식수준 ) 은 더 넓은 범위의 규칙으로 제약되기 전까지 모델의 특정 부분을 사용자의 손에 맡겨야 할 때 생기는 문제를 해결한다 .


그림 16-15


그림 16-17


그림 16-19


• 기본적인 모델의 구조와 행위를 서술하고 제약하는 데 쓸 수 있는 별도의 객체 집합을 만들어라 .

• 이러한 관심사를 두 가지 “수준”으로 분리해서 하나는 매우 구체적으로 만들고 다른 하나는 사용자나 관리자의 맞춤화가 가능한 규칙과 지식을 반영하게 만들어라 .


그림 16-21


그림 16-22

PLUGGABLE COMPONENT FRAME-WORK

• 인터페이스와 상호작용에 대한 ABSTRACT CORE 를 정제하고 그러한 인터페이스의 다양한 구현이 자유롭게 대체될 수 있는 프레임워크를 만들어라

• 컴포넌트가 ABSTRACT CORE 의 인터페이스를 통해 정확히 작동하는 한 어떠한 어플리케이션에서도 그런 컴포넌트를 사용할 수 있게하라 .

구조는 얼마나 제약성을 지녀야 하는가 ?

• 제약적인 구조는 단일성을 증대시켜 설계를 더 쉽게 해석할 수 있게 함

• 반면 제약은 개발자가 필요로 하는 유연함을 앗아 갈 수 있다 .

• 따라서 프레임워크를 만들고 대규모 구조의 구현을 엄격히 통제하고자 하는 유혹을 이겨내야 한다 .

• 대규모 구조가 공헌하는 가장 중요한 바는 개념적 응집성과 도메인에 대한 통찰력을 주는 것이다 .

잘 맞아 떨어지는 구조를 향한 리팩터링

• 최소 주의- 비용을 낮게 유지하는 방법 ? 구조를 간단히 유지- 초반에는 시스템은유나 책임계층같은 느슨한구조

• 의사소통과 자기 훈련 - 팀 전체는 새로운 개발과 리팩터링을 할 때 반드시 구조를 따른다 . - 대부분의 대규모 구조가 느슨한 개념적 지침이라 팀은 반드시 자

기 훈련을 수행해야 한다 .

대규모 구조

Documents