소프트웨어 디자인과 소프트웨어 아키텍처 비교

누군가 소프트웨어 디자인과 소프트웨어 아키텍처의 차이점을 설명 할 수 있습니까?

더 구체적으로; 누군가에게 당신에게 '디자인'을 제시하라고하면-그들이 무엇을 제시 할 것으로 기대하십니까? '아키텍처'도 마찬가지입니다.

나의 현재 이해는 :

• 디자인 : 시스템의 특정 모듈 / 부분에 대한 UML 다이어그램 / 플로우 차트 / 간단한 와이어 프레임 (UI 용)
• 아키텍처 : 구성 요소 다이어그램 (시스템의 다른 모듈이 서로 다른 시스템과 통신하는 방법을 보여줌), 어떤 언어를 사용해야합니까? 패턴?

틀 렸으면 말해줘. Wikipedia에 http://en.wikipedia.org/wiki/Software_design 및 http://en.wikipedia.org/wiki/Software_architecture 에 대한 기사가 있다고 말했지만 올바르게 이해했는지는 확실하지 않습니다.

당신 말이 맞아 시스템의 아키텍처는 '골격'입니다. 시스템의 최고 수준의 추상화입니다. 어떤 종류의 데이터 스토리지가 존재하는지, 모듈이 서로 상호 작용하는 방법, 어떤 복구 시스템이 있는지. 디자인 패턴과 마찬가지로 MVC, 3 계층 디자인 등의 아키텍처 패턴이 있습니다.

소프트웨어 설계는 개별 모듈 / 구성 요소 설계에 관한 것입니다. 모듈 x의 책임, 기능은 무엇입니까? Y 급? 무엇을 할 수 있고 무엇을 할 수 없습니까? 어떤 디자인 패턴을 사용할 수 있습니까?

간단히 말해서 소프트웨어 아키텍처는 전체 시스템의 디자인에 관한 것이고 소프트웨어 디자인은 모듈 / 컴포넌트 / 클래스 레벨에 중점을 둡니다.

SDLC (Software Development Life Cycle)에 대한 일부 설명에서 그것들은 상호 교환이 가능하지만, 그것들은 서로 다르다는 결론입니다. 그들은 동시에 서로 다른 (1) 단계 , (2) 책임 영역 및 (3) 의사 결정 수준입니다 .

• 아키텍처 는 더 큰 그림입니다. 프레임 워크, 언어, 범위, 목표 및 높은 수준의 방법론 ( Rational , Waterfall , Agile 등) 선택.
• 디자인 은 더 작은 그림입니다. 코드 구성 방법에 대한 계획; 시스템의 다른 부분 간의 계약이 어떻게 보일지; 프로젝트 방법론과 목표의 지속적인 구현 . 이 단계에서 사양이 작성됩니다.

이 두 단계는 서로 다른 이유로 혼합되어있는 것 같습니다 .

1. 소규모 프로젝트는 계획을 단계적으로 분리 할 수있는 범위가 충분하지 않은 경우가 많습니다.
2. 프로젝트는 더 큰 프로젝트의 일부일 수 있으므로 두 단계의 일부가 이미 결정되었습니다. (기존의 데이터베이스, 규칙, 표준, 프로토콜, 프레임 워크, 재사용 가능한 코드 등이 이미 있습니다.)
3. SDLC에 대한 새로운 사고 방식 ( 민첩한 방법론 참조 )은이 전통적인 접근 방식을 다소 재정렬합니다. SDLC 전체에서 설계 (아키텍처의 범위가 작음) 가 의도적으로 발생 합니다. 전체 프로세스가 계속 반복 되는 반복 횟수 가 더 많습니다 .
4. 소프트웨어 개발은 ​​복잡하고 어쨌든 계획하기가 어렵지만, 클라이언트 / 관리자 / 영업 사원은 일반적으로 중간 단계에서 목표와 요구 사항을 변경하여 더 어렵게 만듭니다. 계획이든 아니든 프로젝트 후반에 설계 및 건축 결정을 내려야 합니다 .

책임의 단계 나 영역이 서로 섞여서 모든 곳에서 발생하더라도, 어떤 수준의 의사 결정이 이루어지는 지 항상 아는 것이 좋습니다. (우리는 이것으로 영원히 갈 수 있습니다. 요약을 유지하려고 노력하고 있습니다.) 다음으로 끝날 것입니다 : 프로젝트에 공식적인 건축 또는 설계 단계 / AOR / 문서가없는 것 같더라도 누구나 의식적으로하고 있는지 아닌지 아무도 아키텍처를 결정하지 않으면 기본 상태가 좋지 않을 수 있습니다. 디자인을위한 디토. 공식적인 단계가없는 경우 이러한 개념은 거의 더 중요 합니다.

건축은 전략적이며 디자인은 전술적입니다.

아키텍처는 프레임 워크, 툴, 프로그래밍 패러다임, 컴포넌트 기반 소프트웨어 엔지니어링 표준, 높은 수준의 원칙으로 구성됩니다.

디자인은 디자인 패턴, 프로그래밍 관용구 및 리팩토링과 같은 로컬 제약 조건과 관련된 활동입니다.

건축과 디자인을 간단히 구분할 때이 점을 발견했습니다.
당신은 그들을 보는 이런 방식에 대해 어떻게 생각하십니까?

• 건축은 우리가 만들고있는 "무엇"입니다.
• 디자인은 우리가 만들고있는 "어떻게"입니다.

1. 아키텍처는 컴퓨터 또는 컴퓨터 기반 시스템의 개념적 구조와 논리적 구성을 의미합니다.

   디자인은 시스템이나 개체를 만들기 전에 모양과 기능 또는 작업을 보여주기 위해 제작 된 계획이나 그림을 의미합니다.

2. 구성 요소를 "아키텍처"하는 경우 더 큰 시스템에서 구성 요소의 동작 방식을 정의합니다.

   동일한 구성 요소를 "설계"하는 경우 내부적으로 작동하는 방식을 정의하고 있습니다.

모든 아키텍처는 디자인이지만 모든 디자인이 아키텍처는 아닙니다.

What부분은 디자인의이 How구체적인 구현과의 교점 What및 How아키텍처이다.

차별화 된 아키텍처 및 디자인 이미지 :

건축 적으로 중요하지 않은 설계 결정도 있습니다. 즉, 설계의 아키텍처 분기에 속하지 않습니다. 예를 들어, 알고리즘 선택, 데이터 구조 선택 등과 같은 일부 구성 요소의 내부 설계 결정

구성 요소 경계 외부에서 보이지 않는 모든 설계 결정은 구성 요소의 내부 설계이며 아키텍처가 아닙니다. 시스템 설계자가 시스템 레벨 아키텍처에 의해 부과 된 구조적 제약을 위반하지 않는 한, 시스템 설계자가 모듈 설계자의 재량 또는 구현 팀에 맡길 설계 결정입니다.

좋은 비유 를주는 링크

나는 당신이 내 말로 옳다고 말하고 싶습니다.

아키텍처 는 시스템 요구 사항을 시스템 요소에 할당하는 것입니다. 아키텍처에 대한 네 가지 진술 :

1. 언어 나 패턴과 같은 비 기능적 요구 사항을 도입 할 수 있습니다.
2. 구성 요소, 인터페이스, 타이밍 등의 상호 작용을 정의합니다.
3. 새로운 기능을 도입하지 않아야합니다.
4. 시스템이 수행 할 (설계된) 기능을 요소에 할당합니다.

아키텍처는 시스템의 복잡성이 세분화 될 때 필수적인 엔지니어링 단계 입니다.

예 : 집에 대해 생각해보십시오. 부엌에 건축가가 필요하지 않지만 (단 하나의 요소 만 필요) 완전한 건물에는 문 및 지붕과 같은 상호 작용 정의가 필요합니다 .

디자인 은 함수의 (제안 된) 구현에 대한 유익한 표현입니다. 피드백을 유도하고 이해 관계자와 논의하기위한 것입니다. 모범 사례 일 수 있지만 필수적인 엔지니어링 단계는 아닙니다 .

부엌을 설치하기 전에 부엌 디자인을 보는 것이 좋겠지 만 요리 요구 사항에는 필수적이지 않습니다 .

내가 생각하면 다음과 같이 말할 수 있습니다.

• 아키텍처는보다 상세한 추상화 수준의 공공 / 엔지니어를위한 것입니다
• 디자인은 덜 상세한 추상화 수준에서 대중을 대상으로합니다.

내 알림 :

• 누군가에게 묻지 않고 디자인을 바꿀 수 있습니다
• 아키텍처를 변경하면 다른 사람 (팀, 고객, 이해 관계자 등)에게 전달해야합니다.

디자인과 아키텍처에 대해 이야기 할 때 다음 규칙을 사용하여 결정해야한다고 생각합니다. 작성한 소프트웨어 그림의 요소를 프로그래밍 언어 구문 구성에 일대일로 맵핑 할 수 있으면 아키텍처가 아닌 경우 디자인입니다.

예를 들어, 클래스 다이어그램 또는 시퀀스 다이어그램이 표시되는 경우 클래스 구문 구성을 사용하여 클래스 및 해당 관계를 오브젝트 지향 프로그래밍 언어에 맵핑 할 수 있습니다. 이것은 분명히 디자인입니다. 또한이 논의는 소프트웨어 시스템을 구현하는 데 사용할 프로그래밍 언어와 관련이 있다는 표를 가져올 수 있습니다. Java를 사용하는 경우 Java는 객체 지향 프로그래밍 언어이므로 이전 예제가 적용됩니다. 패키지와 그 종속성을 보여주는 다이어그램을 생각해 내면 디자인도 마찬가지입니다. 요소 (이 경우 패키지)를 Java 구문 구성에 맵핑 할 수 있습니다.

이제 Java 애플리케이션이 모듈로 분할되고 각 모듈이 패키지 세트 (jar 파일 배치 단위로 표시됨)이고 모듈 및 해당 종속성을 포함하는 다이어그램 (즉, 아키텍처)이 있다고 가정하십시오. Java (적어도 Java 7까지는 아님)는 모듈 (패키지 세트)을 구문 구조에 매핑하는 방법이 없습니다. 이 다이어그램은 소프트웨어 모델의 추상화 수준에서 한 단계 높은 단계를 나타냅니다. 패키지 다이어그램 위 (거친 입자)는 Java 프로그래밍 언어로 개발할 때 아키텍처 뷰를 나타냅니다. 반면에 Modula-2에서 개발하는 경우 모듈 다이어그램은 설계를 나타냅니다.

( http://www.copypasteisforword.com/notes/software-architecture-vs-software-design 의 조각 )

개인적으로 나는 이것을 좋아한다.

"디자이너는 사용자가 버튼을 눌렀을 때 어떤 일이 발생하는지, 건축가는 1 만 명의 사용자가 버튼을 눌렀을 때 어떤 일이 발생하는지에 관심을 갖고 있습니다."

Mark Cade와 Humphrey Sheil의 SCEA for Java ™ EE 학습 안내서

나는 많은 설명에 동의합니다. 본질적으로 우리는 건축 설계와 소프트웨어 시스템의 세부 설계 사이의 차이점을 인식하고 있습니다.

설계자의 목표는 개발에 필요한만큼 정확하고 구체적으로 사양을 세우는 것입니다. 설계자는 기본적으로 세부 설계가 시작되는 데 필요한만큼 시스템의 구조와 전역 동작을 지정하는 것을 목표로합니다.

훌륭한 설계자는과 규격을 방지 할 것입니다.-아키텍처를 과도하게 지정하지 말고 충분해야합니다. (건축 적) 결정은 가장 비용이 많이 드는 위험을 처리하고 프레임 워크 ( "공통성")를 효과적으로 제공 할 수있는 측면에 대해서만 수립해야합니다. 상세한 설계는 로컬 기능에 대한 가변성에 따라 수행 될 수있다.

실제로 아키텍처 프로세스 또는 수명주기는이 주제를 따르기 때문에 (건축 적으로) 중요한 비즈니스 요구 사항에 대한 구조를 간략하게 설명하고보다 구체적인 결과물을 위해 설계 단계에 세부 정보를 남겨 두는 적절한 추상화 수준을 따릅니다.

건축은 디자인이지만 모든 디자인이 건축적인 것은 아닙니다. 따라서 엄밀히 말하면 건축 설계 와 비 건축 설계 를 구별하는 것이 더 합리적 입니다. 그리고 차이점은 무엇입니까? 때에 따라 다르지! 각 소프트웨어 아키텍트는 다른 답변 (ymmv!)을 가질 수 있습니다. 우리는 휴리스틱을 개발하여 '클래스 다이어그램은 아키텍처이고 시퀀스 다이어그램은 디자인'과 같은 답을 제시합니다. 자세한 내용은 DSA 서적 을 참조하십시오 .

아키텍처가 디자인보다 추상화 수준이 높거나 아키텍처가 논리적이고 디자인이 물리적이라고 말하는 것이 일반적입니다. 그러나이 개념은 일반적으로 받아 들여지지 만 실제로는 쓸모가 없습니다. 높은 추상화 또는 낮은 추상화, 논리 및 물리 사이의 선을 어디에서 그리나요? 때에 따라 다르지!

그래서 내 제안은 다음과 같습니다.

• 단일 디자인 문서를 작성하십시오.
• 이 디자인 문서의 이름을 원하는 방식으로 지정하거나 독자가 더 익숙한 방식으로 지정하십시오. 예 : "소프트웨어 아키텍처", "소프트웨어 디자인 사양"
• 이 문서를 여러 뷰로 나누고 다른 뷰를 구체화하여 뷰를 만들 수 있습니다.
• 상호 참조 또는 하이퍼 링크를 추가하여 문서의보기를 탐색 가능하게 설정
• 그러면 디자인의 넓지 만 얕은 개요를 보여주는 높은 수준의 뷰와 좁지 만 깊은 디자인 세부 사항을 보여주는 구현에 가까운 뷰가 제공됩니다.
• 멀티 뷰 아키텍처 문서의 예 ( here )를 살펴볼 수 있습니다 .

모든 것을 말했듯이 ... 우리가 물어봐야 할 더 관련성있는 질문은 : 얼마나 많은 디자인이 충분합니까? 즉, 설계 설명 (도표 또는 산문)을 언제 중단하고 코딩으로 넘어 가야합니까?

그렇습니다. 디자인은 당신이 할 일이며, 아키텍처는 디자인의 비트와 조각이 결합되는 방식입니다. 언어에 구애받지 않지만 일반적으로 LAMP v Windows, 웹 서비스 v RPC 등 사용할 기술을 지정합니다.

프로그램 또는 컴퓨팅 시스템의 소프트웨어 아키텍처는 시스템의 구조 또는 구조이며, 이는 소프트웨어 구성 요소, 이러한 구성 요소의 외부에서 보이는 특성 및 이들 사이의 관계를 포함합니다.

(Wikipedia, http://en.wikipedia.org/wiki/Software_architecture에서 )

소프트웨어 디자인은 소프트웨어 솔루션에 대한 문제 해결 및 계획 프로세스입니다. 소프트웨어의 목적과 사양이 결정되면 소프트웨어 개발자는 디자이너를 설계하거나 고용하여 솔루션 계획을 개발합니다. 여기에는 아키텍처 수준뿐만 아니라 하위 수준의 구성 요소 및 알고리즘 구현 문제가 포함됩니다.

(Wikipedia, http://en.wikipedia.org/wiki/Software_design에서 )

더 나 자신을 더 잘 말할 수 없었습니다 :)

Patrick Karcher가하는 것처럼 건축을 봅니다. 예를 들어, 건물에 건축물을 제공하고 구조적 지지대, 창문, 출입구, 배수 등을 볼 수 있습니다. 그러나 바닥 배치, 칸막이 위치 등을 "설계"하지 않았습니다.

따라서 건물을 설계하는 동안 각 사무실의 레이아웃을 설계하지 않았습니다. 소프트웨어도 마찬가지입니다.

그래도 레이아웃 디자인을 "레이아웃 아키텍처"로 볼 수 있습니다 ...

좋은 질문입니다. 그들 사이의 선이 밝은 선은 아니지만, imho, 두 용어를 모두 사용하는 경우 Architecture는 무언가를 구축하거나 구성하는 방법, 특히 어려운 결정에 대한 더 기술적 또는 구조적 결정을 포함합니다. 한 번 구현 된 후에는 변경하기 어려운 반면, Design에는 나중에 변경하기 쉬운 방법 (메소드 이름, 클래스 <-> 파일 구성 구조, 디자인 패턴, 특정 문제를 해결하기 위해 싱글 톤 또는 정적 클래스 사용 여부 등)이 포함됩니다. 등) 및 / 또는 시스템 또는 애플리케이션의 외관 또는 미적 측면에 영향을 미치는 요소 (인간 인터페이스, 사용 편의성, 모양 및 느낌 등)

소프트웨어 아키텍처 는 계산의 알고리즘과 데이터 구조를 넘어서 "문제"로 간주됩니다.

아키텍처는 구체적으로 구현 세부 사항 (예 : 알고리즘 및 데이터 구조)에 관한 것이 아닙니다. 아키텍처 디자인에는 일반적으로 OOD (오브젝트 지향 디자인)에서 제공하는 것보다 더 풍부한 추상화 모음이 포함됩니다.

디자인 은 디자인 요소의 모듈화 및 세부 인터페이스, 알고리즘 및 절차, 아키텍처를 지원하고 요구 사항을 충족시키는 데 필요한 데이터 유형과 관련이 있습니다.

"아키텍처"는 종종 "디자인"의 단순한 동의어로 사용되기도합니다 (때로는 형용사 "높은 수준"이 앞에옵니다). 그리고 많은 사람들이“건축 패턴”이라는 용어를“디자인 패턴”의 동의어로 사용합니다.

이 링크를 확인하십시오.

용어 아키텍처, 디자인 및 구현 정의

아키텍처 :
구조 설계는 시스템에 기술적으로 중요한 요구 사항을 실현하는 더 높은 수준의 추상화에서 작동합니다. 이 아키텍처는 추가 설계를위한 토대를 마련합니다.

디자인 :
각 추상화 계층에서 반복 프로세스를 통해 아키텍처가 수행하지 않는 것을 채우는 기술.

아키텍처와 디자인을 분리하는 데있어이 논문을 좋아했습니다.

http://www.eden-study.org/articles/2006/abstraction-classes-sw-design_ieesw.pdf

이를 Intension / Locality 가설이라고합니다. 로컬이 아니며 강렬한 소프트웨어의 특성에 대한 설명은 구조적입니다. 지역적이고 강렬한 진술은 디자인입니다.

... 오래 전에 철학자들은 멀리있는 한 곳에서 많은 사람과의 구별에 대해 걱정했습니다. 건축은 관계에 관한 것이며, 많은 것이 필요합니다. 아키텍처에는 구성 요소가 있습니다. 디자인은 콘텐츠에 관한 것이며, 콘텐츠가 필요합니다. 디자인에는 속성, 품질, 특성이 있습니다. 우리는 일반적으로 디자인이 아키텍처 내에 있다고 생각합니다. 이원론 적 사고는 많은 사람들에게 원시적이다. 그러나 아키텍처도 디자인 내에 있습니다. 그것은 우리 앞에있는 것을 하나 또는 많은 것으로보기 위해 선택하는 방법입니다.

꽤 주관적이지만 내 테이크 :

아키텍처 다른 시스템과의 상호 작용, 하드웨어 요구 사항, 전체 구성 요소 디자인 및 데이터 흐름을 포함한 시스템의 전체 디자인.

디자인 전체 시스템에서 구성 요소의 구성 및 흐름. 여기에는 다른 구성 요소와의 상호 작용을위한 구성 요소의 API도 포함됩니다.

소프트웨어 아키텍처는 비즈니스 및 기능을 높은 아키텍처 수준으로 식별하여 응용 프로그램에 프로젝트를 계획해야 할 때 시스템 수준에서 가장 잘 사용됩니다.

예를 들어, 귀하의 비즈니스는 거래자에 대한 "이익과 손실"에 관한 것이며 주요 기능에는 "포트폴리오 평가"및 "위험 계산"이 포함됩니다.

그러나 소프트웨어 아키텍트 가 솔루션을 자세히 설명하면 다음과 같은 사실을 알게됩니다.

"포트폴리오 평가"는 하나의 응용 프로그램이 될 수 없습니다. 다음과 같은 관리 가능한 프로젝트에서 개선해야합니다.

• GUI
• 발사통
• 디스패처
• ...

(관련 작업이 너무 커서 여러 컴퓨터로 분할해야하지만 공통 GUI를 통해 항상 모니터링해야 함)

소프트웨어 설계는 다양한 응용 프로그램, 기술적 관계 및 내부 하위 구성 요소를 검사합니다.
마지막 아키텍처 계층 ( "기술 아키텍처")이 기술 프레임 워크 또는 횡단 구성 요소 측면에서 작업하고 프로젝트 팀 ( 비즈니스 기능 구현에 더 중점 을두기)에 필요한 사양을 생성합니다. 각각의 프로젝트.

누군가가 배를 만들면 엔진, 선체, 전기 회로 등이 그의 "건축 요소"가 될 것입니다. 그를 위해 엔진 구성은 "디자인 작업"이 될 것입니다.

그런 다음 엔진 구성을 다른 팀에 위임하면 "엔진 아키텍처"가 생성됩니다.

따라서 추상화 또는 세부 수준에 따라 다릅니다. 한 사람의 건축은 다른 사람의 디자인 일 수도 있습니다!

아키텍처는 "변경하기 어려운 디자인 결정"입니다.

실제로 디자인이 항상 변한다는 것을 의미하는 TDD로 작업 한 후 종종이 질문으로 어려움을 겪고 있습니다. 위의 정의는 Martin Fowler 의 Enterprise Application Architecture의 패턴 에서 추출되었습니다.

이는 아키텍처가 시스템의 언어, 프레임 워크 및 도메인에 의존한다는 것을 의미합니다. 5 분 안에 Java 클래스에서 인터페이스를 추출 할 수 있다면 더 이상 아키텍처 결정이 아닙니다.

클리프 노트 버전 :

디자인 : 원하는 제품의 사양을 기반으로 솔루션을 구현합니다.

아키텍처 : 설계를 지원하는 기초 / 도구 / 인프라 / 구성 요소

이것은 많은 반응을 불러 일으킬 꽤 광범위한 질문입니다.

아키텍처는 시스템을 구축하기위한 디자인 패턴 모음입니다.

디자인이이 모든 것을 하나로 모으는 데 사용 된 창의력이라고 생각합니다.

소프트웨어 설계는 역사가 더 길지만 소프트웨어 아키텍처라는 용어는 거의 20 년이되었습니다. 따라서 지금은 고통이 커지고 있습니다.

학계는 아키텍처를 더 큰 소프트웨어 디자인 분야의 일부로 보는 경향이 있습니다. 아치는 그 자체로 필드라는 인식이 커지고 있지만.

실무자들은 아치를 전략적이며 실행 취소하는 데 비용이 많이 드는 고급 설계 결정으로 간주하는 경향이 있습니다.

아치와 디자인 사이의 정확한 선은 소프트웨어 도메인에 따라 다릅니다. 예를 들어, 웹 응용 프로그램 영역에서 계층 구조는 현재 가장 인기를 얻고 있습니다 (Biz Logic Layer, Data Access Layer 등).이 Arch의 하위 레벨 부분은 디자인 (클래스 다이어그램, 메소드 서명 등)으로 간주됩니다. ) 이것은 임베디드 시스템, 운영 체제, 컴파일러 등의 도메인에서 다르게 정의됩니다.

아키텍처는 높은 수준의 추상적이며 논리적 인 디자인이지만 소프트웨어 디자인은 낮은 수준의 세부적이고 물리적 인 디자인입니다.

또한 다음을 참조하십시오 : http://en.wikipedia.org/wiki/4%2B1_Architectural_View_Model

로이 토마스 필딩 (Roy Thomas Fielding)의 논문에서 소프트웨어 아키텍처가 무엇인지에 대한 정의와 설명 : 건축 스타일과 네트워크 기반 소프트웨어 아키텍처 디자인

소프트웨어 아키텍처는 운영 단계 중 소프트웨어 시스템의 런타임 요소를 추상화 한 것입니다. 시스템은 각각 자체 소프트웨어 아키텍처가있는 여러 수준의 추상화와 여러 단계로 구성 될 수 있습니다.

그는 "런타임 요소"와 "추상화 수준"을 강조합니다.

"소프트웨어 아키텍처"와 "소프트웨어 디자인"은 상당히 많은 정의를 가지고 있고 정식 정의도 없기 때문에 이에 대한 명확한 답은 없습니다.

이것을 생각하는 좋은 방법은 Len Bass, Paul Clements, Rick Kazman의 말이다. "모든 아키텍처는 디자인이지만 모든 디자인은 아키텍처가 아니다"[Software Architecture in Practice] 아키텍처에 다른 활동이 포함될 수 있기 때문에 이에 동의하지는 않지만 아키텍처는 디자인의 중요한 하위 세트를 처리하는 디자인 활동이라는 본질을 포착합니다.

약간의 플립 팬트 정의 ( SEI 정의 페이지에 있음 )는 잘못 결정한 경우 프로젝트가 취소되도록하는 일련의 결정입니다.

몇 년 전 Amnon Eden과 Rick Kazman은 "건축, 설계, 구현"이라는 제목의 연구 논문에서 아키텍처, 설계 및 구현을 개념으로 분리하려는 유용한 시도를 수행했습니다. http : //www.sei.cmu .edu / library / assets / ICSE03-1.pdf . 그들의 언어는 상당히 추상적이지만 간결하게 말하면 아키텍처 는 많은 맥락에서 사용될 수있는 디자인 이며 시스템 전체에 적용될 수 있으며, 많은 맥락에서 사용될 수 있지만 특정 부분에 적용될 수있는 (err) 디자인입니다. 시스템의 구현에 따라 구현 은 컨텍스트에 따라 디자인되어 해당 컨텍스트에 적용됩니다.

따라서 아키텍처 결정은 RPC가 아닌 메시징을 통해 시스템을 통합하기로 결정한 것일 수 있습니다 (따라서 여러 곳에서 적용 할 수 있고 전체 시스템에 적용 할 수있는 일반적인 원칙). 설계 결정은 마스터를 사용하는 것일 수 있습니다. 시스템의 입력 요청 처리 모듈에서 / slave 스레드 구조 (어디서나 사용할 수 있지만이 경우 하나의 모듈에서 사용되는 일반적인 원칙) 및 마지막으로 구현 결정은 요청 라우터에서 보안에 대한 책임을 옮기는 것일 수 있습니다. 요청 관리자 모듈의 요청 핸들러 (해당 컨텍스트에서 사용되는 해당 컨텍스트에만 관련된 결정)

이게 도움이 되길 바란다!