[Architecture] 아키텍처 개념 정리

팀에서 아키텍처에 관한 회의가 있었다. 기존 DDD 아키텍처에서 헥사고날 아키텍처 변경에 관한 회의 였는데, 어떤 아키텍처가 적합한지 생각하기 위해선 각 아키텍처에 관한 이해가 필요하다고 생각하여 정리하게 되었다.

 

Architecture 

비즈니스 요구 사항을 만족하는 시스템을 구축하기 위해 구조를 정의한 것

소프트웨어 응용 프로그램을 설계하기 위한 모델 또는 패턴

 

Domain Driven Design

비즈니스 도메인별로 나누어 설계하는 방식

"Loose Coupling, High Cohesion" 모듈간의 의존성은 최소화하고, 응집성은 극대화하는 것이 궁극적인 목표이다.

DDD는 Strategic Design과 Tactical Design으로 나눌 수 있다.

 

tatical design

프로그래밍을 하기 위한 구체적 설계

strategic design에서 설계한 각 Sub domain별 Domain Model을 중심으로 설계하는 것

tatical design시 목적별 계층으로 나누어 설계(Layered Architecture)

 

strategic design

개념적 설계

도메인의 비즈니스 상황(Context)에 따라 비즈니스 목적별로 그룹핑하여 설계

• Domain Model: 비즈니스 도메인의 서비스를 추상화한 설계도
• Bounded Context: 도메인안의 서비스를 경계 지은 Context의 집합
• Context Map: Bounded Context들 사이의 관계
• Ubiquitous Language: Domain Model에 대해 업무의 참여자들이 커뮤니케이션을 위해 공통으로 사용하는 언어

 

Aggregate 

한 단위로 취급 가능한 경계 내부의 도메인 객체

루트 엔티티와 여러 개의 서브 엔티티로 구성된다.

• Root Only: Aggregate 내부의 entity나 VO에 접근시, Aggregate Root를 통해서 접근한다.
• Primary Key: 다른 Aggregate 참조 시, 객체가 아닌 primary key를 사용하여 참조한다.
• One to One: 한 개의 트랜잭션은 한 개의 Aggregate만 write한다.

 

Hexagonal Architecture

레이어 간의 원하지 않는 종속성이나 비즈니스 로직으로 인한 사용자 인터페이스 코드의 오염과 같은 객체 지향 설계의 구조적 함정을 최소화하는 아키텍처

포트 및 어댑터 아키텍처라고도 불린다.

 

포트

내부 비즈니스 영역을 외부 영역에 노출한 API

• 인바운드 포트: 내부 영역 사용을 위해 노출된 API
• 아웃바운드 포트: 내부 영역이 외부 영역을 사용하기 위한 API 

 

어댑터

외부 영역과 포트 간 교환을 조정

• 인바운드 어댑터: 외부 어플리케이션/서비스와 내부 비즈니스 영역 간의 데이터 교환 조정
• 아웃바운드 어댑터: 내부 비즈니스 영역과 외부 어플리케이션/서비스 간의 데이터 교환 조정

 

 

지금까지 MVC 패턴 프로젝트, 멀티 모듈 프로젝트(Core가 중심이 되는), DDD 프로젝트를 순서대로 경험해보았다.

순차적으로 경험을 하게 되어 장점을 더 잘 이해할 수 있는 좋은 기회였다.

가령, 멀티 모듈 프로젝트에서 Core에 도메인이 집중되어 비대해지는 문제점을 도메인 별로 분리한 DDD 모듈 구조를 적용하니 응집성이 극대화 되었다. 또한 도메인 별로 응집성이 높으니 모놀리틱 아키텍처에서 MSA 아키텍처로 분리할 때의 확장성도 가지게 되었다.

이번에 헥사고날 아키텍처를 도입하게 되면서 현재 아키텍처가 최고라는 생각보다 더 좋은 방법이 있는지 계속 고민하는 시간을 가지는 것이 중요하다는 것을 느끼게 되었다.

 

 

참고

https://happycloud-lee.tistory.com/94
https://mesh.dev/20210910-dev-notes-007-hexagonal-architecture/
https://engineering.linecorp.com/ko/blog/port-and-adapter-architecture/