이번 파트에서는 DDD에 대한 Recap을 살짝쿵 하고 필자(M Yauri Attamimi)의 Favorite Architecture중 하나인 “양파 아키텍쳐”를 살펴보자.
DDD는 소프트웨어를 기술적인 관점 대신 비즈니스적인 관점에서 디자인 하는 것에 대한 것이다. 이를 위해 우리는 설계/디자인 과정에 항상 도메인 전문가와 함께 해야한다. 그 프로세스는 항상 Ubiquitous language로부터 시작해야한다. 이후에는 복잡한 도메인을 Bounded Context(Sub-domain)으로 나누고 신중하게 그 Boundary를 정의하고 Context간의 interface및 커뮤니케이션 방식을 정의해야한다. Bounded Context간에는 독립성이 보장되어 서로 내부 구조를 전혀 알 수 없게 해야한다.
추가로, DDD의 디자인과 구현에 대한 주의사항으로 아래와 같은 하지 말아야 할 짓들이 있다. 1. Domain 보다 Data에 집중하기 2. Domain의 로직 보다 구현(Entity, Repo 등등)에 집중하기 3. 핵심 개념 대신 포괄적이고 기술적인 단어 사용하기 4. 비즈니스 트랜잭션 말고 DB 트랜잭션에 집중하기
OK, 이제 이번 파트의 메인 주제인 양파 아키텍쳐를 알아보자!
Onion Architecture 는 Hexagonal Architecture의 아이디어에 착안하였으며 Jeffrey Palermo라는 분이 만들었다.
DDD와 Onion Architecture는 전혀 별개이다. DDD를 쓴다고 Onion Architecture를 사용하지 않아도 되고 MVC와 같은 전통작인 아키텍쳐도 DDD와 사용할 수 있다. 하지만! Onion Architecture는 DDD와 궁합이 좋다.
전통적인 아키텍처 + DDD를 먼저 살펴보자.
이런 구조는 레이어 간의 결합도가 불필요하게 높아진다. 또한 모든 레이어는 Frameworks나 Utility Services에 의존한다.
예를들어 한팀이 infrastructure 계층을 SpringBoot를 써서 개발하기로 정했다고 하자. 그리고 몇년 뒤에 그 팀이 SpringBoot를 버리고 다른 프레임 워크로 이주해야 하는 상황이 되었다. 이때 위와 같은 구조에서는 다른 레이어에 대한 결합도 때문에 변경 없는 이주가 매우 힘들다.
“Loosely coupled, higly cohesive” 낮은 결합도와 높은 응집도
세상에서 가장 안 좋은것 중하나는 UI와 비즈니스 모델이 copuling을 가지는 것이고 비즈니스 모델이 Data 접근 계층과 coupling을 가지는 것이다.
이제 양파 껍데기 아키텍쳐를 살펴보자
양파 껍데기 아키텍처의 Main Goal은 coupling을 제어하는 것이다.
Basic Rule - all coupling is toward the center.
- “Infrastructure”는 “Application Service”, “Domain Services”, “Domain Model”을 앎
- “Application Service” 는 “Domain Services”, “Domain Model”을 앎
- “Domain Services” 는 “Domain Model” 만 앎
- “Domain Model”은 자기 밖에 모름
- 내부 계층은 바깥 계층을 모름
도메인 모델
- 핵심임
- Interfaces들의 collection을 가짐
Infrastructure 레이어
- UI, Automation Test, DatabaseAccess, NetworkAccess, FileAccess
그래서 DDD가 왜 Onion Arachitecture와 짝짝꿍이 좋은가?
다음 장에서 살펴보자