[FLOWBIT] BITCOIN SERVICE의 DDD 구조 작성 📚

1. 개요

 길고긴 DDD 스터디가 끝나고 해당 구조를 나의 서비스에 적용해보고 싶었다. 사실 기본적인 개념만을 이해한 상태에서 서버에서 돌아가고 있는 서비스의 구조를 바꾸는 것은 생각보다 쉽지 않았다. 바운디드 컨텍스트를 MSA를 구성하는 하나의 서버라고 생각하고 도메인을 정리하니 나름 구조가 갖춰졌다. 이번 기록지에서는 기존에 돌아가던 서비스에 DDD 개발론을 적용하는 과정을 적어보고자 한다.

2. 본론

 일단 기존의 파일 구조는 다음과 같았다. (이렇게 보니 머신이고 뭐고 아주 개판인 것 같다.)

---

---

 아주 개판이다... ㅋㅋㅋ spring boot의 controller, service, dao, dto, repository 계층의 구조만 알고있던 사람이 자동시스템 코드에 주먹구구식으로 배운 flask 프레임워크를 도입한 처참한 결과이다...

 

 사실 flask에도 공통적으로 쓰이는 파일구조가 있는지를 찾아보았었다. 결국 flask도 MVC 패턴에 맞게 directory structure를 작성하는건 비슷했다.

---

https://shravan-c.medium.com/mvc-for-flask-application-a636e6f58d72

MVC for Flask Application

---

 위의 구조대로 작성하지 못한 나름의 변명거리는 다음과 같다.

---

• 작성된 Machine CLASS의 계층이 너무 불분명했다.
  • 만약 MongoDB를 편하게 사용할 수 있도록 해주는 객체는 어떤 계층에 넣어주어야할까?
• service 계층단에서 수행할 역할이 불분명했다.
  • 지금 돌아가는 BITCOIN SERVICE는 하루에 한번 cron을 통해 예측가격들을 없데이트 하게 된다. 해당 기능을 DB에 입력하면 그저 그 값을 USER에게 제공만 하면 된다.
• 나의 역량 부족
  • 사실 app.py에서 crontroller를 분리하는 방법도 공부가 필요한 처참한 상황이었다.

---

 이렇게 보니 막상 나의 서비스는 학습된 모델을 사용한다는 특징이 있을 뿐 웹적으로 엄청난 역할은 수행하고 있지 않다는 생각이 들었다. 따라서 DDD로 리펙토링을 진행하면서 전체적인 파일 구조 또한 수정해야겠다는 생각이 들었다. 지금 보이는 부분이지만, 함수명들도 아주 가관이다... ㅠㅠ

 

 일단 DDD 구조를 작성해야 파일 구조를 작성할 수 있을 거라고 생각했다. 처음에 작성했을 때는 다음과 같은 구조였다.

---

---

 init_coin 도메인과 one_day_ai 도메인을 따로 분리하는 방식이다. model_controller는 그저 예측 모델을 다루는 객체라고 생각하면 된다. 나의 첫 생각은 "초기 서비스를 시작할 때 모든 데이터를 초기화하는 코드와 하루에 한번 예측 가격을 도출하는 코드의 역할은 다르니 각각의 root 도메인으로 생각하면 되겠지?" 였다.

 

 아주 좋지 않은 생각이었다. 결국 DDD는 사용자에게 제공하는 기능에 맞춰 구조를 설계하는 것이었는데 그런 개념이 전혀 반영되지 않았다. 결국 기능적인 측면으로 생각해보면 유저는 그저 "예측가격을 제공받기"만 하면 된다. 따라서 해당 기능을 제공하는 root domain으로 coin이라는 귀여운 도메인을 만들었다.

---

---

 자, 그럼 이제 coin이라는 root domain을 위해 필요한 부분을 생각해야 될 때이다. 그 개념으로 봤을 때는 init_coin 도메인과 one_day_ai라는 도메인이 생기게 된다. 이 둘이 coin 도메인 안에 속하게 되면 자연스럽게 다음과 같이 Aggregate의 개념이 생긴다.

---

---

 위의 구조라면 USER는 coin이라는 root 도메인을 통해서만 기능을 제공받을 수 있고, 필요한 도메인은 묶이게 되어 Aggregate의 개념을 적용할 수 있다. 마지막으로 제공하고 싶은 기능을 구현하기 위해 필요한 모든 아키텍쳐 계층이 한 서버안에 있기에 바운디드 컨텍스트에 적합한 구조를 띄게 된다.

 

 위의 구조가 정답이라고 할 수는 없지만, 나름 DDD의 규칙에 맞추려 노력했다 보니 적어도 처음의 개판 파일 구조보다는 깔끔하게 느껴졌다. 다음은 위의 구조에 맞게 Flask 프레임워크에 맞는 파일 구조를 작성하고자 한다.

3. 결어

 개발론은 특정한 정답이 존재하는 것이 아닌 다양한 방법들만이 존재하는 것이기 때문에 참 어려운 것 같다. 근래 이만큼 여러 사람들의 의견을 들은 경험이 있는지에 대한 생각이 들정도로 많은 자료를 찾아보았다.

 

 그래도 하나의 책을 끝내고 이를 적용하려고 노력한 과정이 나름 의미있게 느껴진다. 성과가 없는 상황에서는 이 모든 것이 "정신승리"로 평가되는 경우가 많은 세상이지만 이런 상황을 이겨내는 멘탈을 가지기위해 노력하고 있다.

 

 다음에는 위의 DDD를 최종적으로 적용하고 깔끔해진 파일 구조로 완성된 FLOWBIT VER2를 릴리즈한 과정을 주제로 글을 작성할 것이다.