"소프트웨어를 만든 이유는 기계의 행위를 쉽게 변경할 수 있도록 하기 위해서다."
시시각각 변화하는 요구사항으로 소프트웨어의 본질은 변화한다.이러한 소프트웨어가 쉽게 변화할 수 있도록 만드는 것이 소프트웨어 개발자의 사명이다.소프트웨어 개발자는 유연한 소프트웨어를 위해 적절히 코드를 나누고, 적절한 곳에 책임을 주어 나누어진 코드끼리 적절한 의존성을 가지게 해야한다.
작업의 정도와 상관없이 요구사항은 언제나 바뀔 수 있다.이때문에 불분명한 요구사항들은 불분명한 채로 나두어 나중에 이를 선택하여(view model) 쉽게 반영(view) 할 수 있도록 좋은 아키텍처와 좋은 설계가 필요로 하다.
쉽게 변화하는 소프트웨어를 만드는 방법1. 바꾸어야 할 부분을 쉽고 명확하게 파악할 수 있어야 한다.2. 변경이 최소한으로 일어나야 한다.
Architecture ?
프로젝트의 전체적인 설계도여러 가지 컴퓨터 구성 요소들에 대한 전반적인 기계적 구조를 설계하는 방법
"하나의 서비스가 어떻게 구성이 되며 동작되는지 서비스의 동작 원리를 나타내는 것"
소프트웨어 아키텍처
- 소프트웨어의 골격이 되는 기본구조 (ex.설계도 평면도)
- 하나의 소프트웨어를 개발할 때 소프트웨어를 어떻게 구조화시켜야 되는지, 상위메뉴와 하위메뉴를 어떻게 배치해야 하는지 등을 결정할 때 참고할 정의 문서
(구성요소 하나하나를 어떻게 관계시킬지에 대한 것)
소프트웨어 아키텍처 설계의 기본 원리
- 모듈화 : 소프트웨어 성능 향상 및 유지관리 등이 용이하도록 시스템의 기능을 모듈단위로 나누는 것
- 추상화 : 전체적이고 포괄적인 개념을 설계한 후에 구체화시켜 나가는 것
- 단계적 분해 : 상위 개념부터 하위 개념으로 구체화 시키는 분할 기법 하향식 설계 전략
- 정보은닉 : 모듈 내부에 정보와 자료들을 숨겨서 다른 모듈이 접근하거나 수정 못하도록 하는 기법)
System Architecture ?
시스템의 구조(structure), 행위(behavior), 뷰(views)를 정의하는 개념 모델이다.시스템의 목적을 달성하기 위해 각 컴포넌트가 어떻게 상호작용하고 정보가 어떻게 교환되는 지를 설명한다.
- 시스템 구성 및 동작 원리를 나타냄
- 구성요소 간의 관계 및 시스템 외부 환경과 관계가 나타남
- 요구사항 및 시스템 전체 수명 주기 고려
- 시스템 전체에 대한 논리적인 기능체계와 실현을 위한 구성방식, 최적화를 목표로함
- 아키텍처 설계, 분석 단계의 방향성 유지
- 아키텍처 설계, 분석 시의 성능을 발휘할 수 있도록 구성
- 다양한 System Architecture가 있지만 목적은 하나로 생각할 수 있다.
➡️ 소프트웨어를 계층으로 나눈 관심사를 분리
⬅️(좌) 스파게티 아키텍쳐 / 클린아키텍쳐 (우)➡️
깔끔하고 직관적인 설계도로 클린 아키텍쳐가 많이 쓰여지고 있다.
시스템 아키텍처와 소프트웨어 아키텍처 차이
Clean Architecture ?
좋은 아키텍처는 이 영역 간의 "경계"(중요한 것과 중요하지 않은 것)를 잘 긋는거부터 시작된다.
컴포넌트 사이에 클래스나 파일을 분리한다.코드가 물리적으로 나누어지고 관리가 쉬워진다.
=> 외부로 부터 영향을 받지 않으며 모든 면에서 독립적인 사용이 가능해서 유지보수가 편리하다.
Domain
layer는 Business Rules(비즈니스 로직이 들어가는 핵심기능)이 존재하는 영역이다.예를들어, 쇼핑몰은 상품만 팔고 번역앱은 번역을 하는 것. 이처럼 비즈니스 본질과 핵심기능이이 쉽게 바뀌지 않으므로 Business Rule은 잘 변하지 않는 안정된 영역이다.추상화된 개념(데이터를 저장한다, 비용을 정산 한다.)
Infrastructure
layer는 UI, Database, web APIs, Frameworks 등이 존재하는 영역이다.추상화된 개념을 실제 어떻게 구현할지에 대한 세부 개념이다.예를들어, 쇼핑몰 상품 구입에 대한 비용 정산을 실행 시킬 버튼 UI. UI버튼 모양은 수시로 변경 가능. 저수준 정책
(inner circle 에 해당하는 Domain과 outer circle 에 해당하는 Infrastructure 사이에 경계가 생겨 도메인은 인프라에 대해서 아무것도 모른다)
도메인 층의 세분화 ?
요소들간의 경계로 이루어진 클린아키텍쳐
도메인의 영역인(코어영역) entity, use case 그리고 View영역인 최상층 Infrastructure, 이 두가지 계층 사이를 이어주는 adaptor가 있다.
Entities
- 애플리케이션 기능에 중요한 비즈니스 규칙으로 엔티티에 영향을 주지 않아야한다데이터 구조, 메소드들(함수)의 집합체이다객체지향 프로그래밍 언어에서는 클래스와 메서드로 함께 그룹화 되어있다핵심 업무 규칙을 캡슐화 한다가장 변하지 않고 외부로부터 영향받지 않는 영역이다다른 것에 대해 아무것도 의존하지 않는다
// 데이터 구조 Movie가 Entities이다.
struct Movie: Equatable, Identifiable {
typealias Identifier = String
enum Genre {
case adventure
case scienceFiction
}
let id: Identifier
let title: String?
let genre: Genre?
let posterPath: String
let overview: String?
let releaseDate: Date? } struct MoviesPage: Equatable {
let page: Int
let totalPages: Int
let movies: [Movie] }Use cases
- Entities에서 데이터를 가져오고 어플리케이션의 동작을 결정하는 비즈니스 규칙시스템의 동작을 사용자의 입장에서 표현한 시나리오Entities와의 데이터 흐름을 조정,조율 한다. (Entities에 영향은 주지 않음)해당하는 Entities가 Use cases의 목표를 달성하도록 “지시”한다데이터베이스, UI, 프레임 워크 등 외부 요소의 변경에 의해 영향을 받지 않는다.
Adapters
- 도메인과 인프라의 사이에 Adapter라는 레이어로 존재한다Controllers, Gateway, Presenters가 속해 있다데이터를 변환(Use cases와 Entities에 가장 편리한 방식으로 변환)(데이터베이스나 웹 같은 외부 에이전시에게 가장 편리한 방식으로 변환)Use case와 동심원의 가장 바깥쪽을 연결해주는 역할
Infrastructure
- DB, 프레임워크 같은 것들로 구성되어 있다시스템의 핵심 업무와는 관련 없는 세부 사항으로 언제든 갈아끼울 수 있다가장 변동성이 높은 계층안정적인 도메인 레이어에서 가능한 멀리 유지 된다.별도로 유지 되기 때문에 비교적 쉽게 구성 요소를 변경할 수 있음
이렇게 관심사를 분리 한 규칙을 의존성 규칙으로 설명할 수 있다.
클린아키텍처의 주요원칙
Dependency rule (종속성 규칙)
- 외부(저수준)에서 내부(고수준)로, 안쪽으로만 카리킬 수 있다
(여기서 의미하는 수준(Level)은 입/출력과의 거리를 의미하는 것) - outer저수준 ➡️ inner고수준 으로 의존성을 가지게 된다.
- 내부의 어떤 것도 외부에선 알 수 없다
- 외부의 어떤 것도 내부에 영향을 미치지 않는다
Abstraction principle (추상화 원리)
- 가장 안쪽에 있는 계층 영역이 제일 추상화된 영역이다
- 바깥영역으로 향할수록 내부 계층을 활용하여 세부사항을 구현한다
- 추상화가 많이 되어 있을수록 고수준이라고 할 수 있다
SOLID (객체 지향 설계 원칙)
- 확장이 가능하며 유지보수 가능한 유연한 소프트웨어 아키텍처를 만들기 위한 5가지 필수원칙
SRP - 단일 책임 원칙: 한 클래스는 하나의 책임만 가져야 한다.
OCP - 개방-폐쇄 원칙: 소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다.
LSP - 리스코프 치환 원칙: 프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다.
ISP - 인터페이스 분리 원칙: 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다.
DIP - 의존성 역전 원칙: 프로그래머는 추상화에 의존해야지, 구체화에 의존하면 안된다