아키텍처와 의존성

1. 아키텍처(architecture)란?

• 소프트웨어 시스템의 아키텍처란, 시스템을 구축했던 사람들이 만들어낸 시스템의 형태이다.
• 그 모양은 시스템을 컴포넌트로 분할하는 방법, 분할된 컴포넌트를 배치하는 방법, 컴포넌트가 서로 의사소통하는 방식에 따라 정해진다.
• 그리고 그 형태는 아키텍처 안에 담긴 소프트웨어 시스템이 쉽게 개발, 배포, 운영, 유지보수될 수 있도록 만들어진다.

 
우리는 흔히 '설계'한다고 하지만, 설계와 아키텍처의 경계는 명확히 구분할 수 없다.
아키텍처는 고수준의 무언가를, 설계는 저수준의 구조 또는 결정사항을 의미할 때가 많지만
실제 아키텍트가 하는 일을 살펴보면 이러한 구분은 무의미하다.
 

2. 아키텍처의 종류들

• 레이어드 아키텍처(Layered architecture)
• 헥사고날 아키텍처(Hexagonal architecture)
• 이벤트 기반 아키텍처(EDD)
• 마이크로 서비스 아키텍처(MSA)
• 서비스 지향 아키텍처(SOA)
• 등등…

 

3. 아키텍처 탄생의 배경과 목적

• 시스템이 제대로 동작하는 것과 좋은 아키텍처를 갖추는 것은 다른 것이다.
• 아키텍처의 주된 목적은 시스템의 생명 주기를 지원하는 것이다.
• 좋은 아키텍처는 시스템을 쉽게 이해하고, 쉽게 개발하며, 쉽게 유지보수하고, 쉽게 배포할 수 있게 해야 한다.
• 아키텍처의 궁극적인 목표는 시스템의 수명과 관련된 비용은 최소화하면서 프로그래머의 생산성은 최대화하는 데에 있다.

 

개발 관점

• 팀 구조가 다르다면 아키텍처 관련 결정에도 차이가 난다.
• 팀이 작은 규모라면 서로 효율적으로 협력하며 모놀리식 시스템을 개발할 수 있다.
• 그러나 한 시스템에 여러 팀이 개발을 한다면, 인터페이스를 잘 갖춘, 잘 설계된 컴포넌트 단위로 분리하지 않으면 개발이 진척되지 않는다. 

 

배포 관점

• 배포 비용이 높을수록 시스템의 유연성이 떨어진다. 따라서, 소프트웨어 아키텍처는 시스템을 한 번에 쉽게 배포할 수 있도록 만드는 데 그 목표를 두어야 한다.
• 개발 초기부터 이를 고려해야, 후에 배포 비용이 높은 아키텍처가 될 가능성을 줄여준다.

 

운영 관점

• 보통은 개발, 유지보수에 미치는 영향보다는 작다.
• 운영에서 겪는 어려움은 단순히 하드웨어 스케일 업을 통해 해결할 수 있다.
• 하지만 쉽게 운영하게 해주는 아키텍처는 당연히 바람직하다!!

 

유지보수 관점

• 소프트웨어 시스템에서 가장 비용이 많이 든다.
• 유지보수의 가장 큰 비용은 탐사*와 이로 인한 위험부담에 있다.
• 주의를 기울여 신중하게 아키텍처를 만들면 이 비용을 크게 줄일 수 있다. 시스템을 컴포넌트로 분리하고, 안정된 인터페이스를 두어 서로 격리한다.
• 이를 통해 미래에 추가될 기능에 대한 길을 밝혀둘 수 있을 뿐만 아니라, 의도치 않은 장애가 발생할 위험을 크게 줄일 수 있다.

* 탐사(spelunking): 기존 소프트웨어에 새로운 기능을 추가하거나 결함을 수정할 때, 어디를 어떻게 최적으로 고칠 것인가에 대한 의사결정 비용
 
 

도메인은 왜 분리되어야 하는가?

소프트웨어 시스템은 주요한 두 가지 구성 요소로 분해할 수 있다.

• 정책(policy): 모든 업무 규칙과 업무 절차를 구체화한 것 - 도메인의 기능과 역할
• 세부사항(detail): 사람, 외부 시스템, 프로그래머가 정책과 소통할 때 필요한 요소 - 프레임워크, 데이터베이스, 서버, 통신 프로토콜  등

아키텍트의 목표는 시스템에서 정책을 가장 핵심적인 요소로 식별하고,
동시에 세부사항은 정책에 무관하게 만들 수 있는 형태의 시스템을 구축하는 데 있다.
이를 위해 세부사항을 결정하는 일을 미루거나 연기할 수 있게 된다.
 
소프트웨어를 부드럽게(soft) 유지하는 방법은 선택사항을 가능한 많이, 그리고 가능한 오랫동안 열어두는 것이다.
열어둬야 할 선택사항이 바로 중요치 않은 세부사항이다.
 
구축 초반에는 정책에 집중해야지 세부사항에 목메어 있을 필요가 없다.
DB를 선택하고, 웹서버를 무엇을 쓸지 등 초기부터 선택사항을 미리 결정하여 우리 시스템의 가능성을 닫아버리지 말자.
 

Clean Code(클린 코드) | 로버트 C. 마틴 - 교보문고

 

4. 의존성의 방향

레이어드 아키텍처, 헥사고날 아키텍처 등 여러 아키텍처가 있지만, 결국 이들의 공통점은
"소프트웨어를 계층으로 분리함으로써 관심사의 분리라는 목표를 달성할 수 있다."는 점이다.

• 프레임워크 독립성 : 아키텍처는 여러 라이브러리나 프레임워크의 존재 여부에 의존하면 안 된다.
• 테스트용이성 : 업무 규칙은 UI, DB, 웹서버 등 다른 외부 요소 없이 테스트할 수 있다.
• UI 독립성 : UI의 변경이 업무규칙에 영향을 주면 안 된다.
• 데이터베이스 독립성 : 업무규칙이 데이터베이스에 결합되면 안 된다.
• 모든 외부 에이전트에 대한 독립성 : 실제 업무 규칙은 외부와의 인터페이스에 대해 전혀 알지 못한다.

💡 의존성 규칙
소스 코드 의존성은 반드시 외부에서 안쪽으로, 고수준의 정책을 향해야 한다.
내부의 원에 속한 요소는 외부의 원에 속한 어떤 것도 알지 못한다.
(함수, 클래스, 변수, 엔티티 등) 외부 원에 위치한 어떤 것도 내부 원에 영향을 주지 않아야 한다.
데이터는 저수준에서 고수준으로 이동한다.

 

Architecture & Clean Architecture - part.2

 

Clean Coder Blog

 

5. 고수준과 저수준

클린 아키텍처에서는 추상화*가 많이 될수록 고수준이라 한다.
구체적일수록 저수준!

• 고수준 모듈은 저수준 모듈의 구현에 의존해서는 안된다.
• 저수준 모듈이 고수준 모듈에서 정의한 추상 타입에 의존(DIP 원칙) 해야 한다.

* 추상화: 복잡만 문제에서 핵심만 간추리는 작업

Q. 무엇이 더 고수준일까?
(Q1)
A: 비밀번호 암호화
B: 비밀번호를 SHA256으로 암호화

(Q2)
A: userSeq를 통해 Mysql에서 유저 조회
B: userSeq를 통해 유저 조회

(Q3)
A: paymentId로 조회한 결제 정보를 응답
B: paymentId로 조회한 결제 정보를 FrontEnd에 HTTP로 응답

 

레이어드 아키텍처

Gradle과 함께하는 Backend Layered Architecture

 

헥사고날 아키텍처

스프링 코드로 이해하는 핵사고날 아키텍처

 

아키텍처 별 패키지 구성