<만들면서 배우는 클린 아키텍처 X 도메인 주도 개발 시작하기> 책 리뷰

만들면서 배우는 클린 아키텍처 / 도메인 주도 개발 시작하기

먼저 이 두 책이 말하고 있는 바는 다르다
아래에 나올 용어들을 처음 접하는 분이 있다면 공부해봐도 좋을 것 같다
이 지식들을 알고있더라도 크게 대단한 개발자가 되는 것은 아니지만, 비즈니스 문제를 조금 더 높은 영역에서 해결하는 여러 방법론들 중 몇가지를 배우는 것이다
그리고 DDD, MSA, 클린아키텍처 이런 용어에 매몰되지 않도록 하자!!
 
언제(어느 시점에) 도입하면 좋을지, 왜(다른 방법은 없는지?)를 고민해보고, 적용or사용하고 있는 시점에는 빠른 시점의 회고를 통해 잘못된 부분은 없는지 판단하고 수정해 나갈 수 있는 생각과 능력을 갖추어야 한다고 생각한다
 
먼저 두 책을 리뷰하기에 앞서, 나는 책에 나오는 모든 내용을 요약해서 큰제목/소제목/내용 등으로 나누어 올릴 생각은 없다!
내가 이 두 책을 읽고 느낀 독후감에 대해서 적는 느낌에 가깝다
전반적인 책 내용 말고 한장한장 궁금하신 분들은 다른 블로그 또는 집 근처 도서관이나 서점을 방문해 빌리거나 구매하는 것을 추천한다
 

만들면서 배우는 클린 아키텍처

Clean Architecture, Robert C.Martin

먼저 클린 아키텍처의 개념서라고 불리는 로버트 C. 마틴(엉클 밥, 밥아저씨)이 쓴 클린 아키텍처가 있다(현재 리뷰하는 책 아님)
그 책은 클린한 아키텍처는 ~ 이래야돼 하는 것들을 알려주고(개념의 확장), 제안하는 서적이다
 
내가 포스팅할 책은 톰 홈버그가 원서로 책을 내고, 박소은 개발자님이 한글로 옮기고 조영호님이 감수한 책이다
만들면서 배우는 클린 아키텍처는 여러 아키텍처 패턴중 헥사고날 아키텍처에 대해서 좀 더 실용주의적으로 다루는 쿡북개념의 책이다
책 겉표지만 봐도 자바 코드로 구현하는 클린 웹 애플리케이션이라고 밑줄이 그어져있다
 

독서록

독서사진

총 페이지 수는 144p인데, 하루이틀 사이에 볼 수 있겠지? 라고 생각했다가 큰 코 다쳤다 ㅋㅋ;; 짧게 짧게 보는데 꽤 오래 걸렸다..
북마크/북클립 쓰지 않고 핸드폰 메모에 마지막 본 페이지를 적어가며 봤다

시골로 내려가는 KTX에서도 조금 봤었다ㅋㅋ
 

비슷하지만 헷갈리는 개념 정리

아키텍처는 다양한 패턴이 존재한다 (Architecture 생략)
- Layered(계층형)
- Hexagonal(육각형. Port & Adapter)
- BCE(Boundary Control Entity)
- Onion(양파)
- Uncle Bob's Clean Architecture: Hexagonal + BCE + DCI(Data, Context and Interaction)
 
흔히들 헷갈리는 EDA(이벤트 드리븐 아키텍처), MSA(마이크로 서비스 아키텍처), CQRS(커맨드-쿼리 책임 분리)는 동작 방식에 따른 설계 스타일을 말한다고 생각한다
 
다시 정리하자면 계층형, 육각형, 경계, 양파 아키텍처는 구조적 설계 방법에 따른 아키텍처 패턴
EDA, MSA, CQRS는 동작 방식에 따른 시스템 설계 스타일이다
 

개념(용어) 정리

어쨌든 이 책의 주요 내용은 변화에 유연하게 대처할 수 있는 헥사고날(육각형) 아키텍처에 대한 내용이다
아래 그림에서 볼 수 있듯 주된 용어(개념)들과 그들이 맡은 책임들은 다음과 같다
- Entity: Enterprise Business Rule
- Use Case: Application Busuiness Rule/Logic
- Interface Adapters: Data Mapping, Call Usecase, Port Realize(InBound/OutBound)
- Frameworks & Drivers: Connect External System, Provide submodule(driver)
 
- 엔티티: 핵심 도메인 객체.  비즈니스의 불변 진리와 규칙 표현, 여러 유스케이스가 이 엔티티와 상호작용함
- 유스케이스: 애플리케이션의 비즈니스 로직 담당. 특정 유스케이스를 정의. 엔티티와 상호작용하며 비즈니스 흐름을 결정. 필요한 경우 포트를 통해 상호작용
- 인터페이스 어댑터: 외부 시스템의 데이터를 비즈니스 도메인 객체로 변환/시스템이 이해할 수 있는 형식으로 변환, 인바운드/아웃바운드 포트를 구현하여 외부 시스템을 연결
- 프레임워크&드라이버: 외부 시스템과의 통신을 담당. 데이터베이스, API, 메시지 브로커 등과 연결

출처: blog.cleancoder.com/uncle-bob

Q. 단순히 이 4개의 원만 있을까?

No

그렇지 않다. 원은 의미론적인 것이고, 4개보다 더 필요할 수 있다
하지만, 의존성 규칙은 항상 적용되어야 한다고 한다. 소스코드 종속성은 항상 안쪽으로 향해야 한다. 안쪽으로 이동할수록 추상화 수준이 높아지고, 바깥쪽으로 향할수록 더 구체적인 수준이다
이 번역에 조금 더 붙여보면.. 외부에서 들어오는 것은 변화무쌍하다고 생각한다. 파라미터가 바뀔 수도 있고 추가될 수도 있고 없어질 수도 있다. 내부적으로 갈수록..음 예를들어 Money라는 Value Object가 있다고 할 때 음수인 돈은 없을 것이고 Interval이라는 기간을 나타내는 객체에 From과 To가 있다면 To는 항상 From이후여야 한다
객체가 만들어지고 메세지를 보내 소통할 때 잘 변하지 않는 규칙들이 있고 그것들을 엔티티에 녹여내는 것이지 않을까..?
 
이 경계를 넘어서 다른 계층과 소통하기 위해서는 내부 계층은 외부 계층에 의존하면 안되고, 외부에서 내부로만 의존하는 규칙을 지켜야 한다
하지만, Usecase가 Presenter를 호출해야 하는 경우가 생길 수도 있다. 이럴 경우에는 DIP를 사용해서 해결할 수 있다
Usecase는 내부에 자신이 사용할 Presenter의 인터페이스를 갖고 있는다
Presenter는 인터페이스를 구현or현실화하여 구체화한다
그리고 런타임(생성 시점)에 생성자 주입을 통해 Usecase가 필요한 알맞은 Presenter를 주입받는다
이 과정에서 다형성이 사용될 수 있겠다
 

결론

일단 짧은 1줄로 해석하면 결국 헥사고날의 요지는 시스템을 외부 기술에 의존하지 않는 유연한 구조를 갖게 설계하며 변화가 발생하더라도 최소한의 노력으로 대처할 수 있으며 이에 맞게 의존성 규칙을 잘 지킨다면 자연스럽게 테스트하기 쉬운 구조를 만든다는 것이다
 
https://tech.kakaobank.com/posts/2311-hexagonal-architecture-in-messaging-hub/

유일한 멀티모듈 헥사고날 아키텍처 : 메시지 허브 적용기

https://wikidocs.net/book/8110

Clean Architecture

https://catsbi.oopy.io/71511fc4-7615-4b59-aea0-e043c9f58e83

헥사고날 아키텍처

https://www.youtube.com/watch?v=V0PZmJ7eDvo

https://www.youtube.com/watch?v=MKfSLrwLex8

https://www.youtube.com/watch?v=g6Tg6_qpIVc

 
https://www.youtube.com/watch?v=4QHvTeeTsj0

 
또한 흔히 말하길, 세상에서 가장 무서운 사람은 책 한권만 읽은 사람이라고 하고 나도 그것에 동의하기때문에 클린 아키텍처에 대한 영상들과 포스팅도 찾아봤다. 위의 글들과 영상을 한번쯤 보면 좋을 것 같다 + 출처 링크들도
 
사실 나도 계층형 아키텍처만 현업에서 적용해보고 다른 아키텍처는 적용해본 적이 없다
그렇다면, 나는 별로인 개발자인걸까? 그렇지 않다고 생각한다
내가 과거에는 이러한 개념을 몰라서 적용 못한 것일 수도 있고, 회사의 시니어가 몰랐던 걸 수도있고, 회사의 비즈니스 사항이 아직 헥사고날을 적용할 정도로 엄청나지 않을 수도 있다(규모)
이에 관해 토스페이먼츠의 김재민님이 하신 말씀이 있다. maturity level(성숙도)가 제일 중요하다
이 용어와 반대되는 말로 hasty(성급한), excessive(과도한)이 있다 "성급한 추상화", "과도한 모듈 분리" 등이 있다
좀 더 현실적으로 팀원들(나 포함)의 기술적 성숙도를 뜻하는 것일 수도, 코드 레벨에서의 성숙도를 뜻하는 것일 수도 있다
맨 처음 설계는 빠르게 변화(삭제)할 수 있도록 만들고 시간이 지나면서 변화하는 소프트웨어에 더 맞는 설계로 늦지도 않고 빠르지도 않은 적절한 타이밍에 어떤 아텍처로 가져갈 건지 정하면 된다고 생각한다
어떤 아키텍처를 적용할 것인지 판단을 내리기 위해서는 헥사고날!==정답
을 알고, 다양한 아키텍처에 대한 지식을 갖고 있어야 좋은 decision을 내릴 수 있다고 생각한다
아직 주니어 레벨이지만, 열심히 공부하는 감자한테 돌던지지는 말아줬음 한다! 대신 부족하거나 잘못된 지식이 있는 경우만 따끔한 댓글 달아줬음 한다..헤헷
 

만들면서 배우는 클린아키텍처 감수 조영호님의 싸인

 
마지막으로 오늘 Next Step을 수강하며 받은 이 책의 감수를 맡으신 조영호님의 Signature를 끝으로 다음 책 리뷰로 넘어가본다
감사합니다 조영호님🌱
 
 
출처
https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html

Clean Coder Blog

https://en.wikipedia.org/wiki/Data,_context_and_interaction

Data, context and interaction - Wikipedia

 
 

도메인 주도 개발 시작하기

이 책도 위의 책과 비슷하게 쿡북/실천서 느낌의 책이다
도메인 주도 개발(Domain Driven Design)는 클린 아키텍처 보다 더 큰 개념이다
더 큰 개념이라기보다 음.. 설계 철학과 접근법에 더 가깝다. 클린 아키텍처는 소프트웨어 구조와 아키텍처 패턴인 것이다
도메인 주도 개발 시작하기 (DDD 핵심 개념 정리부터 구현까지) 라는 책은 JSP 2.3 프로그래밍, 스프링5 프로그래밍 입문 등 다수의 개발서적을 내신 최범균님이 저자이신 한빛미디어 출판사의 책이다
이 책은 총 352쪽으로 구성되어 있다
 

DDD 개념 등장, Eric Evans

DDD라는 개념은 2003년 에릭 에반스(서문 마틴 파울러)가 쓴 Domain-Driven Design에서 최초로 탄생했다
먼저 TDD와의 차이점이 뭘까 알아보자
TDD: Test Driven Development
DDD: Domain Driven Design
ㅇㅋ. 맨 끝의 D철자가 다르다. DDD는 비즈니스 도메인을 중심으로 두는 개발 철학과 방법론이다
유머러스하게 또 다른 DDD가 존재한다 Deadline Driven Development 마감일 기반 개발ㅋㅋㅋ
근데 맞는말이긴하다. 결국 개발자, 특히 팀장같은 리더 포지션에서는 마감일을 지키는게 큰 능력성 지표이기도 하다
 
다시 본론으로 돌아와서, 2003년 이 개념이 나올 당시 개발 세계에서는 저자의 뜻을 이해하는 개발자가 거의 없었다고 한다
에릭 에반스는 복잡한 비즈니스 요구를 소프트웨어에 효과적으로 반영하기 위해 비즈니스 도메인이 필요하고, 이를 모델링하기 위해서 개발팀 + 도메인 전문가가 협력해야 한다고 말했다
 

독서록

집으로 가는길에, 병원에서

집에서, 개발 행사 갔다 오는 길에, 도서관에서 공부하고 오는길에, 아버지 항암치료 또는 검사로 병원에 갔을 때 등등 짬을 내서 읽었다!
 

개념(용어) 정리

어려운 책을 볼 때는 제일 먼저 목차를 보곤한다
그리고 그 목차에는 중요 키워드가 나와있다. DDD에서 사용되는 용어들에 대해 알아보자
 
- Ubiqutious Language: Common Language
- Bounded Context: Segregation with Aspect(Domain/Context)
- Entity, Value Object, Aggregate, Repository: Domain Object Modeling
- Domain Event, Domain Service: Business Logic Handling
 
- 유비쿼터스 언어: 도메인 전문가와 개발자가 공통된 언어를 사용해 원활한 소통을 도와주는 언어
- 경계된 문맥: 도메인 내의 특정 영역을 독립적인 문맥으로 구분하여 모델의 일관성을 유지하고 복잡성을 줄이는 경계
- 엔티티, 밸류 오브젝트, 애그릿, 리포지토리: 도메인 객체 모델링을 위해 핵심 도메인 객체와 값 객체 정의. 애그리게이트와 리포지토리로 일관된 데이터 관리를 담당
- 도메인 이벤트, 도메인 서비스: 비즈니스 로직의 상태 변화를 외부에 알리거나, 여러 도메인 객체를 조율하는 비즈니스 로직 처리를 담당

 

두번째 Bounded Context에서 Domain이라는 개념이 쓰였다. Domain Driven하게 모델링을 한다는 말이다
이 도메인 주도 설계로 객체 모델링을 할 때 객체지향이 사용된다. 추상화, 캡슐화, 다형성, (상속은 잠시 쉬세요...^^)
그리고 이때는 사이드이펙트를 최대한 줄이기 위해 불변 객체를 사용한다. Immutable을 만족하는 객체의 그룹 단위를 Aggregate로 묶어 처리한다
이 Aggregate를 일관된 하나의 트랜잭션으로 처리한다
 
그리고 이 모델링이 끝났다면, 컨텍스트에 따라서 모델을 분리한다
그리고 이 분리된 도메인 모델이 적용되는 범위를 Bounded Context라 일컫는다
 
분리된 Context 안에서의 Aggregate 내부의 모델은 CQRS, Event Sourcing와 같은 방법으로 처리할 수 있다
CQRS는 Command Query Responsibility Segregation으로 조회(읽기)와 명령(상태 변경)을 분리하는 하는 방법이다
Event Sourcing은 상태변화를 이벤트의 기록으로 처리하는 방법이다
둘 다 같이 사용하는 방법도 있다 - 주문 생성과 조회를 CQRS로 분리하고, 주문의 상태 변경 이력을 이벤트 소싱으로 관리
 
이와 같은 구조를 가져감으로써 확장성과 유지보수성을 극대화할 수 있다
 
이 DDD에 대한 공부는 Next Step 조영호님의 <도메인 주도 설계의 사실과 오해> 오프라인 수강을 통해 계속 채워나가려고 합니다!
(강의에서 발췌한 부분 X, 구글링 O)

---

 
다음 글에서는 코드레벨에서 어떻게 계층형 아키텍처가 헥사고날 아키텍처로 변환할 수 있는지
도메인 주도 모델링은 코드에서 어떻게 구현할 수 있는지 알아볼 예정이다