[프론트엔드] 소프트웨어 아키텍처와 디자인패턴(1)

시작하며

요즘 더 좋은 코드를 작성하기 위해서 많은 고민을 하던중이다. 최근에는 커스텀 훅을 사용하여 코드의 반복성을 줄이고, 페이지 내에서 코드를 좀 더 간편히 볼 수 있도록 만들어 보았다. 하지만 이것은 전체 집을 설계할 때, 아주 마이너한 부분인것 같다. 블럭 단위로 코드를 잘 작성하는 법이라고 할 수 있겠다. 나는 좀 더 큰 부분에서, 개발하기 용이한 아키텍처에 대해 고민하게 되었다. 그래서 오늘은 디자인 패턴에 대해 공부해 보려고 한다.

소프트웨어 아키텍처 - 아키텍처와 디자인의 차이

근데 개념부터 확실히 하고 넘어가야겠다. 나는 소프트웨어 아키텍쳐와 소프트웨어 디자인의 차이점을 정확히 모른다. 둘의 경계가 모호하기도 하고, 그 요소를 섞어쓰는 경우가 있는 것 같다.

소프트웨어 아키텍처 : 유연성, 확장성, 실행 가능성, 재사용성 및 보안과 같은 소프트웨어 특성을 기술 및 비즈니스 기대치를 충족하는 구조화된 솔루션으로 변환하는 프로세스. 아키텍처 특성(architecture characteristic), 아키텍처 결정(architecture decision), 설계 원칙(design principle) 이 결합된 시스템의 구조(structure)

• 아키텍처 특성: 시스템의 기능과 직교하는 시스템의 성공 기준(성능, 확장성, 신뢰성, 활용성, 유지보수성, 접근성, 보안성, 사용성 등)
• 아키텍처 결정: 시스템 구축에 필요한 규칙들을 정하는 것. 시스템의 제약 조건을 형성
• 설계 원칙: 시스템 구축에 필요한 가이드라인을 정하는 것

소프트웨어 디자인 패턴: 코드 레벨의 디자인(각각의 모듈이 어떤 역할을 수행하는지, 클래스 범위, 함수의 목적 등). 소프트웨어의 특정 구현을 직접 제공하지는 않지만, 반복되는 문제 상황들을 최적화된 방법으로 해결하도록 돕는 역할. 어떻게 코드를 작성할 것인가에 대한 방법론

소프트웨어 아키텍처의 정의

• 유연성, 확장성, 실행 가능성, 재사용성 및 보안과 같은 소프트웨어 특성을 기술 및 비즈니스 기대치를 충족하는 구조화된 솔루션으로 변환하는 프로세스

정의만으로는 정확히 이해하기가 어렵다… 다음으로는 특성을 알아보자.

소프트웨어 아키텍처의 특성

대부분의 사람들은 이전에 “MicroServices” 라는 용어를 들어본 적이 있을 것이다. Layered Pattern, Event-Driven Pattern, Serverless Pattern 등과 같은 다른 많은 소프트웨어 아키텍쳐 패턴 중 하나이다. 마이크로서비스 패턴은 Amazon 과 Netflix 에 채택되어 큰 영향을 미치면서 명성을 얻었다.

Serverless Architecture

서버 및 백엔드 관리의 복잡성을 관리하기 위해 타사 서비스에 의존하는 애플리케이션 솔루션이다. 서버리스 아키텍처는 두 가지 주요 범주로 나뉜다.

• 첫 번째는 “서비스로서의 백엔드(BaaS)” 이고 두 번째는 “서비스로서의 기능(FaaS)”
• 서버리스 아키텍처는 배포 및 서버 일반 작업의 버그를 관리하고 수정하는 데 많은 시간을 절약하는데 도움이 된다.
• 서버리스 API 의 가장 유명한 공급자는 Amazon AWS “Lamda’ 이다.

Event-Driven Architecture

이벤트 생산자와 이벤트 소비자에 따라 달라진다. 이벤트 생산자는 어떤 이벤트 소비자가 어떤 이벤트를 listen 하고 있는지 알지 못한다. 다른 소비자는 누가 어떤 이벤트를 수신하는지 알 수 없다. -> 따라서 주요 아이디어는 시스템의 일부를 분리하는 것.

… 정확히 어떤 아키텍처인지 모르겠다. 자세한 사항은 마이크로소프트 documentation 을 참고하자.

MicroServices Architecture

마이크로서비스 아키텍처는 지난 몇 년 동안 가장 인기 있는 아키텍처가 되었다. 각 서비스가 특정 문제를 해결하거나 고유 작업을 수행하는

• 작고 독립적인 모듈식 서비스 개발
• 모듈은 잘 정의된 API 를 통해 서로 통신하여 비즈니스 목표를 달성

소프트웨어 설계

• 소프트웨어 아키텍처: 소프트웨어의 골격과 상위 수준 인프라를 담당
• 소프트웨어 설계 : 각 모듈이 수행하는 작업, 클래스 범위 및 기능 목적 등과 같은 코드 수준 설계를 담당

개발자라면 SOLID 원칙이 무엇인지, 디자인 패턴이 일반적인 문제를 어떻게 해결해야 하는지 아는것이 중요하다. 이러한 것들을 미리 익혀두면, 자연스럽게 내가 작성하는 코드는 기본원칙을 따르면서 내가 생각하는 좋은 코드가 될 것이다.

SOLID 의 다섯가지

• Single Responsibility, Open Closed, Liskov substitution, Interface Segregation amd Dependency Inversion Principles
• 단일 책임 원칙: 각 클래스는 하나의 단일 목적, 책임, 바꾸는 이유를 가져야 한다.
• 개방형 폐쇄 원칙: 클래스는 확장에는 열려 있어야 하지만, 수정에는 닫혀야 한다. 클래스에는 더 많은 기능을 추가할 수 있어야 하지만, 현재 기능을 사용하는 기존 코드를 손상시키는 방식으로 현재 기능을 편잽해서는 안된다.
• Liskove 대체 원칙:
• 인터페이스 분리 원칙: 클래스는 여러 인터페이스를 구현할 수 있다. 클래스가 목적에 중요하지 않은 기능을 강제로 구현하지 않도록 코드를 구성해야 한다. 따라서, 인터페이스를 분류해야 한다.
• 종속성(의존성) 역전 원칙: 유연성이 극대화된 코드를 설계하기 위해 만든 원칙. 소스 코드 의존성이 추상에 의존하며 구체에는 의존하지 않는 것을 의미

출처

마이크로소프트 공식문서

# Software Architecture - The Difference Between Architecture and Design

https://velog.io/@st_hwang/babwm67z