Order 도메인 설계 시작, Member, Product 도메인에서의 오류, 도메인주도 설계로 시작하는 마이크로서비스 개발 독서, 다짐

이번 한주는 유독 더 짦게 느껴지는 것 같다. 왜 벌서 수요일이 다 지나갔는지 모르겠다.. 8월이 왔음은 알고 있었지만, 벌써 8월 첫째주가 절반이 지나갔다니.. 왜 어째서 시간은 더 빠르게 가는걸까.. 정신차리고한다고하는데, 그렇지 못한걸까.. 이렇게 빠른 시간이 야속하기만하다. 멈추는정도는 아니여도 조금만 더.. 천천히 갔으면 좋겠다.

 

---

독서: 도메인 주도 설계로 시작하는 마이크로 서비스 개발

책쟁이에게 아주 찰떡인 귀여운 책갈피를 선물받았다.

 

요즘에는 도메인 주도 설계로 시작하는 마이크로서비스 개발 책을 제일 많이 보는 것 같다. 다른 재미는 책들도 많은데 최근에 DDD관련된 이야기와 클린 아키텍처(Ports and Adapters)에 대한 이야기를 많이 하다보니 이와 관련된 책을 더 선호하게 되는 것 같다.

 

오늘 독서한 내용은 3장_ 마이크로서비스 애플리케이션 아키텍처 로 아키텍처 부분을 독서하였다. 내가 좋아하는 아키텍처 부분이였어서인지 정말 시간가는줄 모르게 재밌게 봤다.

 

---

행위가치와 구조가치

 

우리의 선생님, 로버트 C. 마틴은 소프트웨어의 가치는 행위가치와 구조가치로 나뉘고, 소프트웨어를 정말로 부드럽게(Soft) 만드는 것은 구조가치라고 이야기하였다.

• 구조 가치: 소프트웨어의 아키텍처
• 행위 가치: 소프트웨어의 기능

 

이는 당연하다. 코드와 설계의 구조를 깔끔하게 만드려는 고민 없이, 기능만 구현하는 것은 유지보수를 힘들게 만들고, 문제가 발생했을 때, 더 많은 비용이 든다. 그리고 이것이 내가 아키텍처를 공부하게 된 계기이기도 하다. 지난 회사에서의 근래에 개발된 레거시코드는 구조나 설계에 대한 고민 없이, 오직 기능구현에만 몰두한 코드들이 즐비했다.(사람자체도 별로였던 사수의 작품이었다.) 이는 이해하기도 어려웠고, 상황에 대처하기도 어려웠다. 당시에는 프로젝트의 구조를 따르는 코드 설계를 생각하지 못했던 것이 아쉽기만하다.(물론 말했어도, 무시당했을테지만 말이다.)

 

---

관심사의 분리: 비즈니스 로직

 

비즈니스 로직이란 비즈니스 영역의 업무규칙(Rule), 개념(Concept)을 표현하는 용어이다. 그리고 개발자는 비즈니스 로직을 분석 및 이해하고 이를 프로그래밍 언어로 만들어야한다. 하지만 만들기만하면안된다. 이해하기 쉽고, 변경하기 쉬운 시스템으로 만들어야 한다.

 

이를 위해서는 비즈니스로직 영역과 기술영역을 철저하게 분리하는 것이 좋다고한다. 이는 비즈니스 로직이 기술보다는 오랫동안 지속되고 안정되어야 하는 애플리케이션의 핵심 영역이기 때문이다. 빠르게 변화하는 기술에는 최소한으로 영향을 받도록 해야한다.

• 비즈니스로직 영역: 비즈니스를 표현
• 기술 영역: 기술 문제를 처리

 

기술과 비즈니스 로직을 분리한다면, 복잡성이 낮아지고, 유지보수성이 증가한다. 당연하다. 관심사가 분리되었으니깐! 그리고 이를 반영한다면 해당 비즈니스 로직은 언어개발자라면 (다른 기술적인 지식 없이)쉽게 이해하고 구조화 할 수 있을 것이다.

 

하지만 이것은 쉽지 않은 일이다. MVC 패턴의 프로젝트에서는 모든 로직을 하나의 SQL로 작성하는 경우가 상당하다.(일단 과거의 나, 그리고 사수가 그랬다.)해당 쿼리가 문제가 있거나, 성능 이슈가 발생할 경우, 당사자가 아니라면 정말 유지보수하기 힘들었다.

 

그리고 나는 이것을 개선하기위한 방법을 공부하기 시작했고, 그 답으로 DDD와 클린아키텍처를 공부하게되었다.

 

 

---

마이크로서비스의 구조: 내부구조

 

마이크로서비스 뿐만아니라 일반적인 비즈니스 서비스를 생각한다면, 외부 구조와 내부구조가 존재할 것이다. 힙한(?) 서비스의 외부 구조는 서비스별로 나뉘어진 MSA 아키텍처 형태를 갖고 있을 것이다. 각 팀마다 MSA 환경을 구축한 이유는 다르겠지만, 서비스를 구분하여, 해당 서비스를 효율적으로 관리하기 위함이 아닐까 싶다.

• 외부영역: 기술 중심의 세부사항
• 내부영역: 비즈니스 로직(업무 규칙) 표현

 

내가 많은 프로젝트를 보지는 못했지만, MSA와 같은 외부 구조를 갖추고선 어울리지 않는 내부구조를 가진 곳이 많은 것 같다는 생각이다.  과연 도메인이 SRP가 지켜지는(도메인이 변경할 이유가 하나뿐인) 프로젝트가 얼마나 있을까?

 

이번 챕터를 보면서, 내가 사용하던 것들이 특정 패턴으로 사용된다는 것도 새롭게 알 수 있었고 DDD가 적용된 내용과 내가 공부하고있는 포트앤어댑터 아키텍처의 비슷하면서도 다른 부분들을 많이알 수 있었다.

 

같은 목표를 지향하지만, 그 방법이 비슷하면서 다른 기술들이 정말 재밌다. 그리고 이를 실제 업무에서 사용한다면 얼마나 더 재밌을까?

 

---

Order 도메인 설계 시작

 

드디어(?) Order 도메인을 설계하기 시작했다. 기본적으로 Order 도메인은 복합적이다. Order 외에 Product, Member그리고 아직 개발되지 않은 Payment 등 다양한 도메인이 총 집합되어 만들어질 예정이다. 아직 개발되지 않은 Payment 의 경우에는 Order을 개발하면서 간단하게 함께 개발이 진행될 것 같다.

 

설렌다.. 머릿속은 복잡하지만, 너무 재밌을 것 같다. 공부했던 내용을 내가 생각한 프로젝트에 반영한다는게 정말 즐겁다. 설렌마음 안고서 열심히 만들어봐야겠다! 

 

---

Member, Product 도메인에서의 오류

 

Product 도메인의 1차 설계와 구현을 마무리하면서 전체적으로 Product 도메인에 대한 정리를 진행했다. 그리고 정리를 하면서 중요한  핵심요소에 문제가 있을을 깨달았다. 바로 이벤트 발행 문제이다.

 

유스케이스를 다루는 CreateProductCommandHandler, 애플리케이션 계층에 속하며, 원래는 이벤트를 발행해야 한다.

 

애플리케이션계층에서는 유스케이스를 다룬다. 나는 유스케이스별 클래스를 사용하여, 각 유스케이스를 처리하고있다. 그리고 도메인 이벤트의 발행은 애플리케이션 계층에서 이뤄져야한다. 하지만 현재 애플리케이션 계층 어디에서도 이벤트가 발행되고있지않다. 이벤트를 발행하기 위해, 퍼블리셔를 모두 구현했음에도 불구하고 말이다.

 

나는 부끄럽지만 이 실수를 오늘 스스로 프로젝트를 정리하기 전까지 인지하지 못했다. 유스케이스를 하나하나 살피며, 흐름을 파악하면서 이 실수를 알 수 있었다. 그리고 이 문제는 지난 Member 도메인 또한 마찬가지였다.

 

왜 이 사실을 계속해서 고민하고 또 설계를 신경썼던 나인데, 왜 알지 못했을까? 반성하면서, 변명이 아니라 회고의 느낌으로 그 원인을 스스로 판단해 보았다.

 

---

 클린 아키텍처 공부와 동시에 적용 및 진행된 개발

 

내 처음 신발 주문 시스템을 설게할 당시에는 클린아키텍처에 대한 생각은 없었다. 그저 도메인 주도 설계와 이벤트기반의 아키텍처만을 고민했을 뿐이었다. 도메인 주도 설계를 공부하면서 궁극적인 DDD의 목표(도메인로직의 보호)를 달성하기 위해서는 클린아키텍처(Ports and Adapters) 가 필수적이라는 생각을 하게되었고, 나는 해당 아키텍처를 내부 아키텍처로 사용하기로 결심했다.

 

당시 나는 클린아키텍처에 대한 지식이 너무나도 부족했다. 기껏해봐야 옛날 강의에서 잠깐 본 피피티 4장이 전부였고, 나는 책을 사서 공부하면서 개발을 함께했다. 그리고 이 과정에서 문제가 발생한 듯하다.

 

클린아키텍처에서는 도메인을 보호하기 위해 내부영역과 외부영역으로 나누어 개발한다. 내부영역에는 애플리케이션 계층, 도메인 계층이 존재하며, 외부계층에는 그밖의 것들이 존재하는 어댑터 계층이 해당한다. 그리고 책에서는 가장 보편적인 외부 계층인 영속성 계층을 예시로 내부-외부를 구현했다. 그리고 나는 이 책에 집중한 나머지 영속성계층에 대한 내용만을 구현했던 것이다.

 

out port 에 나는 message 인터페이스를 정상적으로 구현하였다.

 

애플리케이션 계층을 개발할 때, 나는 정상적으로 message 에 대한 인터페이스를 만들었다. 그래서 더 바보같다..이는 Member 도메인에서 이렇게 시작을 하게되었고.. 또 그대로 Product 에서도 똑같이 한 것 같다. 이렇게 내가 스스로 왜 이랬을까.. 문제를 식별했으니 다행이지만.. 참 바보같다..

 

해당 내용은 Issue 로 등록하여 작업해야겠다.

 

---

다짐

 

최근 작성한 PR들을 통해 느낀점이 있다. 세상은 다른사람에게 관심이 없다. 그리고 자신에게도 여유가 없는 현실인 것같다.

나는 감사하게도 지난 PR들에서는 다른 분들의 리뷰와 피드백을 받아 볼 수 있었다. 지난 회사에서 알게된 열정 넘치는(?) 분들이었기에 같이 공부하고 비전을 공유하면서 서로 공부하는 내용을 리뷰하자는 것에서 시작한 PR 리뷰 요청이었지만, 이제는 그 요청을 그만해야할 것 같다.

 

 나는 생각보다 실수에 대해서 다른사람들이 이를 잡아줄 것이라고 생각했던 것 같다. 하지만 실상은 익숙하지 않은 아키텍처에 대한 설명뿐이었다. 더 좋은 코드를 함께 고민하는 것이 아니라 내가 한것을 뽐내려는(?) 것처럼 보일것 같았다. 그리고 어쩌면 내가 눈치없이 계속해서 리뷰를 요청하는 것일지도모른다는 생각도 들었다.

 

그래서 나는 이제는 가능한 스스로 리뷰를 진행기로 다짐했다. 그리고 좀 더 전투적(?)으로 공부하고, 가능한 빨리 같은 고민을 하는 집단에 속해야겠다 다짐했다.

 

가보자 !!!  Light Weight Babe~ Easy Code Babe~~