Update Technology Post " DDD 세레나데 7기, 5주간의 여정을 돌아보며 "

- 용어 사전 만들기, 모델링하기 관련 그림 추가

Author: devFancy

_posts/2025-03-15-DDD-Serenade-7th-Review.md

@@ -33,32 +33,40 @@ DDD 세레나데 7기에 참여하면서 도메인 주도 설계(DDD)의 기본
 
 * [3단계 - 기능 우선 패키지 구성하기](https://github.com/next-step/ddd-strategic-design/pull/509)
 
-이번 미션은 **페어 프로그래밍(두 명이 함께 작업하는 방식)** 으로 진행되었지만, 일정 조율이 어려워 각자 미션을 수행하는 방식으로 합의하여 진행했습니다.
+이번 미션은 페어 프로그래밍(두 명이 함께 작업하는 방식)으로 진행되었지만, 일정 조율이 어려워 각자 미션을 수행하는 방식으로 합의하여 진행했습니다.
 
 ### 용어 사전 만들기
 
 이번 미션을 수행하면서 용어 사전과 모델링을 작성한 경험이 있었지만, 예상보다 더 구체적으로 작성해야 한다는 점이 기억에 남습니다.
 
-특히, 용어 사전은 단순한 리스트가 아니라 한글명, 영문명, 그리고 구체적인 설명이 포함되어야 하며, **개발자뿐만 아니라 비개발자도 이해할 수 있어야 한다는 점**이 중요했습니다.
+특히, 용어 사전은 단순한 리스트가 아니라 한글명, 영문명, 그리고 구체적인 설명이 포함되어야 하며, 개발자뿐만 아니라 비개발자도 이해할 수 있어야 한다는 점이 중요했습니다.
 
 이에 따라 용어 사전을 아래와 같은 방식으로 정리했고, 리뷰어님께 해당 정의가 적절한지 피드백을 요청했습니다. 다행히도 제가 생각했던 방향과 동일하다는 답변을 받을 수 있었습니다.
 
 > `용어 사전` 이란 프로젝트(또는 서비스)에 참여하는 도메인 전문가, 개발자, 그리고 기획자·디자이너·데이터 분석가 등 **다양한 직군 간의 의사소통을 명확하게 하기 위한 도구**라고 생각한다.
+>
+> 아래는 이전에 작성한 `용어 사전` 중 일부를 가져왔습니다.
+
+![](/assets/img/technology/DDD_Serenade_7th_Week2_1.png)
 
 ### 모델링하기
 
-모델링에 대해서는 처음에는 **도메인 내 객체의 속성(상태)을 구성하고, 객체 간의 관계를 표현하는 과정**이라고 생각했습니다.
+모델링에 대해서는 처음에는 도메인 내 객체의 속성(상태)을 구성하고, 객체 간의 관계를 표현하는 과정이라고 생각했습니다.
 
-그러나 미션을 진행하면서 다른 참여자들의 PR을 확인해본 결과, 단순히 객체의 속성을 정의하는 것만이 아니라, **속성(상태), 행위(기능), 정책(제약사항)** 으로 카테고리를 나누어 작성하는 방식이 더 적절하다는 점을 알게 되었습니다.
+그러나 미션을 진행하면서 다른 참여자들의 PR을 확인해본 결과, 단순히 객체의 속성을 정의하는 것만이 아니라, 속성(상태), 행위(기능), 정책(제약사항)으로 카테고리를 나누어 작성하는 방식이 더 적절하다는 점을 알게 되었습니다.
 
 리뷰어님께서도 모델링은 어떻게 표현하느냐에 따라 다를 수 있으며, 대상에 따라 깊이와 디테일이 달라져야 한다는 피드백을 주셨습니다.
 * 기획자, 상위직책자 분들에게 디테일 보다는 정확한 흐름과 팩트가 필요하다.
 * 협업 부서, 동료 개발자에게는 보다 디테일한 내용이 추가되어야 한다.
 
-이번 2단계에서 작성한 모델링은 협업 부서 및 동료 개발자에게 제공할 목적이었기 때문에, 속성(상태), 행위(기능), 정책(제약사항)으로 구분하여 더 구체적으로 작성했습니다.
+이번 2단계에서 작성한 모델링은 협업 부서 및 동료 개발자에게 제공할 목적이었기 때문에, **속성(상태), 행위(기능), 정책(제약사항)으로 구분**하여 더 구체적으로 작성했습니다.
 
 요구사항을 기반으로 모델링을 도출하다 보면 자연스럽게 중복되는 부분이 생깁니다. 하지만 이는 도메인에 대한 이해를 더욱 명확하게 정리하는 과정으로 볼 수 있습니다.
 
+> 아래는 이전에 작성한 `모델링하기` 중 일부를 가져왔습니다.
+
+![](/assets/img/technology/DDD_Serenade_7th_Week2_2.png)
+
 ### 2주차 복습하기
 
 > 2주차에서 배운 개념(용어)들을 필자의 개인적인 생각과 함께 정리했습니다.
@@ -97,7 +105,7 @@ DDD 세레나데 7기에 참여하면서 도메인 주도 설계(DDD)의 기본
     * 애그리거트는 관련 객체들을 하나로 묶은 군집을 의미합니다.
         * 이는 특정 객체의 타입이 아니라, 관련 객체들을 논리적으로 묶는 구조를 의미합니다.
     * `레포지토리`는 **애그리거트 단위로 도메인 객체를 저장하고 조회하는 기능을 정의**합니다.
-        * **애그리거트(루트) 단위로 존재**하며 테이블 단위로 존재하지 않습니다.
+        * 애그리거트(루트) 단위로 존재하며 테이블 단위로 존재하지 않습니다.
         * JPARepository, CrudRepository 등의 인터페이스를 활용하여 레포지토리를 구현할 수 있습니다.
         * 다만, 이는 JPA 관점에서의 레포지토리이지, DDD에서의 레포지토리 개념과 동일하지 않을 수도 있습니다.
 
@@ -107,7 +115,7 @@ DDD 세레나데 7기에 참여하면서 도메인 주도 설계(DDD)의 기본
 3주차에서는 전술적 설계(Tactical Design) 를 기반으로 기존 코드를 **도메인 중심으로 리팩터링**하는 과정이 진행되었습니다.
 이전 주차가 개념 학습과 문서화 중심이었다면, 이번 주차부터는 본격적으로 실제 코드에 DDD 개념을 적용하는 과정이 핵심이었습니다.
 
-이번 미션에서는 상품, 메뉴, 매장 식사 주문과 관련된 도메인을 리팩터링하며, **도메인 중심으로 설계를 변경하고 비즈니스 로직을 보다 명확하게 분리하는 작업**을 수행했습니다.
+이번 미션에서는 상품, 메뉴, 매장 식사 주문과 관련된 도메인을 리팩터링하며, 도메인 중심으로 설계를 변경하고 비즈니스 로직을 보다 명확하게 분리하는 작업을 수행했습니다.
 
 3주차에 진행한 미션에 대한 결과는 아래와 같습니다.
 
@@ -136,14 +144,14 @@ DDD 세레나데 7기에 참여하면서 도메인 주도 설계(DDD)의 기본
 
 > 양방향 의존성 문제 해결
 
-리팩터링 과정에서 가장 고민했던 부분 중 하나는 **상품과 메뉴 간의 양방향 의존성 문제**였습니다.
+리팩터링 과정에서 가장 고민했던 부분 중 하나는 상품과 메뉴 간의 양방향 의존성 문제였습니다.
 
 기존 코드에서는 `상품`과 `메뉴`가 서로 직접 참조하는 구조를 가지고 있었습니다.
 즉, `상품`이 변경될 경우 `메뉴`도 영향을 받고, 반대로 `메뉴`에서도 `상품`을 직접 조회해야 하는 경우가 많았습니다.
 
 이러한 양방향 의존성은 코드의 복잡성을 높이고, 유지보수를 어렵게 만들 수 있는 문제였습니다.
 
-이 문제를 해결하기 위해 도메인 이벤트(Domain Event) 패턴을 적용했습니다.
+이 문제를 해결하기 위해 **도메인 이벤트(Domain Event) 패턴**을 적용했습니다.
 * 상품은 본인의 역할만 수행하도록 하고, 
 * 메뉴는 상품에서 발생한 이벤트를 수신하여 후속 작업을 수행하도록 변경했습니다.
 
@@ -271,7 +279,7 @@ DDD는 단순히 이론으로 끝나는 것이 아니라, 실무에서 적용해
 > DDD를 실무에 적용하는 방식에 대한 고민
 
 DDD 개념을 실무에서 어떻게 자연스럽게 녹여낼 수 있을지에 대한 고민도 생겼습니다.
-단순히 **"DDD를 도입해보자!"** 라고 하는 것이 아니라,
+단순히 "DDD를 도입해보자!" 라고 하는 것이 아니라,
 * "우리 용어 사전과 모델링을 작성해볼까요?"
 * "도메인이 파편화되어 있으니, 이번에 이벤트 스토밍을 적용해볼까요?"