Category Archives: .NET Application Architecture Guide

CHAPTER 4: A TECHNIQUE FOR ARCHITECTURE AND DESIGN(3)


CHAPTER 4: A TECHNIQUE FOR ARCHITECTURE AND DESIGN(2)에 이어서

Application Overview

당신의 어플리케이션이 완성될 때 어떤 모습을 하게 될지 개요를 작성하라. 이런 개요는 아키텍처를 더욱 tangible하게 만들고 실재 세계의 제약과 결정들과 연관 지어준다. 어플리케이션 개요는 다음의 활동들로 구성된다:

  1. 어플리케이션 타입을 결정하라. 첫째로, 구축하는 어플리케이션의 타입을 결정하라. 그것은 모바일 어플리케이션인가? 리치 클라이언트, 리치 인터넷 어플리케이션, 서비스, 웹 어플리케이션, 혹은 이런 타입들의 조합인가? 공통 어플리케이션 archetype의 자세한 내용은 see Chapter 20 “Choosing an Application Type.”
  2. deployment 제약사항을 식별하라. 어플리케이션 아키텍처를 설계하려고 할 때, 어플리케이션을 deploy하려는 계획 위에서 인프라와 함께 corporate 정책이나 절차를 고려해야 한다. 만약 대상 환경이 고정되어 있거나 융통성이 없는 경우, 어플리케이션은 그런 환경에 존재하는 제약사항을 반영해야만 한다. 어플리케이션 설계는 보안이나 신뢰성 같은 서비스의 품질(QoS) 속성을 고려해야만 한다. 때때로 당신은 프로토콜 제약사항과 네트워크 토폴로지 사이에서 설계 트레이드오프를 해야 한다. 설계 프로세스의 초기에 어플리케이션 아키텍처와 인프라 아키텍처 사이에 존재하는 요구사항과 제약사항을 식별함으로써, 당신은 적절한 deployment 토폴로지를 선택할 수 있고 어플리케이션과 대상 인프라 사이의 모순을 해결할 수 있다. For more information about deployment scenarios, see Chapter 19 “Physical Tiers and Deployment.”
  3. 중요한 아키텍처 설계 스타일을 식별하라. 어떤 아키텍처 스타일을 당신의 설계에서 사용할 것인지를 결정하라. 아키텍처 스타일은 원칙의 집합이다. 당신은 그것을 시스템의 패밀리를 위한 추상화된 프레임워크를 제공하는 coarse-grained pattern으로 생각할 수도 있다. 각각의 스타일은 (1) 시스템을 조합, (2) 그들이 조립되는 방법에 대한 제약사항, (3) 그들이 어떻게 함께 묶일 것인지의 의미에 대한 가정할 수 있도록 사용할 수 있는 컴포넌트들의 종류들로 명세하는 규칙들을 정의한다. 아키텍처 스타일은 자주 되풀이되는 문제들에 대한 해결책을 제시함으로써 파티셔닝과 설계 재사용을 증진한다. 흔한 아키텍쳐 스타일은 Service Oriented Architecture (SOA), client/server, layered, message-bus, and domain-driven design이다. 어플리케이션은 스타일의 조합을 사용한다. For more information about the architectural styles in common use today, see Chapter 3 “Architectural Patterns and Styles.”
  4. 관련된 기술을 결정하라. 마지막으로, 당신의 어플리케이션 타입과 제약사항을 기반으로 관련 기술을 식별하고 어떤 기술을 당신의 설계에서 사용할 것인지를 결정하라. 고려해야 하는 핵심 요소들은 당신이 개발하고 있는 어플리케이션의 타입이고, 당신이 선호하는 어플리케이션 deployment 토폴로지에 대한 옵션이고 아키텍처적 스타일이다. 기술들의 선택은 조직적 정책, 인프라 제한, 리소스 스킬 등에 의해 제약된다. 다음의 섹션은 어플리케이션의 각각의 타입에 대한 흔한 마이크로소프트 기술을 기술한다.(이하 skip)

Whiteboard Your Architecture

설계

Key Issues

이슈사항에 대한 질의 및 해결

Quality Attributes

Crosscutting Concerns

Designing for Issue Mitigation

Candidate Solutions

Reviewing Your Architecture

Advertisements

CHAPTER 4: A TECHNIQUE FOR ARCHITECTURE AND DESIGN(2)


CHAPTER 4: A TECHNIQUE FOR ARCHITECTURE AND DESIGN(1)에 이어서

Identify Architecture Objectives

아키텍처 목표는 (1) 당신의 아키텍처와 설계 프로세스를 형성하는 목표와 제약조건이고 (2) exercise의 범위를 정하는 것이고 (3) 당신이 끝났을 때 당신이 결정하는 것을 돕는 것이다. 당신의 아키텍처 목표들을 식별하려고 할 때 다음의 핵심사항들을 고려하라.

  • 처음에 당신의 아키텍처 목표를 식별하라. 당신이 아키텍처 및 설계의 각각의 단계에서 소비하는 시간의 양은 이 목표들에 의존적일 것이다. 예를 들어 당신은 신규 어플리케이션을 위해 프로토타입을 만들고, 잠재적 경로를 시험하고, 혹은 오랫동안 동작하는 아키텍처적 프로세스를 착수하는가?
  • 누가 당신의 아키텍처를 사용할 것인지를 식별하라. 당신의 설계가 다른 아키텍트에 의해 사용될 것인지, 혹은 개발자나 테스터, 운영 스탭, 관리에게 사용 가능하도록 만들어질 것인지를 결정하라.
  • 당신의 제약사항을 식별하라. 당신의 기술적 옵션들과 제약사항, 사용 제약사항, deployment제약사항을 이해하라. 처음에 당신의 제약사항을 이해하여 시간을 낭비하지 않도록 하거나 나중에 어플리케이션 개발 프로세스의 뒤 부분에서 돌발상황을 마주치지 않도록 하라.

Scope and Time

당신의 아키텍처에 대한 고 수준 목표를 기반으로 하여, 당신의 설계 활동의 각각에 대한 소비해야 하는 시간의 양의 범위를 정할 수 있다. 예를 들면, prototype은 설계하기 위해 며칠이 필요한 반면, 복잡한 어플리케이션에 대한 완전하고 상세한 아키텍처는 수 개월이 걸릴 것이다.- 그리고 수 차례 반복하는 아키텍처 및 설계를 포함할 것이다. (1) 얼마나 많은 시간과 에너지를 각각의 스텝에서 소비할 것인지를 결정하기 위해 (2) 결과가 어떻게 보일지 이해하기 위해, (3) 당신의 아키텍처에서 목적과 우선순위를 명확하게 정의하기 위해 목표를 잘 이해하라.

가능한 제안들은 다음을 포함할 수 있다:

  • 완전한 어플리케이션 설계를 생성하기
  • 프로토타입을 구축하기
  • 핵심적인 기술적 리스크를 식별하기
  • 잠재적 옵션들을 시험하기
  • 시스템의 이해를 획득하기 위한 공유모델들을 구축하기

이들 각각은 설계의 다른 부분들을 강조한 결과들이고 시간에 따라 다를 수 있다. 예를 들어 만약 당신이 인증(authentication)아키텍처에서 핵심적인 리스크를 식별하길 원한다면, 많은 시간과 에너지를 들여서 인증 시나리오, 당신의 인증 아키텍처의 제약사항, 그리고 가능한 인증 기술 선택들을 식별하려고 할 것이다. 하지만, 당신이 만약 어플리케이션의 초기 단계에서 있다면, 인증은 여러 가지 해결해야 하는 것들 중에 하나일 것이다.

아키텍처 활동들의 몇몇 사례는 웹 어플리케이션을 위한 order processing UI의 피드백을 얻기 위해 프로토타입을 구축하거나 결과들을 검색하기 위해 위치 정보를 매핑하는 다른 방법으로의 시험, 보안 검토를 수행하기 위한 어플리케이션에 대한 인증 설계 및 인증 아키텍처 등이 있을 수 있다.

Key Scenarios

아키텍처와 설계의 맥락에서, 유즈 케이스는 시스템과 하나 이상의 액터(유저 혹은 다른 시스템)간의 일련의 상호작용의 기술이다. 시나리오는 유즈케이스를 통한 경로라기 보다는 광범위하고 보다 확장적인 시스템 내의 사용자의 상호작용에 대한 기술이다. 시스템의 아키텍처에 대해 생각할 때 목표는 당신의 아키텍처에 대한 결정을 내리는데 도움이 되는 몇가지 핵심 시나리오를 식별하는 거이 되어야 한다. 목표는 사용자, 비즈니스, 시스템 목표(1장 그림1에 보인 바와 같이 “아키텍처는 무엇인가?)간에 균형을 달성하는 것이다.

핵심 시나리오는 당신의 어플리케이션의 성공을 위한 가장 중요한 요소이다. 핵심 시나리오는 1개 혹은 그 이상의 다음의 기준을 만족시키는 시나리오로 정의될 수 있다.

  • 이슈를 표현한다. – 중요한 미지의 영역 혹은 중요한 리스크 영역
  • 아키텍처적으로 중요한 유즈케이스를 언급한다(다음에 이어지는 섹션에 기술됨)
  • 품질 속성과 기능이 서로 상충되는 부분을 표현한다.
  • 품질 속성간의 tradeoff를 표현한다.

예를 들어서, 사용자 인증을 커버하는 당신의 시나리오가 핵심적 시나리오가 될 수 있는데, 그 이유는 품질 속성(보안)과 중요한 기능(어떻게 유저가 시스템 내부에 로그를 남길 것인가)과 상충되기 때문이다. 또 다른 예는 익숙하지 않거나 새로운 기술이 중심이 된 시나리오가 될 수 있다.

Architecturally Significant Use Cases

아키텍처적으로 중요한 유즈케이스는 당신의 설계에 여러가지 관점에서 영향을 미친다. 이러한 유즈케이스들은 특별히 당신의 어플리케이션의 성공을 결정짓는데 중요하다. deploy된 어플리케이션의 인수를 위한 중요한 것들이 있으며 아키텍처를 평가하는데 유용한 설계의 충분함을 평가하는 것들이 있다. 아키텍처적으로 중요한 유즈케이스들은:

  • 비즈니스에 중요함. 유즈케이스는 높은 사용 수준이거나 다른 기능들과 비교했을 때 부분적으로 사용자 혹은 이해관계자에게 중요하며 그렇지 않으면 높은 리스크를 초래한다.
  • 중대한 영향. 유즈케이스는 기능 및 품질 속성을 intersect하거나 계층을 넘어 당신의 어플리케이션의 tier까지 end-to-end 영향을 가진다. 사례가 보안에 민감한 CRUD가 될 것이다.

당신의 어플리케이션을 위한 아키텍처적으로 중요한 유즈케이스를 선택한 후에, 당신은 그것들을 아키텍처의 후보의 성공 혹은 실패를 평가하기 위한 수단으로 사용할 수 있다. 만약 그 후보들이 더 많은 유즈케이스를 나타내거나 기존의 유즈케이스가 더욱 효과적이 되도록 한다면, 그것은 후보 아키텍처가 베이스라인 아키텍처보다 더 나음을 보여주는데 도움이 될 수 있다. 유즈케이스의 용어에 대한 정의는 아래 site에서 “what is use case?”를 참조한다. http://searchsoftwarequality.techtarget.com/sDefinition/0,,sid92_gci334062,00.html

좋은 유즈케이스는 아키텍처의 사용과 뷰, 시스템 뷰, 비즈니스 뷰를 포함한다. 당신의 설계를 시험하기 위한 이런 시나리오들과 유즈케이스를 사용하여 어디세 이슈들이 존재하는지를 결정하라. 당신의 유즈케이스와 시나리오에 대해 생각할 때 다음의 사항들을 고려하라.

  • 프로젝트 초반에 아키텍처의 모든 계층을 exercise하는 아키텍처적으로 중요한 end-to-end시나리오를 지원하는 후보 아키텍처를 생성함으로써 risk를 줄여라.
  • 당신의 아키텍처 모델을 가이드로서 사용하고 아키텍처, 설계, 코드가 당신의 시나리오, 기능 요구사항, 기술적 요구사항, 품질 속성, 제약사항에 맞도록 변경하라.
  • 그 시점에 당신이 알고있는 것을 기반으로 아키텍처 모델을 생성하고 이후의 스토리와 이터레이션에서 해결되어야만 하는 질문들의 리스트를 정의하라.
  • 아키텍처와 설계에서 충분히 중요한 변화들을 만든 이후, 이러한 변화를 반영하고 exercise할 수 있는 유즈케이스를 생성하는 것을 고려하라.

Chapter 4: A Technique for Architecture and Design(1)


Overview

이 장은 당신의 향후 아키텍처에 대해서 고민하고 스케치할 수 있도록 하기 위한 반복적인 기법에 대해서 기술한다. 이 장은 또한 당신이 이 가이드에서 논의하는 핵심 결정사항(품질 속성, 아키텍처 스타일, 어플리케이션 타입, 기술, 배치(deployment) 결정)에 대해서 알려줄 것이다.

그 기술은 연속적인 5개의 단계를 포함하며, 각각은 이 가이드의 나머지에서 충분히 설명된 개별 고려사항으로 쪼개진다. 이런 반복적인 프로세스는 단계를 반복함으로써 더욱 개선될 수 있는 잠재 솔루션을 만드는 것을 도울 수 있다. 프로세스의 마지막 부분에서 당신은 모든 관련된 영역들에 대한 당신의 아키텍처에 대해 검토하고 의사소통 할 수 있다.

소프트웨어 개발에 대한 조직의 접근법에 의존적으로, 당신은 제품이 개발되고 있는 동안 여러 번 당신의 아키텍처를 들여다볼 것이다. 당신은 이런 기술을 사용하여 당신의 아키텍처를 개선할 수 있고, 스파이킹(spiking), 프로토타이핑, 그리고 실제 개발의 주기에서 배웠던 것을 구축할 수 있다.

이것은 단지 가능한 한가지의 접근법이라는 것을 아는 것도 또한 중요하다. 당신의 아키텍처를 정의하기, 검토하기, 의사소통하기 위한 여러 가지 형식적 접근법이 있다. 몇몇은 이 장의 마지막에서 간단하게 논의할 것이다.

Inputs, Outputs, and Design Steps

당신의 설계의 입력은 요구사항 및 당신의 아키텍처가 제공해야 하는 제약사항을 형식화하는 것을 도울 수 있다. 공통 입력은 유즈 케이스와 사용 시나리오, 기능 요구사항, 비기능 요구사항(성능, 보안, 신뢰성, 기타 등과 같은), 기술적 요구사항, 타겟 배치 환경, 다른 제약사항들이다.

설계 프로세스 동안, 당신은 아키텍처적으로 중요한 유즈 케이스, 특별한 주의를 요구하는 아키텍처적 이슈, 그리고 요구사항과 설계 프로세스상에 정의된 제약 조건을 만족시키는 아키텍처 솔루션들의 후보들을 생성할 것이다. 설계가 모든 요구사항을 만족시키고 모든 제약조건에 부합하도록 할 때까지 시간이 지나면서 설계를 개선하는 공통적인 기술은 그림 1과 같이 5개의 중요한 단계로 구성된 반복 기법이다.

그림1. 핵심 아키텍처 설계 활동을 위한 반복 단계

다음의 섹션에서 각 단계들을 자세히 설명하도록 한다.

  1. 아키텍처 목표를 식별한다. 명확한 목표는 당신의 아키텍처에 집중하고 설계에서 올바른 문제를 해결하는데 도움이 된다. 간단한 목표는 당신이 현재 단계에서 완료 및 다음 단계로 나아가는 것을 결정하는데 도움이 된다.
  2. 핵심 시나리오. 무엇이 가장 중요한지 당신의 설계에서 집중하고 후보 아키텍처들이 준비되었을 때 평가하기 위해 핵심 시나리오를 사용하라.
  3. 어플리케이션 개요. 당신의 어플리케이션 타입, 디플로이먼트 아키텍처, 아키텍처 스타일, 기술들을 식별하여 당신의 설계가 어플리케이션이 동작하는 실제 세계에서 연결할 수 있도록 하라.
  4. 핵심 이슈. 품질 속성과 crosscutting concerns를 기반으로 한 핵심 이슈들을 식별하라. 이들은 어플리케이션을 설계할 때 가장 많이 하는 실수하는 영역들이다.
  5. 솔루션 후보. 솔루션을 진화시키고 개선시킬 수 있는 spike나 prototype 아키텍처를 생성하고 당신의 아키텍처의 다음 반복이 시작되기 전에 당신의 핵심 시나리오, 이슈, deployment제약사항에 대해서 평가하라

이러한 아키텍처적인 프로세스는 반복적이고 증가적인(iterative and incremental)접근법이다. 당신의 첫 번째 후보 아키텍처는 핵심 시나리오, 설계, 알려진 제약사항, 품질 속성, 아키텍처 프레임에 대해 테스트할 수 있는 고 수준의 설계가 될 것이다. 당신이 후보 아키텍처를 정제할 때마다 당신은 설계에 대한 보다 상세한 것을 배우게 될 것이고 핵심 시나리오, 어플리케이션 개요, 이슈들에 대한 당신의 접근법에 대한 보다 심도 있는 확장을 할 수 있을 것이다.

Note.

아키텍처에 대한 반복적 접근법에 대해 논의할 때, 그것은 종종 사용자를 위한 완성된 기능(유즈 케이스)을 구성하는 계층을 넘는 기능성에 대한 고려를 요구하는 수직적 슬라이스보다 수평적 슬라이스(layer)로 반복하려고 하기도 한다. 만약 당신이 수직적으로 반복하는 것을 실패한다면, 당신의 사용자들이 그것을 validate하기 전에 여러 가지 기능의 구현에 대한 리스크를 떠안게 될 것이다.

아키텍처에 대한 반복적 접근법에서 수평적 계층 구조(layered architecture)를 기반으로 하여 설계를 하지 말라는 의미이다. 그렇다고 Layered architecture를 하지 말라는 뜻은 아님. 그렇다고 Layered architecture를 언제 하라고 얘기하는 것도 아니지만..:-)

당신은 1회 반복으로 당신의 아키텍처를 완성하려고 해서는 안 된다. 각각의 반복에서 보다 상세화가 추가되어야 한다. 상세화하면서 길을 잃어버리지 말고 major step에 집중하고 당신의 아키텍처와 설계를 토대에서 프레임워크를 구축하라. 다음의 섹션은 각각의 step에 대한 가이드라인과 정보를 제공한다.