그럼 아키텍처 설계 설명서는 어떻게 쓰나요? 이 설명서에는 어떤 내용이 포함되어야 합니까? 우리는 아키텍처 설계 사양이 시스템 아키텍처의 구체적인 내용을 설명한다는 것을 알고 있습니다. 내 이전 문장' 내 아키텍처관-아키텍처의 미래 발전' 에 따르면, 아키텍처의 본질은 시스템이 최종 사용자에게 지원 기능을 제공하는 방법, 외부 시스템에 상호 작용 기능을 제공하는 방법, 기업 데이터에 처리 능력을 제공하는 방법 등 세 가지 주요 기능을 제시하는 것입니다. 따라서 이러한 관점에서 아키텍처 설계 설명서의 섹션 설정 및 섹션 내용 배치는 시스템 아키텍처가 이러한 세 가지 기능을 어떻게 제공하는지 명확하게 설명할 수 있어야 합니다. 하나씩 분석해 보겠습니다.
시스템이 최종 사용자에게 어떻게 지원 기능을 제공합니까? 이는 시스템 자체의 능력, 즉 시스템이 어떤 기능을 갖추어야 하는지, 어떻게 서로 맞춰야 최종 사용자를 지탱할 수 있는 요구를 충족시킬 수 있는 것이다. 실제로 시스템의 기능 아키텍처 또는 논리 아키텍처에 대해 이야기하고 시스템이 기능 세분성에서 몇 개의 기능 모듈 또는 하위 시스템, 각 모듈 또는 하위 시스템 간의 내부 인터페이스 관계 등에 대한 질문에 답하는 것입니다. 물론 고려해야 할 또 다른 문제가 있습니다. 세로 차원에서 아키텍처 설계 개념이 지속적으로 발전함에 따라 논리 아키텍처 모델은 초기 디스플레이-데이터 2 계층 모델에서 디스플레이-논리-데이터 3 계층 모델 (즉, MVC), 디스플레이-호출 인터페이스-논리-데이터 인터페이스-데이터 5 계층 모델까지 다양한 수준에서 시스템 내부 설계의 정교함을 보여줍니다 따라서 실제 상황에 따라 이러한 계층형 설계를 논리 스키마 설계에 추가할 필요가 있습니다. 특히 브라우저/서버 아키텍처 모드의 MIS 시스템에서는 이 계층이 더 일반적입니다. 또한 사용자는 시스템에 비해 시스템이 제공하는 능력에 대한 개인적인 선호도를 가지고 있습니다. 이를 위해서는 시스템이 지원을 제공할 수 있을 뿐만 아니라 더욱 안정적이고 편리하며 유연하고 빠르기 때문에 아키텍처 설계 사양에 비기능적 설계라는 것을 추가해야 합니다. 즉, 시스템의 성능, 고가용성, 확장성, 서비스 가능성, 보안 및 이식성을 설명합니다.
시스템이 외부 시스템에 상호 작용 기능을 제공하는 방법은 무엇입니까? 이것은 시스템이 외부 시스템과 호출 관계를 생성하는 방법, 외부 시스템이 제공하는 오픈 인터페이스, 외부 시스템에 제공하는 외부 인터페이스 및 기능을 설명하는 완전한 전체로 간주되는 것입니다. 동시에 이러한 상호 호출 관계에서 전체 it 아키텍처의 위치는 실제로 시스템의 전체 아키텍처입니다. 또한 운영 체제와 하드웨어 서버를 특수한 외부 시스템으로 본다면, 운영 체제에 따라 하드웨어 서버를 사용하여 컴퓨팅, 스토리지, 네트워킹 등의 기능을 제공하는 방법, 그리고 시스템이 어떻게 자신을 별도의 부분으로 분할하여 서버에 배포할 수 있는지 설명해야 합니다. (데이비드 아셀, Northern Exposure (미국 TV 드라마), 컴퓨터명언) 이것은 실제로 배포 아키텍처입니다.
기업 데이터에 처리 능력을 제공하는 방법: 정보 시스템의 초기 원동력은 사람들이 컴퓨터의 강력한 컴퓨팅 능력을 이용하여 대량의 데이터를 처리하는 데 도움을 주어 이해할 수 있는 정보를 형성하고 결국 습득한 지식을 형성해야 한다는 것이다. 따라서 데이터 처리는 시스템의 근본적인 목적이며 매우 중요합니다. 아키텍처 설계 사양에서 시스템의 데이터 처리 능력, 즉 시스템 데이터 아키텍처를 별도로 설명해야 합니다. 이것은 여전히 외부와 내면의 두 각도에서 볼 수 있다. 외부, 엔터프라이즈 데이터 스트림 전체에서 이 시스템이 처리하는 데이터의 위치, 관련 업스트림 데이터와의 관계, 데이터 업스트림 외부 시스템에서 어떤 데이터를 가져와야 하는지 설명해야 합니다. 데이터 다운 스트림 시스템에 어떤 데이터를 제공해야합니까? 내부에는 시스템이 비즈니스 요구 사항에 따라 설계한 주요 데이터 테이블, 키 및 외래 키 관계, 시스템을 초기화하기 위해 외부에서 데이터를 가져와야 하는지 여부를 설명해야 합니다. 물론 데이터 중복 설계, 백업 메커니즘, 데이터 보안 관리 메커니즘 등을 포함한 데이터 관리에 대한 설명도 있습니다.
-응? -응? 음, 이 세 가지 기능을 분석 후, 우리는 거의 전반적인 스키마, 논리 스키마, 데이터 스키마, 배포 스키마, 내부 및 외부 인터페이스, 비 기능성 설계 등 아키텍처 설계 사양에 포함 되어야 하는 콘텐츠를 발견 했습니다. 건축 설계가 순수한 이론 학습이라면 이것으로 충분하다. 그러나 실제로 우리가 작성한 아키텍처 설계 사양은 후속 시스템 개발을 안내하기 위해 작성되었으며, 진정한 구현이 필요합니다. 그렇다면 어떤 기술로 실현할 수 있을까요? (데이비드 아셀, Northern Exposure (미국 TV 드라마), 예술명언) 어떤 핵심 기술이 있습니까? 어떤 성숙 또는 오픈 소스 기술 구성 요소가 사용됩니까? 이전에 어떤 기술 성과가 중용되었습니까? 등등, 기술적 위험과 예방 조치에 대한 고려도 포함되어 있다. 이것들은 모두 기술 아키텍처의 내용이다.
요약하면, 우리는 완전한 아키텍처 설계 사양 구조와 포함되어야 할 내용을 얻을 수 있습니다. 일반적인 장은 다음과 같아야 합니다.
문서 개요: 프로젝트 배경, 프로젝트 대상, 문서 버전 정보, 대상 독자, 참조 문서, 명사 해석 등 일반 문서에서 흔히 볼 수 있는 장을 포함합니다.
전체 아키텍처: 주로 전체 it 계층에서 시스템의 위치 및 주변 관련 시스템과의 호출 관계를 설명합니다.
논리 아키텍처: 시스템 내부 기능 모듈의 구분, 각 모듈의 기능 소개 및 상호 관계 표현
인터페이스 설계: 시스템 간의 인터페이스 설계와 내부 기능 모듈 간의 인터페이스 설계를 포함합니다.
데이터 스키마: 시스템과 업스트림 및 다운스트림 시스템 간의 데이터 흐름 관계, 시스템의 주요 데이터 테이블 설계 및 데이터 관리 전략
기술 아키텍처: 이 아키텍처를 구현하는 데 필요한 기술적 역량, 재사용 능력 및 위험
배포 아키텍처: 시스템 배포 방법, 네트워크 토폴로지에 필요한 요구 사항, 하드웨어 서버에 필요한 요구 사항, 필요한 서버 수, 서버 매개 변수 최적화 필요 여부
비기능적 설계: 성능, 고가용성, 확장성, 서비스 가능성, 보안, 이식성 등
기타 설명: 특수 제약, 위험 고려 사항, 진행 요구 사항, 정책 제한, 환경 영향 등