DDD, TDD, CDD(?) 의 시작 그리고 hexagonal architecture - 인턴 생활

인턴을 하면서 새로운 것들을 많이 배웠다. 기술들을 마구잡이로 붙여서 그냥 기능만 찍어내는 위주로 개발을 해왔던 나는 이번 인턴을 통해 사수분으로부터 개발론에 대해 많은 것들을 느끼며 더 많은 준비가 필요함을 느끼며 다시 집구석으로 자진 하방 했다. 더 큰 도약을 위한 일보 후퇴라고 믿고 열심히 하고 있다. 유레카의 순간을 안겨주신 나의 사수였던 경석 씨 에게 경의를 표하며 이 글을 써내려 가려고 한다.

 

본론으로 들어가서, hexagonal architecture 기반으로 DDD, TDD, CDD 라는 내가 처음 접해본 방법론으로 개발을 진행했다. 모두 아시다시피

• DDD - Domain Driven Design
• TDD - Test Driven Design

이다. 그런데 CDD는 기존에 없던 용어로 알고 있다.

• CDD - Commit Driven Design

커밋 주도 개발이라고 이름을 붙였다ㅋㅋ Jira에 Task를 만들고 해야 할 작업 내용에 대해 적고 브렌치를 파고 해야할 작업 내용을 계속 생각하면서 코딩을 하자는 취지이다. 그러니까 내가 무엇을 해야 하는지 알고 코드를 작성 하자는 의미였다. ( 항상 나는 A를 개발하면 B, C … 들도 생각이 나서 옆으로 세면서 코딩을 해왔는데 커밋 주도 개발을 하면서 또 다른 좋은 개발론에 대해 생각해보게 되는 계기가 되었다. )

 

이번 포스팅에서는 DDD만 써내려갈 계획이다.

DDD 를 하기 위해 이벤트 스토밍을 하기 위해서 Miro 를 이용했다.

 

본격적으로 내가 인턴을 하면서 DDD 를 설명하기에 앞서 이와 같은 조건들을 사용하여 설계해 나갔다.

1. 액터(Actor) 는 커맨드(Command) 를 내린다. 예를 들어, “서비스 사용자는 push 알람 설정 변경을 한다.” 는 예시를 들 수 있다.
2. 커맨드는 애그리거트 단위의 기능을 제공하기도 하고 **액터(이벤트, 유저 그리고 외부 시스템)**에 의해서 수행된다. 이벤트가 들어오면 커맨드(명령)가 실행되고, **유저(어플리케이션)**가 API 를 요청해서 실행되는 경우도 있고, 구글 로그인, 이메일 발송, 알람 발송(Twillio, FCM, OneSignal…) 등 외부 시스템에서 실행할 수 있다. 나는 다른 도메인에서 실행되는 외부 서비스는 해당 서비스를 담당하고 있는 도메인에서 이벤트로 표시하였다.
3. 액터(이벤트, 유저, 외부시스템)로 부터 시작된 동작의 결과로 이벤트가 생성된다. 이벤트는 액터에 의해 발생한 일을 의미한다. 예를 들어, “push 알람 설정 변경됨" 이 사례를 들 수 있다.
4. Event의 결과는 Read Model 에 영향을 준다. Read Model은 CQRS 에서 비롯된 개념이다. 말 그대로 읽기와 쓰기를 분리해서 읽기에 특화된 모델이다. 커맨드를 나와서 이벤트가 되면 queue 에 이벤트가 쌓여서 그것을 읽기만 하는 모델이다. 이런 방식은 성능에 장점이 있다. 그리고 단순성이다. 데이터베이스에서 데이터를 가져오는 더 간단한 방법은 없다.
5. 정책은 “A 이벤트가 발생하면 B 커맨드를 트리거 한다" 를 표현한다. ( 예를 들어 )즉 커맨드는 사실 액터와 Policy에 의해서 트리거 될 수 있는 셈입니다.
6. 별도로 의문점이나 추후 해결해야하는 티켓이 있다면 핫스폿 으로 표현할 수 있다.

 

이벤트 정의

이벤트들은 CQRS 원칙에 따라 Read 를 제외한 Create, Update, Delete 성질을 가진 이벤트들이 주로 이루고있다. 그 외 Read 는 Read Model 로 표현되는 경우가 많다. SRP를 생각하며 이벤트들을 쪼개는 작업은 정말 애매했다. 그럴 때 마다 잘게잘게 쪼개야 한다는 것을 터득했다. (이 방법이 주로 괜찮았음)

 

이벤트 표현 방법

보통 좌 에서 우로 표현하며, 좌에서는 이벤트를 발생시키기 위한 명령(커맨드)를 배치하고 우에서는 커맨드가 실행하고 발생되는 이벤트 내용을 적는다. 커맨드와 그에 따라 발생되는 이벤트는 주로 동사형태로 작성된다. 

위를 해석해보자면, “이벤트가 왔을 때 sms 메시지를 저장하고 저장되면 sms 전송을 한다.” 로 해석된다.

“완료”는 개발이 완료 되었을 때 표시하는 용도로 사용했다.

 

또 다른 케이스가 있다. 커맨더가 실행되고 난 후 여러가지 케이스의 이벤트가 발생할 수 있다.

위와 같은 상황에서 “push 메시지 저장” 이라는 커맨드가 발생하고 “push 전송 메시지 저장됨" 이랑 “push 비전송 메시지 저장됨" 이 있을 수 있다. 이 때 위와 같이 발생되는 이벤트를 위아래로 표현할 수 있다.

 

 

액터와 정책으로 연결된 어그리개잇들 그리고 그렇지 않은것

처음에 DDD를 접하고 설계를 할 때, 액터가 있는 티켓도 있고 없는 티켓도 있었는데 여기서 좀 헷갈렸다.

이 티켓들을 예시로 들어보면, 액터가 이벤트인것을 알 수 있는데, 액터의 성질인 이벤트가 들어오면 해당 “push 메시지 저장" 커맨드를 수행하고 “push 전송 메시지 저장됨" 이벤트가 발생하면 “push 알람 전송" 커맨드가 실행되는 것을 알 수 있다. 여기에서 또 확인할 수 있는 부분이 “push 알람 전송" 커맨더 앞에 액터가 없는 것을 확인할 수 있다. 이 의미는 외부적으로 API 를 열지 않고 마스터 서버 내부적인 API 라는 뜻이다. 즉 액터가 없으면 외부적으로 API 를 열어놓지 않았다는 의미가 된다.

 

반면 이것은 정책으로 연결되어 있지 않은 티켓이다. 토큰을 등록하는 기능을 하는데 외부로 부터 API 를 열어둔 것을 확인할 수 있다.

 

 

 

 

 

 

 

또 다른 케이스는 이렇게 두 가지의 액터를 가질 수 있다. 해석하자면, 이벤트와 사용자 둘 다 “이메일 메시지 저장"커맨드를 실행하고 “이메일 메시지 저장됨" 이벤트를 발생할 수 있다.

 

지금까지 여러 경우의 이벤트 스토밍 된 티켓들을 봤다. 잘 생각해보면 정책으로 연결되어있는 것이 없을 수록 좋다. 그래야 내부적으로 복잡하지 않기 때문에 서버에 부담을 줄일 수 있기 때문이다. 잘 생각하고 판단해서 티켓들을 만들어야 했다.

 

 

 

Read Model 로 Read 작업 분리 이유

API 로 커맨드가 실행되고 커맨드를 받은 도메인에서 이벤트가 발생하고 queue 에 들어간다. QueryModel 은 queue 에 있는 이벤트들을 끌어와서 처리하는 방식이다. 도메인별로 서버가 각각 따로되어 있는데 비즈니스 로직을 맡고있는 도메인들이 죽어도 앱이 돌아가는 이유는 QueryModel 에서 화면을 보여주고 있기 때문이다. 기능은 수행하지 못할지라도 완전히 앱이 죽는 것 보다 앱을 켜서 사용은 할 수 있는 것이 훨씬 사용자 경험상으로 좋기 때문이다.

 

이 그림에서는 QueryModel 이라고 했는데 ReadModel 이랑 다를바 없다고 보면 된다.

 

TDD

테스트 주도 개발이다. 먼저 테스트 코드를 작성하고 로직을 짜는 식으로 코딩을 해야 진정한 TDD 라고 배웠는데 해보니까 쉽지 않았다. 회사에 들어와 처음 해보는 테스트 코드 작성이기도 한지 생각의 연속이었다. 빨리 서비스를 출시해야하기 때문에 많은 시간이 걸릴 것 같아서 결국에는 로직을 먼저 코딩하고 테스트를 짜는 식으로 하였다. 먼저 테스트 코드를 짜는 방식으로 연습이 필요하다고 느꼈다.

테스트 코드는 각 애그리거트 당 나오는 레파지토리 테스트를 하고 커맨드핸들러 들을 테스트 했다.

 

헷갈렸던 것들

테스트로 푸시메시지를 보내기 위해서 가짜 객체를 DI 해줘야 하는데 Stub 이랑 Spy 가 헷갈렸다.

 

- Stub: 로직에 영향을 끼친다. (Repository 같은 경우는 findbyId 같은것들도 있기에 stub이고, template 같은 것들도 stub이다..)

- Spy: 로직에 영향을 끼치지 않는다. (Send 같은 것들은 send 만 테스트 해보고 싶은거니까 spy 이다.)

 

이렇게 정리가 되었다.

 

CDD

앞서 말했듯이 커밋주도개발은 어떤것을 개발해야하는지 먼저 생각한 후 지라에 적고, 해당 브렌치를 파고 해당 브렌치에서는 지라에 적은 것들만 개발하자는 취지였다. 다시말해 관심사를 정해놓고 개발하자는 것이다. 예를 들어 

위와 같은 방식을 ⬇️ 이렇게 지라에 스토리로 하든 작업으로 하든 등록을 해 놓고 코딩을 시작하는 방식으로 하였다.

 

hexagonal architecture

육각형 아키텍처는 포트와 어댑터을 가장자리에 두고 비즈니스 로직은 어디에도 의존되지 않아야하는 것이 아이디어이다. 프로젝트의 핵심인 비즈니스 로직을 보호하고 외부 툴 및 기술로 부터 이를 격리하기 위해서 추상화를 하였다. 수시로 변경되는 요구 사항으로 인해 코드에 큰 변경이 필요한 소프트웨어가 아니라고 생각했기 때문에 지속 성장이 가능한 구조라고 생각이 되었다. 추상화는 어디 까지 해야하는지에 대한 질문을 사수분이 던져주셨다. 정말 애매했다. 결론은 Infrastructure 는 추상화 하는 것이 좋고 domain 은 추상화 하기가 어렵다로 났다. 여기에 대한 나의 생각을 덧붙이고 싶지만 육각형 아키텍처를 잘 모르는 상태에서 말하기에는 너무 주제넘는다고 생각한다. 추후 이에 대해 공부를 하면서 더 생각해볼것이다. 이에 대한 더 자세한 내용은 따로 포스팅 할 예정이다.

 

마치며

말로만 들었던 DDD 를 완전히 처음 접해보았다. 이번을 계기로 개발에 대한 나의 인식이 많이 바뀌게 되는 터닝포인트가 되었다. 어릴 때 정말 재미있게 한 레고가 떠올랐다. 처음 레고를 사면 함께 들어있는 설명서도 없이 블록들만 있는 상태에서 설명서를 내가 만들고 그 설명서를 보면서 블록을 가지고 만드는 것 같았다. 처음 배운다고 정말 힘들었지만 조금이라도 알고나니 정말 재미있다. 이런것들을 접하게 해준 나의 사수에게 정말 감사하다.