Architectural Design

The Design Process

• Design is the creative process of figuring out how to implement all of the customer’s requirements; the resulting plan is also called the design
설계는 고객의 모든 요구사항을 구현하는 창의적인 과정입니다. 결과적으로 나오는 계획도 설계라고 합니다.
• Early design decisions address the system’s architecture
초기 설계 단계에서는 시스템의 전체적인 구조와 아키텍처에 대한 결정이 이루어집니다.
• Later design decisions address how to implement the individual units
후기 설계 단계에서는 개별적인 모듈이나 유닛들을 어떻게 구현할 것인지에 대한 결정이 이루어집니다.

구조설계 vs. 상세설계

구조 설계

• 전체 시스템의 구성요소와 이들간의 상관
  관계를 식별
• 비기능적 요구사항이 반영되어야 함
• 여러 가능한 대안의 도출 및 검토, 의사결
  정 내역에 대한 문서화가 중요

상세 설계

• 개별 구성요소의 내부 구조를 설계하는 활동. 즉 구현가능한 소프트웨어 단위로 분할하고, 내부 로직 및 인터페이스를 정의

Architecture

• set of rules to define the structure of a system and the interrelationships between its parts (ISO/IEC 10746-2:2009)

시스템의 구조와 그 구성 요소 간의 상호 관계를 정의하는 규칙의 집합

• fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution (ISO/IEC/IEEE 12207:2017)

Client-server vs. Peer-to-Peer

클라이언트-서버 아키텍처는 네트워크 환경에서 가장 일반적으로 사용되는 모델로, 시스템이 클라이언트와 서버로 구분됩니다. 클라이언트는 사용자가 사용하는 인터페이스를 제공하며, 서버는 데이터, 자원 또는 서비스를 제공하고 관리합니다.

P2P 아키텍처는 네트워크에서 모든 참여자가 동등한 권한을 가지며 직접적으로 서로 연결되어 자원을 공유하는 모델입니다. 중앙 서버 없이 각 참여자가 서비스 제공자와 소비자 역할을 동시에 할 수 있습니다

The Design Process

• Design is an intellectually challenging task
  • Numerous possibilities the system must accommodate
  잘 설계된 시스템은 유연하고 다양한 시나리오와 요구사항을 수용할 수 있어야 합니다
  • Nonfunctional design goals (e.g., ease of use, ease to maintain)
  기능 외적 요구 사항(사용성, 유지보수성, 성능, 보안 등) 또한 고려해야 합니다.
  • External factors (e.g., standard data formats, government regulations)
  디자이너는 또한 디자인에 영향을 미칠 수 있는 외부 요인을 고려해야 합니다. 이는 산업 표준, 데이터 형식, 법적 규정 및 기술 트렌드와 같은 요소들을 포함합니다.

• We can improve our design by studying examples of good design

• Most design work is routine design, solve problem by reusing and adapting solutions from similar problems
  디자인의 일부는 창의적인 해결책이 필요한 혁신적인 작업이지만, 대부분의 디자인 작업은 기존의 솔루션과 패턴을 활용하는 루틴한 작업입니다. 검증된 솔루션을 재사용하면 공통 문제를 효율적으로 해결하고 리스크를 줄일 수 있습니다.

---

• Many ways to leverage existing solutions
  기존 솔루션을 활용하는 여러 방법이 있습니다.
  • Cloning: Borrow design/code in its entirety, with minor adjustments
  이미 존재하는 디자인 또는 코드를 전체적으로 빌려오되, 소규모의 조정을 통해 적용하는 방식
  • Reference models: Generic architecture that suggests how to decompose the system
  참조 모델은 일반적인 아키텍처로, 시스템을 어떻게 분해할지 제안하는 지침을 제공합니다

Architectural Styles and Strategies

Client-Server
• Peer-to-Peer
• Layering
• Pipes-and-Filter
• Publish-Subscribe
• Repositories
• Microservice

Client-Server

• Two types of components:
  • Server components offer services
  서버 컴포넌트는 서비스를 제공하는 역할을 합니다.
  • Clients access them using a request/reply protocol
  요청-응답 프로토콜을 통해 서버와 통신하며, 서버가 제공하는 서비스를 이용
• Client may send the server an executable function, called a callback
  • The server subsequently calls under specific circumstances

Peer-to-Peer (P2P)

• Each component acts as its own process and acts as both a client and a server to other peer components.
• Any component can initiate a request to any other peer component.
  P2P 모델에서 각 피어는 자체적으로 서버 역할과 클라이언트 역할을 수행할 수 있습니다. 즉, 어떤 피어도 다른 피어에게 요청을 시작할 수 있습니다
• Characteristics
  • Scale up well
  피어가 추가됨에 따라 확장 가능
  • Increased system capabilities
  P2P 모델은 많은 사용자가 동시에 서비스를 공유하고 사용할 수 있도록 해줍니다.
  • Highly tolerant of failures
  분산된 구조를 가지고 있어 단일 지점의 장애가 시스템 전체에 영향을 미치지 않을 수 있습니다

Layered Architecture

• Layers are hierarchical
  계층 구조
  • Each layer provides service to the one outside it and acts as a client to the layer inside it
  각 레이어는 외부 레이어에 서비스를 제공하고 내부 레이어에 클라이언트 역할을 합니다
  • Layer bridging: allowing a layer to access the services of layers below its lower neighbor
  한 계층이 그 아래 계층의 서비스를 직접적으로 사용할 수 있도록 허용합니다.
• The design includes protocols
  • Explain how each pair of layers will interact
  상호 작용은 정의된 프로토콜을 통해 이루어집니다. 각 계층은 정해진 방식으로 다른 계층과 통신합니다.
• Advantages
  • High levels of abstraction
  각 계층은 특정 기능을 수행하므로 시스템의 복잡성을 줄이고 이해하기 쉽게 만듭니다.
  • Relatively easy to add and modify a layer
  상대적으로 계층 추가 및 수정 용이성
• Disadvantages
  • Not always easy to structure system layers
  시스템의 복잡성에 따라 적절한 계층 구조를 설계하기가 어려울 수 있습니다.
  • System performance may suffer from the extra coordination among layers
  계층 간의 추가적인 조정이 필요할 수 있어 성능 저하가 발생할 수 있습니다

Pipes-and-Filter

• The system has
  • Streams of data (pipe) for input and output
  파이프(Pipe): 입력과 출력의 데이터 스트림을 나타냅니다. 이는 데이터의 흐름 경로를 나타내며, 연속적으로 데이터를 전달합니다.
  • Transformation of the data (filter)
  필터(Filter): 데이터 변환을 수행하는 요소입니다. 각 필터는 입력 데이터를 받아 변환하여 출력 데이터를 생성합니다.
• Several important properties
  • The designer can understand the entire system's effect on input and output as the composition of the filters
  • The filters can be reused easily on other systems
  • System evolution is simple
  시스템의 변화나 확장이 비교적 간단합니다.
  • Allow concurrent execution of filters
  각 필터는 독립적으로 실행될 수 있어 병렬 처리가 가능합니다.
• Drawbacks
  • Encourages batch processing. Not good for handling interactive application
  데이터를 일괄 처리하는 데 적합합니다. 반면 대화형 응용 프로그램과 같은 실시간 처리가 필요한 경우 적합하지 않을 수 있습니다.

Publish-Subscribe

• Components interact by broadcasting and reacting to events
  컴포넌트들이 이벤트를 발행하고 이벤트에 반응하여 상호작용하는 방식을 기반으로 합니다.
  • Component expresses interest in an event by subscribing to it
  • When another component announces (publishes) that event has taken place, subscribing components are notified
    컴포넌트는 자신이 관심 있는 이벤트를 구독하여, 해당 이벤트가 발생했을 때 알림을 받을 수 있습니다.
  • Implicit invocation is a common form of publish-subscribe architecture
  • Registering: subscribing component associates one of its procedures with each event of interest (called theprocedure)
• Characteristics
  • Strong support for evolution and customization
  • Easy to reuse components in other event-driven systems
  • Need shared repository for components to share persistent data
  • Difficult to test

Repositories

리포지토리는 여러 구성 요소가 상호 작용하여 정보를 저장, 검색 및 업데이트하는 중앙 집중식 데이터 저장소 솔루션을 제공

• Two components

  • A central data store
    데이터가 중앙에 저장되는 저장소
  • A collection of components that operate on it to store, retrieve, and update information
    정보를 저장, 검색 및 업데이트하기 위해 작동하는 구성 요소 모음

• The challenge is deciding how the components will interact
  이러한 구성 요소가 중앙 데이터 저장소와 상호 작용하는 방식을 결정하는 것
  • A traditional database: transactions trigger process execution
  • A blackboard: the central store controls the triggering process
  • Knowledge sources: information about the current state of the system’s execution that triggers the execution of individual data accessors

• Major advantage: openness
  • Data representation is made available to various programmers (vendors) so they can build tools to access the repository
  • But also a disadvantage: the data format must be acceptable to all components
  저장소에 사용되는 데이터 형식이 저장소에 액세스하는 모든 구성 요소에서 호환되고 허용되어야 한다는 것입니다.

Microservice architecture

• 마이크로 서비스는 작고, 독립적이며, 느슨하게
  결합되어 있습니다.
• 각 서비스는 작은 개발 팀이 작성/유지관리할
  수 있는 개별 코드베이스입니다.
• 서비스를 독립적으로 배포할 수 있습니다. 팀이
  전체 애플리케이션을 다시 빌드한 후 재배치하지 않고도 기존 서비스를 업데이트할 수 있습니다.
  • 서비스가 해당 데이터 또는 외부 상태를
  유지해야 합니다. 이는 별도의 데이터 레이어가
  데이터 지속성을 처리하는 기존 모델과의
  차이점입니다.
  • 서비스가 잘 정의된 API를 사용하여 서로
  통신합니다. 각 서비스의 내부 구현 세부
  정보는 다른 서비스에서 숨겨집니다

Monolith

다양한 구성 요소(예: 사용자 인터페이스, 비즈니스 로직, 데이터 액세스)가 단일 플랫폼의 단일 프로그램으로 결합된 단일 계층 소프트웨어 애플리케이션을 의미

• 구성 요소는 종종 상호 의존성이 높기 때문에 시스템의 한 부분을 변경하면 잠재적으로 다른 부분에 영향을 줄 수 있습니다.
• 개별 구성요소를 독립적으로 확장하기가 어렵습니다. 확장하려면 전체 애플리케이션을 복제해야 하므로 비효율성이 발생합니다.

Monolith vs. Microservice

Monolith

• 단일 코드베이스: 모든 기능(예: 게시물 처리, 친구 관리, 사진 저장)은 하나의 대규모 애플리케이션의 일부입니다

• 단일 데이터베이스: 전체 애플리케이션이 하나의 중앙 집중식 데이터베이스와 상호 작용합니다.

• 긴밀한 결합: 애플리케이션의 모든 부분이 긴밀하게 통합되어 있어 초기 개발은 더 쉽지만 애플리케이션이 성장함에 따라 관리 및 확장이 더 어렵습니다.

Microservice

• 독립 서비스: 애플리케이션은 더 작고 독립적으로 배포 가능한 서비스로 나뉩니다. 각 서비스는 특정 기능을 처리합니다.

• 분리된 구성 요소: 각 서비스는 독립적으로 작동하므로 유연성이 향상되고 확장이 더 쉬워집니다.

• 다양한 데이터베이스: 각 서비스는 필요에 가장 적합한 데이터베이스 유형(문서 저장소, 그래프 데이터베이스, Blob 저장소)을 사용할 수 있습니다

• 모놀리스: 초기 설정이 더 간단하고 단일 기술 스택이 있으며 성장에 따라 확장 및 유지 관리가 더 어렵습니다.

• 마이크로서비스: 더 복잡한 설정, 여러 기술 스택, 더 쉽게 확장, 유지 관리 및 병렬 개발이 가능합니다.

Combining Architectural Styles

• Actual software architectures rarely based on purely one style
• Architectural styles can be combined in several ways
  • Use different styles at different layers (e.g., overall client-server architecture with server component decomposed into layers)
  예: 전체 시스템은 클라이언트-서버 아키텍처로 구성되지만, 서버 컴포넌트는 레이어드 아키텍처로 분해될 수 있습니다.
  • Use mixture of styles to model different components or types of interaction (e.g., client components interact with one another using publish-subscribe communications
  클라이언트 컴포넌트 간의 상호작용은 퍼블리시-서브스크라이브(publish-subscribe) 통신 방식을 사용할 수 있습니다.
• If architecture is expressed as collection of models, documentation must be created to show relation between models
  이러한 결합된 아키텍처를 명확히 문서화하여, 시스템의 전체 구조와 각 부분의 역할을 이해하고 유지보수할 수 있도록 하는 것입니다.

Architecture Description

아키텍처 설명은 시스템의 구조, 동작, 그리고 시스템이 충족해야 하는 요구사항과 제약 조건을 포괄적으로 나타내는 문서

• Work product of systems and software architecting
  시스템 및 소프트웨어 아키텍팅 과정에서 생성되는 주요 작업 산출물
  • System-of-interest
  • Stakeholders and concerns
    • Goals, expectations, requirements, quality attributes, design constraints, assumptions,
  • Architecture views, architecture models
  • Architecture decisions and rationale
    • justification or reasoning about architecture decision