NextStep DDD 세레나데 수료 후기

후기🔥/회고록

NextStep DDD 세레나데 수료 후기

dkswnkk 2024. 7. 15. 00:02

계기

4.30 ~ 6.10까지 DDD 세레나데 6기 과정에 참가했다. 요 과정을 듣게 된 이유는

넥스트스텝 강의 중 듣고 싶었던 강의 중 하나였기도 하고,
기수별로 거의 일 년에 한 번 열리기에 2년 차인 지금이 적기라 생각했고,
DDD관련해서는 책으로 이론공부만 했었는데 실습을 해보고 싶었고,
현재 프로젝트에서 이 구조를 기반으로 하고 있기 때문에 업무에 도움이 될 거라 생각했기 때문이다.

커리큘럼

강의 커리큘럼은 다음과 같다.

1주차 - 도메인 주도 설계 이해

첫 주는 도메인 주도 설계의 등장 배경에 대해서 학습했는데, '도메인', '모델', '도메인 모델', '도메인 주도 설계'라는 단어의 정의에 대해 생각해 보는 시간을 많이 가졌다. 미션에서는 2단계와 3단계가 개인적으로 많은 도움이 되었다.

2단계 요구 사항 정리에서는 프로젝트의 요구사항을 정리하는 작업을 했는데, 예를 들어 "상품명은 비어있으면 안 되고 비속어는 포함되면 안 된다."와 같은 것들을 작성하는 것이다. 처음에 나는 "상품명은 null이면 안된다."와 같이 개발자 관점에서만 작성했었는데, 요구 사항은 프로젝트에 참여하는 전 직군을 아우르는 모든 이해관계자들이 전부 이해할 수 있도록 작성해야 한다는 점을 배웠다.

3단계 테스트를 통한 코드 보호는 단위테스트를 작성하면서 Fake 객체를 사용하는 방법과 Mock 객체를 사용하는 방법에 대해 알아보고, 각각의 차이점에 대해 학습했다.

Mock 객체: Stub 방식을 이용해 화이트 박스 테스트 형식으로 테스트 코드를 작성한다. 내부 로직을 정확히 알고 있어야 하고, 빠르게 테스트 코드를 작성할 수 있다는 장점이 있지만 given 절이 많아질수록 가독성이 떨어지고, 내부 동작의 흐름에 영향을 받기 때문에 코드 리팩터링 시 테스트 코드의 변경도 많이 필요할 수도 있다.
Fake 객체: 라이브러리를 의존하지 않고 블랙박스 형식으로 통합 테스트 코드를 작성하듯이 결과만 확인하면 되어서 편하고 가독성 있게 작성할 수 있다. 하지만 초기 세팅 작업이 오래 걸리고 귀찮다는 단점이 존재한다.

단위테스트 하면 런던파와 고전파의 논쟁에 대한 이야기가 나오는데, 사실 이런 건 잘 모르겠고 나는 개인적으로 초반에 조금 귀찮더라도 통합테스트처럼 결과만 검증하면 되는 Fake 방식을 선호하는 것 같다. (물론 외부 I/O들은 부분적으로 Mock을 사용하고,,)

아래는 참고하면 좋은 아티클들이다.

이벤트 스토밍

중간에 우아한 테크살롱에서 오프라인으로 이벤트 스토밍을 진행했다. 이전까지 여러 기업들의 기술 블로그를 통해 이벤트 스토밍을 하는 이유에 대해서는 알고 있었지만, 이것 역시 글로만 봤다 보니 실제로 어떻게 진행되고 어떤 효용이 있는지는 직접적으로 느끼지 못했었다. 하지만 이번 기수에서 직접 오프라인으로 참가하여 진행해 보면서, 그 진행 방식과 효용에 대해 알게 되었다.

이벤트 스토밍(Event Storming)은 도메인 주도 설계에서 사용하는 워크숍 기법으로, 도메인 전문가와 개발자가 함께 시스템의 복잡한 비즈니스 프로세스를 시각적으로 표현하고 이해하기 위해 사용된다. 진행 방법에 대해서는 아래의 영상들을 참고하면 좋을 것 같다.

이벤트 스토밍은 도메인 주도 설계에서 사용하는 워크숍 기법이라고 하지만, 이러한 설계가 아니더라도 팀에 새로운 인원이 들어오거나 반기별로 한 번씩 진행하면 도메인을 빠르게 이해하고 시스템의 복잡한 부분이나 잠재적인 문제를 사전에 발견할 수 있어서 매우 도움이 된다고 생각되었다.

2주차 - 크게 소리내어 모델링 하기

2주차는 유비쿼터스 언어와, 바운디드 콘텍스트에 대한 개념에 대해 학습했고, '용어사전 정의'와 '모델링'에 대해 미션을 진행했다.

1단계 용어 사전 만들기 미션을 진행하면서 '이런 건 사내에 도입되면 정말 좋을 것 같다'라는 생각이 들었다. 용어 사전을 정의하는 이유는 프로젝트나 조직 내에서 사용되는 중요한 용어와 개념을 명확하게 정의하여 구성원들 간의 의사소통을 원활하게 하기 위해서이다. 예를 들면 이커머스 조직에서 'product' 라는 것을 '제품'으로 부를지 '상품'으로 부를지를 정의하는 행위를 의미한다.

당장에 현업에서 기획자와 개발자들이 서로 부르는 용어가 다르고, 사업 팀에서 부르는 용어가 달라 회의나 업무를 할 때 헷갈리는 경우가 많은데 이것들을 시간 내서 정의하면 의사결정을 보다 정확하고 신속하게 할 수 있어 불필요한 커뮤니케이션 비용을 줄일 수 있을 것 같다.

2단계 모델링 정의는 시스템을 단순화하여 수학적, 논리적, 혹은 시각적으로 표현하는 과정으로 모델은 이러한 과정의 결과물을 의미한다.

마크다운을 사용했기에 이번 미션을 진행하면서 mermaid라는 언어에 대해 알게 되었고, 위와 같이 모델링을 시각적으로 표현하는 방법에 대해 배웠다.

그리고 전체적으로 2주차 미션들은 랜덤으로 지정된 페어와 미션을 진행하는 것이 특징이다. 미션들 자체가 혼자 하면 정말 쉬운 미션이지만 함께하는 인원이 늘어날수록 미션의 난이도가 높아지는데, 상대방을 설득하고 리뷰어를 설득하는 과정들이 포함되기 때문이다. 특히 용어를 정의할 때 나는 이렇게 생각하는데 페어는 다르게 생각할 수 있기 때문에 소통하며 맞춰가는 과정에서 많이 배웠던 것 같다.

3주차 - 도메인 주도 설계 기본 요소

3주차는 하위 도메인과 Bounded Context, 도메인 모델링, Entity와 VO, Aggregate와 Repository, 그리고 도메인 서비스에 대해 학습했다.

각 Aggregate 별로 Repository를 만들고, 기존에 복잡하게 서로 관계를 맺고 있던 레거시 코드들을 Bounded Context 끼리 알맞게 분리하는 작업을 진행했다. 이번 주차에서는 직접적으로 코드를 작성하는 부분이 많았기 때문에 가장 시간이 많이 들었고, 그만큼 가장 많이 배운 주차였다.

패키지 구조는 처음에 아래와 같이 POJO와 영속성 레이어를 분리하고 싶었지만, 기간 내에 미션을 완료하지 못할 것 같아 ORM 엔티티를 도메인 모델로 사용했다. 그리고 Bounded Context 간의 데이터 전달은 이벤트를 사용했다.

4주차 - 도메인 주도 설계 아키텍처

4주차부터는 강의위주이고, 아래의 내용들을 배웠다.

도메인 주도 설계에 어울리는 아키텍처
- 계층형 아키텍처
- DTO, DIP, ACL(부패 방치 계층)
- 아키텍처의 진화
AGGREGATE 심화
- 큰 애그리거트와 작은 애그리거트
- 결과적 일관성
미션 라이브 코딩

5주차 - 도메인 이벤트와 CQRS

마지막 주차는 Q&A를 포함하여 도메인 이벤트, 이벤트 소싱과 CQRS 패턴에 대해 학습했다. CQRS 패턴에 대해서는 직접적인 미션으로 진행했으면 했는데 강의로 진행된 점에 있어서 조금 아쉬웠다.

아래의 아티클들이 강의를 이해하는데 많은 도움이 되었다.

마무리

넥스트 스텝의 첫 강의로 작년에 TDD, 클린 코드 with Java를 수강했었는데, 이때 매우 만족했고 나의 코딩 스타일이 확연하게 개선되었다는 점을 몸소 느꼈기 때문에 다른 강의들도 꼭 들어보고 싶은 마음이 들었다. 특히 이번 강의인 DDD 같은 경우는 지금까지 책을 통해 이론만 배웠기도 하고, 최근에 옮긴 팀의 프로젝트 구조의 일부에서 사용하고 있지만 어디선가 계속 삐거덕 되는 바람에 잘 사용하고 있는지에 대해 계속해서 의문이 들어 제대로 배워서 프로젝트를 개선해보고자 하는 마음에 신청했다.

결과적으로 비싼 금액(회사 복지포인트로 구매했긴 한데... 여튼)이지만 만족했고, 넥스트스텝의 강의들은 본인이 하고자 하는 의지만 있으면 실력을 몇 단계나 올릴 수 있는 개발의 터닝포인트가 될 수 있는 강의들이라 생각한다.(이런 넥스트스텝을 신입 온보딩으로 활용하는 카xx나 여타 기업들의 복지가 부러울 따름이다.)

+ 참고로 이전에는 정보가 없어서 잘 모르겠지만 DDD강의는 작년과 올해 비싼 금액임에도 인기가 많아 강의가 오픈된 지 x분 이내로 마감이 되었다. 그러니 혹시라도 수강할 마음이 있는 분이라면 아마 다음번에도 오픈런을 해야 할 것이다.

아래는 DDD 관련하여 읽으면 좋은 아티클들을 모아봤다.

저작자표시 동일조건