아웃소싱 비즈니스 유형 프로젝트의 경우 소프트웨어 아키텍처 설계의 목적은 제품 유형 프로젝트와 다릅니다. 여기서는 아웃소싱 비즈니스 유형 프로젝트의 소프트웨어 아키텍처 설계 목적에 대해 주로 논의합니다. 1. 대규모 개발의 기초와 사양을 제공하고 재사용 가능한 자산을 제공합니다. 소프트웨어 시스템의 대규모 개발에는 소프트웨어 엔지니어링 자체의 요구 사항일 뿐만 아니라 고객의 요구 사항인 특정 사양을 따르는 기반이 있어야 합니다. 아키텍처 설계 과정에서 일부 공통 부분을 추상화하여 공용 클래스 및 도구 클래스를 형성하여 재사용 목적을 달성할 수 있습니다. 2. 프로젝트 주기를 어느 정도 단축하고 소프트웨어 아키텍처가 제공하는 프레임워크 또는 재사용 가능한 구성 요소를 활용하여 프로젝트 개발 주기를 단축합니다. 3, 개발 및 유지 보수 비용 절감, 대량 재사용 및 추상화, 일부 개발자가 신경 쓰지 않아도 되는 공통 부분 추출, 개발자가 비즈니스 논리의 실현에만 집중할 수 있도록 하여 대량의 작업량을 줄이고 개발 효율성을 높일 수 있습니다. 4. 제품의 품질을 향상시킵니다. 좋은 소프트웨어 아키텍처 설계는 제품 품질 보증입니다. 특히 고객이 자주 제기하는 비기능적 수요에 대한 만족입니다. 소프트웨어 아키텍처 설계의 원칙 소프트웨어 아키텍처 설계는 기능 및 비기능 요구 사항을 충족하기 위해 1 원칙을 따라야 합니다. 이것은 소프트웨어 시스템의 가장 기본적인 요구 사항이며 아키텍처 설계에서 따라야 할 가장 기본적인 원칙입니다. 2. 실용원칙, 각 소프트웨어 시스템이 사용자에게 사용자 문제를 해결할 때 반드시 실용적이어야 하는 것처럼, 아키텍처 설계도 실용적이어야 한다. 그렇지 않으면' 높이' 또는' 오버디자인' 이다. 3. 재사용 요구 사항을 충족하고 개발자의 생산성을 극대화합니다. 소프트웨어 아키텍처 설계에 대한 몇 가지 관점 아키텍처 설계를 논의할 때, 또는 아키텍처 설계 검토 회의에서 개발자가 로그를 기록하는 방법, 트랜잭션 제어 방법 등 다양한 질문을 자주 합니다. 어떻게 하면 우리 개발자의 생산성을 높일 수 있습니까, 즉 단위 시간 내에 더 나은 품질로 더 많은 기능을 완성할 수 있습니까? 고객의 비기능 요구 사항을 어떻게 충족합니까? 운영 환경의 플랫폼 관리자가 시스템을 더 잘 유지 관리할 수 있도록 하려면 어떻게 해야 합니까? 위의 문제는 실제로 소프트웨어 시스템의 서로 다른 관계자들이 서로 다른 각도에서 제기한 것이다. 이러한 질문에 답하려면 소프트웨어 아키텍처 설계 작업을 다른 관점에서 보아야 합니다. 1. 논리 아키텍처의 관점에서 시스템 사용자의 관점에서 문제를 고려하여 설계된 소프트웨어 아키텍처는 비즈니스 논리의 요구를 충족하고 점점 더 복잡해지는 비즈니스 논리 요구 사항을 처리할 수 있습니다. 2. 개발 아키텍처의 관점에서 시스템 개발자의 관점에서 문제를 고려합니다. 설계 아키텍처는 이해, 개발 및 단위 테스트가 쉬워야 하므로 개발자는 최소한의 코드 라인으로 기능 개발을 완료하는 것이 좋습니다. 3. 운영 아키텍처의 관점에서, 시스템 런타임 품질 요구 사항, 특히 시스템의 비기능적 요구 사항에 초점을 맞추는 경우, 고객은 2000 명의 사용자가 동시에 온라인으로 사용할 수 있도록 시스템의 기능 화면에 최대 응답 시간을 4 초 이하로 요구하는 경우가 많습니다. 시스템 리소스는 역할 기반 보안 제어를 기반으로 합니다. 4. 물리적 아키텍처 관점에서 시스템 설치 배포 환경 (예: IBM http server+WebSphere application server+DB2, WebLogic+Oracle) 에 초점을 맞추는 것이 가장 널리 사용되는 엔터프라이즈 응용 프로그램 서비스 솔루션입니다. 5. 데이터 아키텍처에서 볼 때, 우리가 오늘 개발한 다양한 시스템 (예: MIS, ERP, SAP) 은 기본적으로 각종 데이터에 대해 운용하고, 잘 이해하지 못하는 데이터를 사용자에게 보여 주고, 각종 데이터를 자동으로 처리하기 때문에 데이터의 지속성이 중요하다. 1. 요구 사항을 분석하고, 비즈니스 모델 (또는 영역 모델링) 을 이해하고, 주요 사용 사례를 선택합니다. 소프트웨어 요구 사항은 사용자 관점과 개발자 관점으로 나눌 수 있으며, 사용자 관점에서 기능 요구 사항과 비기능 요구 사항으로 나눌 수 있습니다. 우리는 서로 다른 각도와 수준에서 요구 사항을 종합적으로 이해하고 분석하고 비즈니스 모델을 이해해야 합니다. 실천은 우리가 자주 간과하는 비기능적 수요가 종종 전체 프로젝트의 실패를 초래한다는 것을 보여준다. 비즈니스 요구 사항을 이해하는 가장 좋은 방법은 영역 모델링입니다. 도메인 모델링과 수요 분석은 종종 번갈아 진행됩니다. 도메인 모델링에는 ◆ 복잡한 문제를 탐색하고 도메인 지식을 정리하는 세 가지 기능이 있습니다. 마틴 풀러 (Martin Fowler) 는 그의 객체 지향 접근법의 가장 큰 장점은 더 복잡한 문제를 해결하는 데 도움이 된다고 말했다. 도메인 모델링 자체는 사고를 돕는 도구로, 가장 중요한 비즈니스 개념과 그 관계에 항상 집중할 수 있도록 하여 지속적으로 수요를 분석하고 이해할 수 있도록 해 줍니다. (윌리엄 셰익스피어, Northern Exposure (미국 TV 드라마), 예술명언) 도메인 모델링은 종종 흐릿함에서 명료함, 조각에서 시스템에 이르는 과정입니다. ◆ 기능 범위를 결정하고 확장성에 영향을 미칩니다. 모든 모델은 현실 세계에서 프로그램의 추상화입니다. 이러한 추상화는 객체의 속성, 객체 간의 관계 등과 같은 것을 무시하며, 이러한 무시는 종종 목적이 있으며 함수의 범위를 결정합니다. 이 모델은 다양한 기능 뒤에있는 구조를 보여줍니다. 정의함수가' 사진 찍기' 와 같다면 영역 모델링은' 투시' 와 같고 문제 영역의 내부 구조에 더 많은 관심을 기울이는 것은 문제 영역을 어느 정도 추상화하는 것과 같다. 좋은 분야 모델은 기존 기능을 잘 지원할 뿐만 아니라 향후 발생할 수 있는 새로운 요구 사항을 어느 정도 지원할 수 있어 확장성이 뛰어납니다. ◆ 효과적인 의사 소통을 촉진하기위한 의사 소통의 기초를 제공하십시오. 도메인 모델링은 일반적으로 UML 다이어그램을 표현으로 사용하여 의사 소통을 용이하게 합니다. 물론, 때로는 문자가 특정 분야의 문제를 설명할 때 더 적합하고 융통성이 있을 수 있다. 우리 회사의 실제 소프트웨어 개발 과정에서 도메인 모델링은 종종 이 부분이 부족한 경우가 많으며, 이는 향후 업무에서 더 보완해야 할 곳일 수 있습니다. 우리는 항상 건축가가 수요를 완전히 파악할 수 있기를 기대하지만, 시간과 정력의 제약으로 인해 건축가가 모든 수요를 깊이 분석할 시간이 없다는 것이 현실이다. 그래서 우리의 전략은' 칼날에 강철을 잘 쓰는 것' 이다. 즉, 대부분의 시간과 정력을 아키텍처의 가장 중요한 수요를 결정하는 데 쓰는 것이다. 주요 요구 사항을 선택할 때, 우선 순위가 높은 요구 사항은 종종 사용자의 관점에서 볼 수 있으며, 실제 주요 요구 사항은 아닐 수 있다는 점에 유의해야 합니다. RUP 종사자 가이드' 라는 책에서는 주요 기능 요구 사항을 파악하는 방법을 알려 줍니다. A. 응용 프로그램의 핵심 또는 시스템 주 인터페이스를 구현하는 기능 B. 구현되어야 할 기능, 즉 이러한 기능이 구현되지 않으면 개발된 소프트웨어는 가치를 잃게 됩니다. C. 시스템 아키텍처의 일부 측면을 포괄하지만 다른 중요한 사용 사례로 덮어쓰지 않는 기능. 소프트웨어 아키텍처의 모든 측면을 다른 관점에서 고려하십시오. 소프트웨어 아키텍처 설계는 모든 측면을 고려해야 하며, 선행 작업에 의해 설정된 영역 모델, 주요 요구 사항 및 시스템 제약에 따라 설계되어 시스템 사용자, 개발자, 시스템 관리자, 배포 관리자 및 데이터 관리자의 관점에서 문제를 분석하고 해결해야 합니다. 예를 들어, 운영 아키텍처가 클러스터 모드인 경우 캐시 및 세션 사용을 조심해야 합니다. 비즈니스 논리에서 여러 데이터베이스를 운영해야 하는 경우 2 단계 트랜잭션 제출 지원을 고려해야 합니다. 이러한 모든 측면을 고려해야만 이러한 아키텍처 설계가 완전합니다. 각 뷰에서 설계해야 할 세부 사항은 실제로 전체 프로젝트의 프로세스 정의와 관련이 있습니다. 예를 들어, 스키마 설계 과정에서 상위 수준의 데이터베이스 특성과 데이터베이스 간의 관계에만 초점을 맞추고, 후속 관련 활동에서 각 테이블의 데이터 사전을 설계할 수 있는 특별한 활동이 있습니다. 그러나 이 활동이 없으면 각 테이블의 각 필드와 테이블 간의 관계를 구체화합니다. 3. 기술적 핵심 문제와 곤혹을 해결하는 소프트웨어 아키텍처 설계 과정에서 우리는 종종 기술적인 주요 문제와 곤혹을 극복해야 하는데, 이는 탄탄한 이론 지식과 풍부한 실천 경험이 필요한 작업이다. 예를 들어, 전체 시스템의 성능을 어떻게 향상시킬 수 있습니까? 매우 복잡한 "중국식 보고서" 를 내보내는 방법 (일반적으로 서방 국가에서 나온 보고서보다 훨씬 복잡하며, 많은 오픈 소스 BI 프레임워크도 문제를 완전히 해결할 수 없음)? 정말 어려운 문제가 생기면 바이두나 구글, 컨설팅 회사의 선임 기술자나 전문가, 또는 소규모 기술 세미나를 열어 브레인스토밍을 통해 답을 찾아 생산성을 높일 수 있습니다. 4. 아키텍처 설계 검토 회의를 열고 동료 평가를 받습니다. 건축 설계 검토는 매우 중요한 부분이다. 나는' 7 종 무기' 에서 이별 갈고리로 묘사된 적이 있다. 동료가 회의에서 많은 질문이나 의견을 물어볼 수 있고, 많은 의견이 날카로워서 반드시 겸허하게 받아들이고 기록을 잘 해야 하기 때문이다. 속담에 "좋은 약은 입에 쓰지만 병에 이롭고 충언은 귀에 거슬린다" 는 말이 있다. 심사 회의를 하기 전에, 우리는 반드시 대량의 준비 작업을 완성해야 한다. 가장 중요한 문제를 열거하는 간결한 전자 브리핑을 준비하는 것이 가장 좋다. 이렇게 하면 검토 회의를 진행할 때 목적을 달성하지 않을 것이다. 우리는 회의 전에 이 자료들을 참석자들에게 나누어 줄 테니, 시간을 내서 먼저 알아보도록 하겠습니다. 회의가 진행되는 동안, 회의의 진도를 통제하고, 회의의 효율을 높이는 것을 배워야 한다. 5. 주요 사용 사례의 설계 아키텍처에서 기능을 구현하여 아키텍처를 검증합니다. 아키텍처 설계의 검증도 매우 중요한 작업이며, 검증 기술은 매우 많다. 우리 회사에서는 일반적으로 샘플 형식, 즉 XP 의 반복 0 과 RUP 의 슬라이스를 사용합니다. 이렇게 하면 실제 제품의 관점에서 아키텍처가 요구 사항을 충족하는지 효과적으로 검증할 수 있어 폐기된 프로토타입 검증 기술에 비해 비용을 절감할 수 있다는 장점이 있습니다. 이 샘플은 아키텍처 설계 문제를 해결할 때 실험에 사용하는 코드의 패치 워크가 아니라 아키텍처 설계를 충족하는 완벽한 제공 코드와 관련 문서 및 주요 사용 사례를 구현하는 일련의 사양입니다. 동시에, 이 샘플은 당신이 설명하거나 아키텍처를 훈련시킬 때 교재로 사용할 수 있고, 개발자가 이 프레임워크를 사용하여 개발한 청사진으로 사용할 수 있으며, 심지어 간단한 수정만으로 복사하여 붙일 수도 있습니다. (데이비드 아셀, Northern Exposure (미국 TV 드라마), 예술명언) 6. 검토를 위해 고객에게 전달. 소프트웨어 아키텍처가 반드시 고객 감사를 필요로 하는 것은 아니지만, 우리 같은 서비스 회사에게는 고객의 존중이 가장 중요하기 때문에 많은 기업들이 존재하지 않을 수 있습니다. 소프트웨어 아키텍처 설계를 구현하는 활동은 고객이 아키텍처 설계를 이해하고 받아들이도록 하는 것이며, 고객은 아키텍처를 검증하는 데 도움이 됩니다. 일반적으로 Dell 아키텍처는 고객이 인정한 후 대규모 개발에 들어갈 수 있습니다. 고객 검토를 제공할 때 검토는 일반적으로 회의 형식으로 진행될 수 있으므로 검토 회의의 모범 사례를 참조하여 회의를 열 수 있습니다. 여기서는 자세히 설명하지 않습니다. 소프트웨어 아키텍처 설계에 대한 일반적인 오해와 솔루션 1, 아키텍처 설계는 종종 "높은 수준" 입니다. 너무 높아서 더 이상 높을 수 없다는 것은 사실 우리의 아키텍처 설계가 모델 단계에만 머물러 있지만 결코 첫 번째 샘플 방안이 아니라는 것이다. 아키텍처 설계는 어떤면에서 종종 과도하게 설계됩니다. 전혀 일어나지 않는 변화를 위해 일련의 복잡한 디자인이 이루어졌다. 이러한 설계를 과잉 설계라고 하며, 종종 자원 낭비를 초래하고 개발의 작업량이나 난이도를 증가시킬 수 있습니다. 시스템의 확장성과 서비스 용이성을 고려해야 하지만 지나치게 설계해서는 안 된다. 때로는 어떤 디자인이 과도하게 설계되었는지 판단하지 못할 수도 있습니다. 이때 PM 을 전체 프로젝트의 높이에서 결정하도록 요청할 수 있습니다. 3. 아키텍처는 하나의 틀도 아니고, 몇 개의 틀이나 기술의 간단한 조합도 아니다. 프레임 자체에는 구조가 있습니다. 프레임워크는 일반적으로 어떤 방면이나 분야를 겨냥한 반제품으로, 재사용성과 확장성이 뛰어나다. 우리는 고전적인 말로 요약할 수 있다: 프레임워크는 소프트웨어이고, 아키텍처는 소프트웨어가 아니며, 프레임워크는 특수한 소프트웨어이다. Dell 의 업무에서는 재사용 가능한 많은 도구 클래스, 공용 클래스 및 기본 클래스를 추상화하여 재사용 가능한 프레임워크를 형성할 수 있습니다. 건축 설계는 결코 신기술을 보여주는 플랫폼이 아닙니다. 적절한 기술은 프로젝트에 유익한 기술이며 개발자와 유지 관리 인력의 능력을 고려해야 한다. 건축가로서 Dell 은 이러한 기술적 세부 사항보다는 비즈니스 요구 사항, 직조 작업 (주로 팀워크) 및 기술 간의 관계를 균형 있게 조정하는 방법에 더 많은 관심을 기울여야 합니다. 아키텍처 설계의 성공은 시스템의 품질을 결정합니다. 잘못된 아키텍처 설계로 인해 고객의 비기능적 요구 사항을 충족시킬 수 있는 시스템 버그가 너무 많아서 프로젝트 취소 사례가 자주 발생합니다. 건축 설계는 건축가 한 사람의 일도 아니고, 며칠 만에 완성할 수 있는 것도 아니다. 설계자의 수많은 노력의 결과여야 하며, 성공 또는 실패는 종종 조직, 경영진 및 프로젝트 관리자의 지원과 밀접한 관련이 있습니다. 건축 설계에 관한 몇 가지 일반적인 기술: 1 및 레이어 규칙. 여기서 레이어는 물리적 계층이 아닌 논리적 계층을 나타냅니다. 현재 대부분의 엔터프라이즈 애플리케이션 시스템은 표현 계층, 영역 계층, 데이터 계층의 세 계층으로 나뉩니다. 각 계층을 나눌 때 주로 다음과 같은 측면을 고려할 수 있습니다. A, 각 계층은 상대적으로 독립적인 부분이며, 다른 계층을 알 필요 없이 전체적으로 사용할 수 있습니다. B, 레벨 간의 의존성을 최소화하십시오. 즉, 커플링을 줄입니다. C, 한 레이어에는 어느 정도 대체가 있을 수 있으며, 다른 레이어에는 큰 영향을 미치지 않습니다. D, 등급 시스템은 모든 것을 닫을 수 없습니다. 사용자 인터페이스에 필드를 추가하면 데이터 필드가 도메인 계층에 추가되고 해당 필드가 데이터 계층에 추가됩니다. 또한 계층 수가 너무 많으면 성능에 어느 정도 영향을 줄 수 있습니다. 패키지 간에 순환 종속성이 없습니다. 일반적으로 패키지는 먼저 논리적 계층으로 분할된 다음 해당 계층의 패키지 아래 기능에 따라 나뉩니다. 방 사이의 순환 의존성을 피하는 것은 보편적인 규칙이며, 이러한 규칙에는 반드시 그 존재의 가치와 이유가 있어야 한다. 주된 이유는 다음과 같습니다. A, 순환 의존은 계층화를 무의미하게 만들 수 있습니다. B, 순환 의존은 중첩된 트랜잭션의 현상과 같은 많은 잠재적 위험을 초래할 수 있습니다 (JavaEE 표준은 지원되지 않음). 나는 이런 문제가 발생한 적이 있다. 프로젝트 내에서 트랜잭션은 비즈니스 논리 계층에 배치되어 일관되게 통제됩니다. 그러나 개발자가 아키텍처에서 이 원칙을 무시했기 때문에 지속성 계층에서 계층을 나타내는 공용 클래스가 호출되어 중첩된 트랜잭션이 발생합니다. 디자인 패턴 응용 프로그램. 많은 사람들은 디자인 패턴을 제공하는 것이 GOF 의 디자인 패턴과 같다고 생각합니다. 사실, 디자인 패턴은 수요 패턴, 도메인 패턴, 반 패턴 등과 같은 광범위한 개념입니다. 패턴은 실제로 도구입니다. 과거에 사람들이 특정 유형의 문제를 해결한 경험을 요약한 것입니다. 그래서 우리는 디자인 활동에 다양한 디자인 패턴을 적용할 수 있지만, 이러한 패턴을 적용하기 전에 반드시 문제를 분석해야 합니다. 그렇지 않으면' 소머리가 말부리에 맞지 않는다' 는 현상이 나타날 수 있습니다. 성공한 프로젝트에는 항상 유사점이 있고, 실패한 프로젝트에는 각자의 실패가 있다. 좋은 소프트웨어 아키텍처 설계는 반드시 성공 프로젝트의 유사점이어야 한다. 우리가 소프트웨어 아키텍처 설계를 제대로 하지 못한 이유는 무엇입니까?