들어 가기에 이번 장에서는 앞서 이론적인 소프트웨어 아키텍처에 대한 지식을 기반으로 실제로 소프트웨어 아키텍처를 설계하는 방법에 대해 살펴보겠습니다.
엔터프라이즈 시스템을 구축한다는 것은 간단한 프로그램을 작성하는 것과는 전혀 다른일입니다. 일관되고 체계적인 프로세스를 통해서 견고한 아키텍쳐를 정립한 후에야 성공적이며 효율적인 엔터프라이즈 시스템을 개발할 수 있게됩니다. 이것을 위해서는 소프트웨어 공학적인 지식이 풍부한 개발 경험을 가진 아키텍트가 필요합니다. 이번에는 아키텍트가 수행해야하는 여러 작업들을 살펴보겠습니다. 그리고 최종 목표는 엔터프라이즈 시스템을 위한 견고한 소프트웨어 아키텍처를 정의하는 것입니다.
소프트웨어 아키텍처란 소프트웨어 요소와 이들 요소의 외부 속성 그리고 이들 사이의 관계구성하는 시스템의 구조입니다.
비즈니스 아키텍처는 사용자의 요구사항, 기능적인 요구사항을 유스케이스 다이어그램으로 표현합니다. 앞장에서 실행한 내용입니다.
나머지 애플리케이션,기술, 데이터 악키텍처는 기능 및 비기능적인 사용자 요구사항을 표현합니다.
자세한 내용은 뒤에 보겠습니다.
시스템의 소프트웨어 아키텍처를 설계하기 위해서는 사전 준비작업이 필요한데 그 사전 준비작업은 초기 아키텍처 개요를 정의하는 활동이며 두 번째는 행위분석 활동입니다.
초기 아키텍처 개요 정의는 사용자의 비기능적인 요구사항으로부터 품질 속성을 실현할 수 있는 전략을 수립하여 가장 실현 가능한 초기 아키텍처 개요를 정의합니다. 이때 생성된 초기 아키텍처 개요는 이후 아키텍처 설계를 위한 모든 과정의 기초가 됩니다. 또한 초기에 수립된 아키텍처의 세부적인 사항은 언제든지 변경가능합니다.
행위분석활동에서의 주요작업중 하나가 유스케이스 분석입니다. 시퀀스 다이어그램으로 표현되는 유스케이스,즉 시스템이 행하는 행위를 분석하고 실행하는 것입니다.
이러한 과정 속에서 우리는 분석 클래스라고 하는 개념적인 소프트웨어 요소를 찾아내게 되며, 유스케이스 실현은 이들 개념적인 소프트웨어 요소들이 어떻게 서로 상호작용하는지 방법을 표현함으로써 유스케이스의 목적을 달성합니다.
애플리케이션 아키텍처 설계는 주로 사용자의 기능적인 요구사항을 실현하는 비즈니스 컴포넌트에 초점을 맞춤니다.
비즈니스 컴포넌트와 이들 사이의 상호작용이란 관점에서 시스템의 구조를 논리 뷰로 표현하고, 비즈니스 컴포넌트에서 사용자 인터페이스와 관련된 부분을 분리하여 인터페이스 뷰로 표현합니다, 논리적인 비즈니스 컴포넌트를 구현하는 물리적인 소프트웨어 모듈의 구조를 구현 뷰로 표현합니다. 구현 뷰를 제외한 논리 뷰와 인터페이스 뷰를 아키텍처 정의 단계에서 정의합니다.
애플리케이션 아키텍처 설계는 유스케이스 실현의 결과를 환용하는 가장 중요한 활동입니다.
기술 아키텍처 설계는 사용자의 비기능적인 요구사항, 그 중에서도 특히 기술적인 요구사항을 실현하는 방법에 초점을 맞춘다. 기술 아키텍처는 전적으로 기술적인 요구사항을 해결하는데 집중해야 합니다.
기술 아키텍처에는 유스케이스 다이어그램과 클래스다이어그램 기술 유스케이스 뷰를 포함합니다
또한 물리적 노드의 구성과 상호 연결 관계 보여주는 배포다이어그램 과 배포다이어그램으로 표현되는 배포 뷰를 포함합니다
데이터 아키텍처 설계 (정규화 : 데이터를 일정한 규칙에 따라 변형하여 이용하기 쉽게 만드는 것)
유스케이스의 실현의 결과를 활용하는 두번 째 활동입니다. 비즈니스 객체를 도출하고, 비즈니스 객체 모델을 생성한다. 정규화 과정을 수행하여 논리 데이터 모델을 구성하고 데이터베이스 설계활동에서 이들 비즈니스 객체 중에서 지속성 처리를 요구하는 객체를 대상으로 정규화 과정을 수행하여 논리 데이터 모델을 구성합니다.
설계 전략 정의와 아키텍처 프로토 타이핑
아키텍처 설계 완료되면 해당 아키텍처를 기반으로 설계 단계에서 실계자가 템플릿으로 사용할 설계 메커니즘과 구현 단계에서 개발자가 사용하게 될 구현 메커니즘을 정의합니다. 여기서 정의되는 것으로 설계자와 개발자들이 자신의 작업을 수행하는데 있어서 제약사항으로 작용된다.
결국 정의된 아키텍처와 구현 메커니즘에 기술된 제약사항의 범위안에서 설계하고 코드를 작성해야하는 것입니다.
아키텍처 정의의 마지막 단계는 아키텍처 프로토타이핑 아키텍트 구룹에서 가장 위험요소가 많고 우선 순위가 높은 유스케이스를 선택하여 실제로 아키텍처와 설계 및 구현 메커니즘에 따라 설계 구현 테스트 과정을 실행함으로써 설계된 아키텍처가 견고한지를 검증하고 이 결과는 다시 아키텍처 설계에 반영된다. 최종적으로 견고함이 검증되면 설계자와 개발자에게 제시하게 된다.
이 활동은 첫 번째 사전 활동으로서, 요구 파악단계에서 도출된 사용자 비기능 요구사항으로부터 품질 속성을 도출하고 우선 순위를 결정하며, 도출된 품질 속성을 실현할 수 있는 전략을 수립하여 가장 실현 가능한 초기 아키텍쳐 개요를 정의하는 작업입니다.
초기 아키텍처 모델 정의
이 작업에서 생성된 초기 아키텍처는 이후 아키텍처 설계를 위한 모든 과정의 기반이 됩니다. 예를들면 유스케이스 분석 작업에서 유스케이스 실현에 참여하게 된 분석 클래스를 식별하는 기준이 됩니다.그러나 이후 아키텍처 설계 과정에서 초기에 수립된 아키텍처의 세부적인 사항이 변경될 수 있으며 따라서 초기 아키텍처 정의 작업에서는 아직 아키텍처가 확정되는 것은 아닙니다..
참고 ATAM 기법을 활용한 아키텍처 정의 (Architecture Tradoff Analysis Methodd)
9단계 과정으로 아키텍처를 평가하는 방법이지만 약간 변형하여 정의 할수도 있다.
-아키텍처 접근 방법(아키텍처 스타일)식별
품질 속성 유틸리티 트리 생성
-품질 속성 시나리오를 도출하고 우선 순위를 결정
아키텍처 접근 방법(아키텍처 스타일)분석
-품질 속성을 기준으로 후보 아키텍처를 평가한다.
아키텍처 선정
ATAM 기법은 아키텍트 시간으로 시스템을 바라볼 수 있게 하는 좋은 길잡이가 되어 줄 것이다.
초기 아키텍처 정의를 위해 가장 처음 할 일은 사용자의 비기능적인 요구사항으로부터 품질 속성을 도출하고, 품질 속성에 대하여 수선 순위를 부여하는 것입니다. 0~10 점까지 점수를 매기거나, 상 중 하와 같은 상대적 순위로 걸정할 수 있습니다.
위의 설명은 고려사항입니다.
각 품질 속성에 대한 기본적인 아키텍처 전략을 세울때는 애플리케이션 아키텍처 뿐만 아니라, 기술 아키텍처와 하드웨어 구성, 구현 등을 종합적으로 고려하며, 아키텍처 스타일이나 아키텍처 패턴등을 참조해야 합니다.
유의 할 점은 도출된 모든 품질 속성 요구사항을 만족시킬 수 있는 아키텍처 전략을 수립하기는 거의 불가능는것인데, 각 품질 속성의 요구사항이 서로 충돌할 수도 있기때문입니다. 예를들면 변강 가능 품질 속성의 요구사항을 실현하기 위해 레이어 아키텍처 스타일을 사용할 때입니다. 사용자의 요청을 처리하기 위해 여러 레이어를 거쳐야 한다면 아무래도 성능에 지장은 주기 때문이죠.
변경 가능성 품질 속성의 요구사항을 배송 서비스를 손쉽게 변경 할 수 있게 해달라일 때의 전략입니다. 가용성은 성능의 변화없이 시스템의 기능을 확장에 대한 전략입니다.
일반적으로 엔터프라이즈 시스템은 여러 추상화 단계를 갖는 많은 컴포넌트로구성된다.
따라서 일반적으로 엔터프라이즈 시스템에 요구되는 관리성, 재사용성, 확장성, 강건성, 보안등의 요구사항을 지원하도록 컴포넌트를 구조화할 필요가 있다.
이러한 목적으로 가장 많이 사용되는 것이 레이어 아키텍처 스타일이다.
레이어 사이의 상호작용 방식
하향식
시스템의 외부에서는 가장 상위에 레이어와 상호작용한다. 최상위 레벨으 ㅣ레이어는 하위 레벨의 레이어가 제공하는 서비스를 사용하고 다시 각 하우 ㅣ레벨의 레이어는 그밑의 하위 레벨의 레이어가 제공하는 서비스를 이용한다. 이런 방식으로 최하위 레벨의 레이어로 내려갈 때 까지 계속된다.
상향식은
하샹식과 정반대 그러나 레이어 사이에 상호작용 방식이 조금 다르다. 상위 레이어가 하위 레이어 호출하지만 하위 레이어는 직접 호출하지 못한다. 대신 하위 레이어는 이벤트나 콜백 delegate 등을 통해서 상위 레이어와 커뮤니케이션을 해야 한다. 그러나 상향식은 상위레이어에 대하여 종속적인 상태가 되게 하므로 레이어 아키텍쳐를 사용하는 이점을 반감시키므로 가능한 상향식 모드를 사용하지 않는 것이 바람직하다.
논리적인 레이어는 물리적인 티어에 분산 배포된다.엔터프라이즈 애플리케이션 시스템을 구성하는 각 서버나 클라이언트 컴퓨터 시스템은 물리적인 티어로 구조화 된다. 즉 각 티어는 하나 이상의 컴퓨터로 구성된다. 같은 티어에 속해있는 컴퓨터 시스템은 같은 특성을 공유한다.
*레이어의 방식
1. 엄격한 레이어 방식
같은 레벨의 레이어 또는 바로 하위 레벨의 레이어하고만 커뮤니케이션을 할 수 있도록 제한한다. 레이어3은 3이나 2하고만 커뮤니 가능
2유연한 레이어 방식
같은 레벨의 레이어는 물론, 하위 레벨의 어떤 레이어하고도 커뮤니케이션이 가능하다. 레이어3은 레이어2,1하고도 가능
유연한 레이어 방식은 중간에 다른 레이어를 거치지 않고도 직접 하위 레이어와 커뮤니케이션을 할 수 있게 하기 때문에 유연성 증가 그러나 상위 레벨의 레이어들에게 영향을 주지 않고 하위 레벨의 레이어를 변경 시키는 ㅇ리이 어려우므로 관리에 문제를 노출하기도 한다.
POSA(pattern-Oriented Software Architecture) POSA는 패턴 지향 아키텍쳐 패턴을 실제 시스템에 적용하게 해주는 큰 밑그림 디자인 패턴을 실무에 적용해주는 것
총 10단계로 구성되는데 모두 필수적인 것이아니라 필요에 따라 선택할 수 있습니다.
품질 속성이 도출되고, 품질 속성에 대한 기본적인 아키텍처 전략이 수립되었다면, 두출된 품질 속성과 아키텍처 전략을 만족하는 레퍼런스 아키텍처를 선택하여 초기 아키텍처의 골격으로 삼는다.
일반적으로 레퍼런스 아키텍처는 다음과 같이 3개의 레이어로구성되는 레이어 아키텍처 스타일 사용한다.
1. 프리젠테이션 레이어 웹티어에 위치하며 사용자가 엔터프라이즈 애플리케이션과 상호작용하기 위해 호출되는 컴포넌트 포함 사용자 인터페이스 컴포넌트만 포함
2. 비즈니스 레이어 비즈니스 티어에 위치하며, 애플리케이션으 ㅣ기능성 즉, 비즈니스 로직을 구현한다. (비즈니스 컴포넌트와 비지니스 워크플로우, 서비스 인터페이스 포함)
A. 비즈니스 컴포넌트 비즈니스 로직을 캡슐화하고 구현하는 비즈니스 개념의 소프트웨어 실현이다.
B. 비즈니스 워크플로우는 비즈니스가 수행하는 행위 과정, 즉 비즈니스 프로세스를 캡슐화하는 컴포넌트이다
C. 서비스 인퍼테이스는 외부에 대해 서비스를 제공하는 컴포넌트로서. 큰 입자를 갑는 비즈니스 인터페이스만 노출한다. 일반적으로 서비스 인터페이스는 비즈니스 퍼샤드로서 역할을 하는 비즈니스 퍼사드 컴포넌트로 실현, 웹섭스를 사용하여 실현 할 수도 있따.
3. 데이터 레이어 비즈니스 티어에 위치하며 , 주로 데이터베이스에 저장된 데이터 비즈니스 레이어 측에 노출하는 데이터 액세스 컴포넌트를 포함하며, ㅓ비스 에이전트 컴포넌트를 포함할 수 있다.
A. 데이터 액세스 컴포넌트는 특정한 데이터 저장 솔루션의 세부사항으로부터 비즈니스 레이어를 분리, 분리시 이점
i. 데이터 공급자가 변경될 떄 영향을 최소화 할 수 있다
ii. 데이터베이스 스키마와 같은 데이터 표현 방식이 변경될 때 영향을 최소화할수잇다
iii. 한곳에서 특정한 데이터를 조작하는 코드를 캡슐화 > 테스트와 관리를 쉽게
일단 아키텍처 전략이 수립되었다면, 이들 아키텍처 전략을 기반으로 초기 아키텍처 모델을 생성한다. 초기 아키텍처 모델은 애플리케이션 아키텍처의 논리 뷰와 기술 아키텍처의 배포 뷰로 표현한다.
이 예제는 3레이어 아키텍처 스타일에 별도의 비즈니스 퍼사드 레이어를 추가한것입니다.
비즈니스 퍼사드 레이어는 Fowler의 서비스 레이어와 마찬자기로 APP범위와 프레젠테이션 레이어가 상호작용을 할 수 있는 오퍼레이션의 집합을 정의한다. 비즈니스 퍼사드 레이어는 비즈니스 퍼사드 레이엉에 포함되는 비즈니스 퍼사드 컴포넌트는 비즈니스 레이어의 다른 비즈니스 컴포넌트와 프레제인테이션 레이어의 사용자 인터페이스 컴포넌트를 분리하는 연할을한다. 이러한 것의 이점은 비즈니스 레이어에 대한 접근을 클라이언트로부터 분리함으로써 비즈니스 컴포넌트의 번화에도 시스템이 유연성을 갖도록 한다는 것이다.
성공적인 아키텍처 설계 원칙
1. .T자형 사고
A. 먼저 커다란 시야로 시스템을 바라봄으로써 시스템의 전체적인 개요를 이해한다. 결국 나무 보다 숲을 먼저 보자는 것이다. 세부적인 사항에 대해 신경 쓸 필요가 없다. 시스템의 전체의 이미지를 그릴 수 있다면 시스템을 추상화 시켜 시스템을 의미잇는 단위로 분할한 후 ,서브시스템이나 컴포넌트 무듈로 그룹화 함으로써 모듈화 분할된 무듈을 하나씩 나누어서 해결 한다.
B. 다음에는 하나의 모듈을 선택하여 한 레벨 안으로 들어가서 생각한다. 다른 모듈관의 관계를 염두하지 않는다. 시스템의 큰 그림과 관계만 고려하고 다른 사항은 고려하지 않는다.
C. 한 모듈의 범위 안에서 하나의 레벨을 이해했다면, 관심을 다른 모듈로 이동해 그 모듈의 범위 안에서 한 레벨안으로 들어가서 생각한다. 이과정은 시스템의 모든 모듈에 적용한다. 전체 시스템을 확실히 이해할 때까지 반복한다.
2. 기존의 성공지식을 활용하라
A. 아키텍처 스타일, 레퍼런스 아키텍처등은 수 많은 프로젝트 중 성공적으로 수행된 결과를 기반으로 재사용될 수 있도록 정의된것이다. 이러한 자산을 충분히 활용한다면 실패없는 견고한 아키텍처를 설게 할수 있게된다
3. 이론적인 기초에 충실해라
2번째 에서 어느게 좋은지 나쁜지 선택이나 판단이 맞는지 틀리는지 판단할 수 없는경우 가 있는데, 이럴 때 가장 좋은 스승은 경험이다.
유스케이스 실현을 통해 유스케이스의 행위를 설명하고 개념적인 분석 클래스를 도출한다.
업무 처리에서 중요한 개념을 갖는 비즈니스 객체를 도출하고, 이들 비즈니스 객체 사이의 관계 정의 한다.
사용자 인터페이스 요소가 어떻게 유스케이스 행위를 제공하는지 정의한다.
아키텍처 정의 단계의 두 번째 활동은 유스케이스의 행위를 분석하는 일입니다. 아키텍처를 설계 하기 위한 두 번째 사전활동으로서 유스케이스 분석잡업에서 객체 사이의 상호작용이란 관점에서 요구 파악 단계에서 도출된 유스케이스를 실현함으로써 유스케이스 행위를 설명하고, 유스케이스 실현을 토대로 개념적인 비즈니스 객체 모델을 생성한다. 또한 유스케이스 스토리보드를 생성하여 사용자 인터페이스 요소가 어떻게 유스케이스의 행위를 제공하는 지를 정의하는 작업을 수행한다.
유스케이스 실현을 통해 유스케이스의 행위를 설명하는 것
비즈니스 컴포넌트의 후보를 도출하는데 사용되며 비즈니스 객체 모델을 생성하는 기반이 된다.
분석 클래스 식별과 유스케이스 실현을 개별적으로 수행할 수 있으나 두 절차를 함계 병행하여 수행하는 것이 더 효과적일 경우가 많다.
유스케이스 분석작업은 요구 파악 단계에서 도출된 각 유스케이스에 대하여 유스케이스 실현을 생성함으로써 시작한다.
대략적인 표현방법과 실제적인 표현방법입니다.
MVC 패턴을 적용하여 3가지 유형의 클래스를 식별한다.
경계 클래스 View에 해당하는 클래스
사용자 인터페이스 클래스(사용자가 시스템에서 사용하게 될 화면 사용자 화면에 대한 자세한 모델링은 사용자 인터페이스 모델 생성작업에서 수행하므로 여기서는 단지 경계 클래스만 찾는다.)
시스템 인터페이스 클래스 (기존의 외부 시스템과 커뮤니케이션하는 경계 클래스이며, 유스케이스 모델에서는 액터로 정의되어 있는 경우가 많다.)
제어 클래스 컨트롤러에 해당하는 클래스 시스템을 제어하는 행위를 제공하며 비즈니스 컴포넌트의 후보가된다. 찾을때 고려사항
기본적으로 각 유스케이스에 대하여 하나의 제어 클래스를 생성한다.
CRUD(Create,Read,Update/Delete) 유스케이스라면 제어클래스가 반드시 필요한것은아니다. 그러나 비즈니스 컴포넌트의 유력한 후보가 되므로 일단 도출하고 나중에 제외시킬 것을 고려하는 것이 좋다.
복잡한 유스케이스라면 하나이상의 제어클래스가 필요할수도있다.
제어클래스는 경계 클래스와 실체 클래스 객체를 효율적으로 분리시킴으로써 시스템 영역의 변경 사항에 대하여 시스템이 내구성을 갖게 한다.또한유스케이스에 특정한 행위를 실체클래스로부터 분리시킴으로써 다른 유스케이스와 시스템에서 제어 클래스를 재사용할 수도 있게된다.
실체 클래스 시스템에 저장되는 정보를 표현하며 일반적으로 시스템이 관리하는 주요 추상화 개념을 표현하기 위해 사용된다. 따라서 비즈니스 객체 모델 생성작업에서 도출될 비즈니스 객체의 유력한 후보가 되며, 데이터 액세스 컴포넌트의 후보가 된다. 보통 수동적인 지속성을 가지며, 시스템에 정보를 저장하고 관리하는 역할을 한다.
참고 :분석 클래스 식별방법
텍스트를 분석해서 클래스 식별방법
CRC분석방법
올바른 클래스를 찾아내는 것은 각강의 분석가의 관점과 기술, 그리고 경험에 많이 좌우된다
텍스트를 구문 분석함으로써 클래스와 속성 책임을 찾는 간단한 방법 도메인에서 사용하는 동사/명사를 직접 분석하는 기법으로 수년간 사용된 방법이고 좋은 결과를 주고 있다. 하지만 유의어나 동음이의어에 대해서 각별히 주의해야 하고, 문제 도메인을 확실히 이해하고 있어ㅇ야한다. 가장 까다로운 점은 숨겨진 클래스를 찾는것이다.
CRC 분석을 통한 분석 클래스식별
사용자의 참여를 이끌어낼 수 있는 방법이다. CRC란 클래스 책임Responsibility 협력자 Collaborator를 나타낸다. 정보 수집(브레인스토밍) 모든 아이디어를 받아들여 기록하되 , 논쟁하지않는다. 분석과 논의는 별도의 작업을 통해서 하게된다.
정보 분석 분석가와 도메인 전문가만 참여해서 어느 CRC카드가 클래스가 되고 어떤것이속성이 될것인지 결정한다.
앞에서 한 시퀀스 다이어그램을 기반으로한 분석클래스 모델입니다.
유스케이스 분석잡업에 도출된 전체 유스케이스 실현을 대상으로 제어 분석클래스나 실체분석클래스에 메시지와 함께 전달되는 데이터를 그룹화하여 비즈니스 객체를 정의
예 이와 같이 생성된 비즈니스 객체모델은 선택 사항으로 소프트웨어 아키텍처 정의서의 비즈니스 아키텍처에 추가될 수 있다.
유스케이스 스토리보드를 생성하여 사용자 인터페이스 요소를 도출하고 사용자 인터페이스 요소가 어떻게 유스케이스 행위를 제공하는지를 정의하는 것 , 생성결과물은 UI설계자가 사용자 화면을 디자인하는데 입력자료로서 활용된다.
사용자 인터페이스 정의에 대해서는 블렌더 발표자가 발표하는게 효과적이므로 자세한 내용은 생략했습니다.
애플리케이션 아키텍처 설계 단계 활도엥서는 행위 분석활동에서 정의된 유스케이스 실현과 비즈니스 객체 모델을 분석하여 후보 비즈니스 컴포넌트를 도출, 비즈니스 컴포넌트를 식별하여 비즈니스 컴포넌트의 논리적인 모델을 정의한다. 그리고 마지막으로 식별된 비즈니스 컴포넌트의 명세를 설계하는 작업을 수행한다.
비즈니스 컴포넌트란 비즈니스 개념 또는 비즈니스 프로세스를 구현하는 소프트웨어 구현으로서 재사용할 수 있는 엔터프라이즈 시스템의 요소로서 해당 비즈니스 개념을 표현하고 구현 및 배포 하는데 필요한 모든 소프트웨어 산출물들로 구성된다.
이와 같은 비즈니스 컴포넌트에 대한 정의는 비즈니스 컴포넌트가 물리적인 개념 뿐만 아니라 논리적인 개념도 함께 포함되고 있다는 것을 말해준다.
비즈니스 객체가 업무 처리에서 중요한 개념.을 갖는 실체(entitiy) 를 표현하는 개념적 의미를 갖는다면
비즈니스 컴포넌트 비즈니스 개념을 실현하기 위한 설계 과정에서의 일련의 행위들의 결과로 도출되는 사양specification
결국 개념적인 비즈니스 객체는 논리적인 비즈니스 컴포넌트로 실현되며, 다시 물리적인 구현 컴포넌트로 구현되는 과정을 밟게 된다.
앞의 비즈니스 객체 모델으로 비즈니스 컴포넌트를 도출한 예 입니다.
유스케이스 분석작업에서 도출된 분석 클래스중 제어 클래스가 비즈니스 컴포넌트의 최우선 후보가 된다.
CRUD 유스케이스라면 실체 클래스가 비즈니스 컴포넌트의 후보가 된다.
서로 관련된 유스케이스들의 유스케이스 실현에서 유사한 메시지 흐름을 갖는 제어 클래스를 그룹화하여 하나의 후보 비즈니스 컴포넌트로 정의한다. 유사한 책임은 같은 비즈니스 컴포넌트에 속해야 하기 떄문이다.
마찬가지 방법으로 유사한 메시지 흐름을 갖는 실체 클라스를 그룹화 한다. 비즈니스 컴포넌트가 여러 실체를 관리해야 한다면 이들 실체를 관리하는데 필요한 책임은 해당 비즈니스 컴포넌트에 있기 때문이다.
후보 컴포넌트 도출의 예입니다.
식별된 인터페이스를 구현하게 될 비즈니스 컴포넌트를 추가하고 비즈니스 인터페이스와 비즈니스 컴포넌트 사이에 실현관계를 정의한다. 다음 후보 비즈니스 컴포넌트 모델을 참조하여 비즈니스 인터페이스를 중심으로 비즈니스 컴포넌트 사이의 관계를 식별하고 종속 관계를 정의한다.
비즈니스 컴포넌트 모델 구조화
비즈니스 컴포넌트 모델 정의 작업의 마지막 절차는 비즈니스 컴포넌트 모델을 구조화 하는것이다.
유의해야 할점은 비즈니스 컴포넌트 모델이 초기 아키텍처 정의 활동에서 정의한 초기 아키텍처 모델을 충실히 반영해야 한다.
비즈니스 컴포넌트가 실현할 인터페이스를 명세화하여 비즈니스 컴포넌트 설계서에 기술한다. 여기에서 비즈니스 컴포넌트 설계서를 생성하고 유스케이스 실현을 참고하여 인터페이스에 포함된 각 행위 기능을 비즈니스 컴포넌트 설계서에 상세히 기술한다. 입출력매개변수 컴포넌트가 상태를 유지해야할 항목 및 컴포넌트 제약사항등이 기술된다. 비즈니서 컴포넌트 설계서에서는 논리적인 관저점에서 비즈니스 컴포넌트 설계 내용을 기술하면된다. 특정한 기술이 적용된 비즈니스 컴포넌트는 설계는 설계 단계에서 구현 컴포넌트 설계서에 작성될 것이다.
애플리케이션 아키텍처 설계이후 과정
설계된 비즈니스 컴포넌트는 기업 안에서 관리되는 컴포넌트 레파지토리에서 설계된 비즈니스 컴포넌트의 사양과 일치하거나 유사한 비즈니스 컴포넌트가 있는지 검색한다. 만약 컴포넌트 레파지토리에 비즈니스 컴포넌트가 있다면 컴포넌트를 그대로 또는 약간의 수정을 통해 재사용할 수 있게 된다. 이 경우, 컴포넌트 레파지토리에 있는 컴포넌트에 대해서는 설계 단개를 포함하여 이후의 과정이 생략될 수 있으며, 이것은 엔터프라이즈 애플리케이션 개발 노력과 기간을 단축시켜준다. 하지만 없다면 셀계 단계를 통해 특정한 기술이 적용된 구현 컴포넌트로 설계되고 물리적인 구현 컴포넌트로 구현되어야한다.
