핵심 원칙

소프트웨어 아키텍처는 시스템의 구성으로 설명되며 시스템은 정의 된 기능을 수행하는 구성 요소 집합을 나타냅니다.

건축 스타일

그만큼 architectural style라고도 함 architectural pattern는 애플리케이션을 형성하는 일련의 원칙입니다. 구조적 조직의 패턴 측면에서 시스템 제품군에 대한 추상 프레임 워크를 정의합니다.

건축 스타일은-

결합 방법에 대한 규칙과 함께 구성 요소 및 커넥터의 어휘를 제공합니다.
자주 발생하는 문제에 대한 솔루션을 제공하여 파티셔닝을 개선하고 디자인을 재사용 할 수 있습니다.
구성 요소 모음 (잘 정의 된 인터페이스, 재사용 및 교체 가능한 모듈) 및 커넥터 (모듈 간 통신 링크)를 구성하는 특정 방법을 설명합니다.

컴퓨터 기반 시스템 용으로 구축 된 소프트웨어는 여러 아키텍처 스타일 중 하나를 나타냅니다. 각 스타일은 다음을 포함하는 시스템 범주를 설명합니다.

시스템에서 필요한 기능을 수행하는 구성 요소 유형 집합입니다.
서로 다른 구성 요소 간의 통신, 조정 및 협력을 가능하게하는 커넥터 세트 (서브 루틴 호출, 원격 프로 시저 호출, 데이터 스트림 및 소켓)입니다.
시스템을 형성하기 위해 구성 요소를 통합 할 수있는 방법을 정의하는 의미 적 제약.
런타임 상호 관계를 나타내는 구성 요소의 토폴로지 레이아웃입니다.

일반적인 건축 설계

다음 표는 주요 초점 영역별로 구성 할 수있는 건축 스타일을 나열합니다.

범주	건축 설계	기술
통신	메시지 버스	하나 이상의 통신 채널을 사용하여 메시지를 송수신 할 수있는 소프트웨어 시스템의 사용을 규정합니다.
통신	서비스 지향 아키텍처 (SOA)	계약 및 메시지를 사용하여 기능을 서비스로 노출하고 사용하는 애플리케이션을 정의합니다.
전개	클라이언트 서버	클라이언트가 서버에 요청하는 두 개의 애플리케이션으로 시스템을 분리합니다.
전개	3 계층 또는 N 계층	기능을 별도의 세그먼트로 분리하고 각 세그먼트는 물리적으로 분리 된 컴퓨터에있는 계층입니다.
도메인	도메인 중심 설계	비즈니스 도메인 모델링 및 비즈니스 도메인 내의 엔터티를 기반으로 비즈니스 개체를 정의하는 데 중점을 둡니다.
구조	구성 요소 기반	애플리케이션 설계를 잘 정의 된 통신 인터페이스를 노출하는 재사용 가능한 기능적 또는 논리적 구성 요소로 분류합니다.
	계층화	애플리케이션의 관심사를 스택 그룹 (레이어)으로 나눕니다.
	객체 지향	응용 프로그램 또는 시스템의 책임을 개체로 나누는 것을 기반으로하며, 각각 개체와 관련된 데이터 및 동작을 포함합니다.

아키텍처 유형

기업의 관점에서 보면 4 가지 유형의 아키텍처가 있으며 총체적으로 이러한 아키텍처를 enterprise architecture.

Business architecture − 기업 내 비즈니스, 거버넌스, 조직 및 주요 비즈니스 프로세스의 전략을 정의하고 비즈니스 프로세스의 분석 및 설계에 중점을 둡니다.
Application (software) architecture − 개별 애플리케이션 시스템, 상호 작용 및 조직의 비즈니스 프로세스와의 관계에 대한 청사진 역할을합니다.
Information architecture − 논리적 및 물리적 데이터 자산과 데이터 관리 리소스를 정의합니다.
Information technology (IT) architecture − 조직의 전체 정보 시스템을 구성하는 하드웨어 및 소프트웨어 빌딩 블록을 정의합니다.

아키텍처 디자인 프로세스

아키텍처 설계 프로세스는 기능 및 비 기능적 요구 사항을 충족하기 위해 시스템을 여러 구성 요소와 상호 작용으로 분해하는 데 중점을 둡니다. 소프트웨어 아키텍처 설계에 대한 주요 입력은 다음과 같습니다.

분석 작업에 의해 생성 된 요구 사항입니다.
하드웨어 아키텍처 (소프트웨어 아키텍트는 하드웨어 아키텍처를 구성하는 시스템 아키텍트에게 요구 사항을 제공합니다).

아키텍처 설계 프로세스의 결과 또는 출력은 architectural description. 기본 아키텍처 설계 프로세스는 다음 단계로 구성됩니다.

문제 이해

이것은 다음 디자인의 품질에 영향을 미치기 때문에 가장 중요한 단계입니다.
문제에 대한 명확한 이해 없이는 효과적인 솔루션을 만들 수 없습니다.
많은 소프트웨어 프로젝트 및 제품은 실제로 유효한 비즈니스 문제를 해결하지 않았거나 인식 할 수있는 ROI (투자 수익)를 갖지 않았기 때문에 실패로 간주됩니다.

디자인 요소와 그 관계 식별

이 단계에서는 시스템의 경계와 컨텍스트를 정의하기위한 기준을 구축합니다.
기능 요구 사항에 따라 시스템을 주요 구성 요소로 분해합니다. 분해는 요소의 세분성을 지정하지 않고 디자인 요소 간의 종속성을 보여주는 DSM (Design Structure Matrix)을 사용하여 모델링 할 수 있습니다.
이 단계에서 아키텍처의 첫 번째 유효성 검사는 여러 시스템 인스턴스를 설명하여 수행되며이 단계를 기능 기반 아키텍처 설계라고합니다.

아키텍처 디자인 평가

각 품질 속성에는 추정치가 제공되므로 정 성적 측정 또는 정량적 데이터를 수집하기 위해 설계가 평가됩니다.
여기에는 아키텍처 품질 속성 요구 사항을 준수하기위한 아키텍처 평가가 포함됩니다.
모든 예상 품질 속성이 필수 표준에 부합하면 건축 설계 프로세스가 완료된 것입니다.
그렇지 않은 경우 소프트웨어 아키텍처 설계의 세 번째 단계 인 아키텍처 변환이 시작됩니다. 관찰 된 품질 속성이 요구 사항을 충족하지 않는 경우 새 디자인을 만들어야합니다.

아키텍처 디자인 혁신

이 단계는 건축 설계를 평가 한 후에 수행됩니다. 품질 속성 요구 사항을 완전히 충족 할 때까지 아키텍처 디자인을 변경해야합니다.
도메인 기능을 유지하면서 품질 속성을 개선하기 위해 설계 솔루션을 선택하는 것과 관련이 있습니다.
디자인 연산자, 스타일 또는 패턴을 적용하여 디자인을 변형합니다. 변환을 위해 기존 설계를 취하고 분해, 복제, 압축, 추상화 및 리소스 공유와 같은 설계 연산자를 적용합니다.
설계를 다시 평가하고 필요한 경우 동일한 프로세스를 여러 번 반복하고 심지어 재귀 적으로 수행합니다.
변환 (즉, 품질 속성 최적화 솔루션)은 일반적으로 하나 또는 일부 품질 속성을 개선하고 다른 항목에는 부정적인 영향을 미칩니다.

주요 아키텍처 원칙

다음은 아키텍처를 설계 할 때 고려해야 할 핵심 원칙입니다.

오래도록 구축하는 대신 변경하도록 구축

새로운 요구 사항과 과제를 해결하기 위해 시간이 지남에 따라 애플리케이션이 어떻게 변경되어야하는지 고려하고이를 지원할 수있는 유연성을 구축하십시오.

분석 할 위험 및 모델 감소

디자인 도구, 시각화, UML과 같은 모델링 시스템을 사용하여 요구 사항 및 디자인 결정을 캡처합니다. 영향도 분석 할 수 있습니다. 설계를 쉽게 반복하고 적용 할 수있는 기능을 억제 할 정도로 모델을 공식화하지 마십시오.

모델 및 시각화를 커뮤니케이션 및 협업 도구로 사용

설계, 결정 및 설계에 대한 지속적인 변경에 대한 효율적인 커뮤니케이션은 좋은 아키텍처에 매우 중요합니다. 아키텍처의 모델,보기 및 기타 시각화를 사용하여 모든 이해 관계자와 효율적으로 설계를 공유하고 공유합니다. 이를 통해 설계 변경 사항을 신속하게 전달할 수 있습니다.

주요 엔지니어링 결정과 실수가 가장 자주 발생하는 영역을 식별하고 이해합니다. 설계를보다 유연하게 만들고 변경으로 인해 손상 될 가능성을 줄이기 위해 처음에 주요 결정을 올바르게 내리는 데 투자하십시오.

점진적이고 반복적 인 접근 방식 사용

기본 아키텍처로 시작한 다음 반복 테스트를 통해 후보 아키텍처를 발전시켜 아키텍처를 개선합니다. 여러 번에 걸쳐 디자인에 세부 사항을 반복적으로 추가하여 크고 정확한 그림을 얻은 다음 세부 사항에 집중하십시오.

주요 설계 원칙

다음은 비용, 유지 보수 요구 사항을 최소화하고 아키텍처의 확장 성, 유용성을 최대화하기 위해 고려해야 할 설계 원칙입니다.

우려 사항 분리

시스템의 구성 요소를 특정 기능으로 분할하여 구성 요소 기능이 겹치지 않도록합니다. 이것은 높은 응집력과 낮은 결합을 제공합니다. 이 접근 방식은 시스템을 쉽게 유지하는 데 도움이되는 시스템 구성 요소 간의 상호 의존성을 방지합니다.

단일 책임 원칙

시스템의 모든 모듈에는 하나의 특정 책임이 있어야 사용자가 시스템을 명확하게 이해할 수 있습니다. 또한 구성 요소를 다른 구성 요소와 통합하는데도 도움이됩니다.

최소 지식의 원리

모든 구성 요소 또는 개체는 다른 구성 요소의 내부 세부 정보에 대한 지식이 없어야합니다. 이 접근 방식은 상호 의존성을 피하고 유지 관리에 도움이됩니다.

대규모 설계를 사전에 최소화

응용 프로그램의 요구 사항이 명확하지 않은 경우 큰 디자인을 미리 최소화하십시오. 요구 사항을 수정할 가능성이있는 경우 전체 시스템에 대해 대규모 설계를하지 마십시오.

기능을 반복하지 마십시오

반복 금지 기능은 구성 요소의 기능이 반복되지 않도록 지정하므로 한 구성 요소에서만 코드를 구현해야합니다. 응용 프로그램 내에서 기능이 중복되면 변경 사항을 구현하기 어렵고 명확성이 떨어지며 잠재적 인 불일치가 발생할 수 있습니다.

기능을 재사용하면서 상속보다 구성 선호

상속은 자식 클래스와 부모 클래스간에 종속성을 생성하므로 자식 클래스의 무료 사용을 차단합니다. 반대로 컴포지션은 높은 수준의 자유를 제공하고 상속 계층 구조를 줄입니다.

구성 요소를 식별하고 논리적 계층으로 그룹화

요구 사항을 충족하기 위해 시스템에 필요한 식별 구성 요소 및 관심 영역. 그런 다음 이러한 관련 구성 요소를 논리적 계층으로 그룹화하면 사용자가 높은 수준에서 시스템의 구조를 이해하는 데 도움이됩니다. 동일한 레이어에서 다른 유형의 문제의 구성 요소를 혼합하지 마십시오.

계층 간 통신 프로토콜 정의

배포 시나리오 및 프로덕션 환경에 대한 완전한 지식이 필요한 구성 요소가 서로 통신하는 방법을 이해합니다.

레이어의 데이터 형식 정의

다양한 구성 요소가 데이터 형식을 통해 서로 상호 작용합니다. 응용 프로그램을 쉽게 구현, 확장 및 유지 관리 할 수 있도록 데이터 형식을 혼합하지 마십시오. 여러 구성 요소가 서로 통신하는 동안 데이터를 코딩 / 디코딩 할 필요가 없도록 레이어의 데이터 형식을 동일하게 유지하십시오. 처리 오버 헤드를 줄입니다.