지금의 기록이 미래의 자산이 된다.
Today's records become tomorrow's assets.-
DDD 세레나데 7기, 5주간의 여정을 돌아보며
이 글은 넥스트스텝의 DDD 세레나데 7기 교육을 5주간 참여하며 배운 경험과 느낀 점을 정리한 후기입니다.
Prologue
아래는 DDD 세레나데 7기 교육을 무사히 끝마친 후 받은 수료증입니다.
DDD 세레나데 7기에 참여하면서 도메인 주도 설계(DDD)의 기본 개념부터 실전 적용까지 다양한 내용을 배울 수 있었습니다.
미션을 수행하며 리뷰어 피드백을 반영하는 과정이 큰 도움이 되었습니다.
1주차에 대한 리뷰는 이미 작성한 글인 DDD 세레나데 7기 1주차 (feat. 이벤트 스토밍) 를 참고하시면 되므로, 이번 글에서는 2주차부터 정리하고자 합니다.
2주차 - 전략적 설계
2주차에서는 DDD의 핵심 개념인 전략적 설계(Strategic Design) 에 대해 배우며, 특히
유비쿼터스 언어(Ubiquitous Language)와바운디드 컨텍스트(Bounded Context) 개념을 깊이 있게 다루었습니다.2주차에 진행한 미션에 대한 결과는 아래와 같습니다.
이번 미션은 페어 프로그래밍(두 명이 함께 작업하는 방식)으로 진행되었지만, 일정 조율이 어려워 각자 미션을 수행하는 방식으로 합의하여 진행했습니다.
용어 사전 만들기
이번 미션을 수행하면서 용어 사전과 모델링을 작성한 경험이 있었지만, 예상보다 더 구체적으로 작성해야 한다는 점이 기억에 남습니다.
특히, 용어 사전은 단순한 리스트가 아니라 한글명, 영문명, 그리고 구체적인 설명이 포함되어야 하며, 개발자뿐만 아니라 비개발자도 이해할 수 있어야 한다는 점이 중요했습니다.
이에 따라 용어 사전을 아래와 같은 방식으로 정리했고, 리뷰어님께 해당 정의가 적절한지 피드백을 요청했습니다. 다행히도 제가 생각했던 방향과 동일하다는 답변을 받을 수 있었습니다.
용어 사전이란 프로젝트(또는 서비스)에 참여하는 도메인 전문가, 개발자, 그리고 기획자·디자이너·데이터 분석가 등 다양한 직군 간의 의사소통을 명확하게 하기 위한 도구라고 생각한다.아래는 이전에 작성한
용어 사전중 일부를 가져왔습니다.
모델링하기
모델링에 대해서는 처음에는 도메인 내 객체의 속성(상태)을 구성하고, 객체 간의 관계를 표현하는 과정이라고 생각했습니다.
그러나 미션을 진행하면서 다른 참여자들의 PR을 확인해본 결과, 단순히 객체의 속성을 정의하는 것만이 아니라, 속성(상태), 행위(기능), 정책(제약사항)으로 카테고리를 나누어 작성하는 방식이 더 적절하다는 점을 알게 되었습니다.
리뷰어님께서도 모델링은 어떻게 표현하느냐에 따라 다를 수 있으며, 대상에 따라 깊이와 디테일이 달라져야 한다는 피드백을 주셨습니다.
- 기획자, 상위직책자 분들에게 디테일 보다는 정확한 흐름과 팩트가 필요하다.
- 협업 부서, 동료 개발자에게는 보다 디테일한 내용이 추가되어야 한다.
이번 2단계에서 작성한 모델링은 협업 부서 및 동료 개발자에게 제공할 목적이었기 때문에, 속성(상태), 행위(기능), 정책(제약사항)으로 구분하여 더 구체적으로 작성했습니다.
요구사항을 기반으로 모델링을 도출하다 보면 자연스럽게 중복되는 부분이 생깁니다. 하지만 이는 도메인에 대한 이해를 더욱 명확하게 정리하는 과정으로 볼 수 있습니다.
아래는 이전에 작성한
모델링하기중 일부를 가져왔습니다.
2주차 복습하기
2주차에서 배운 개념(용어)들을 필자의 개인적인 생각과 함께 정리했습니다.
도메인이란 우리가 해결해야할 영역 → 보통은 비즈니스 도메인이라 부릅니다.- 예시. 커머스
하위 도메인이란 도메인을 세부 도메인으로 나누는 것을 의미합니다.- 예시. 전시, 카탈로그, 상품, 주문, 결제, 정산
- 이런 하위 도메인은 자연스럽게 도출되는 개념이다. → 그만큼 하위 도메인은 제어할 수 없는 대상이 될 수 있습니다.
- 특정 하위 도메인의 비즈니스 가치가 크다면, 추가적으로 더 세부적인 하위 도메인을 정의할 수 있습니다.
하위 도메인과바운디드 컨텍스트의 차이점은 무엇인가요?- 하위 도메인은 자연스럽게 나뉘며, 바운디드 컨텍스트는 인위적으로 나뉩니다.(->의도적으로 구분하는 경계)
- 하위 도메인은 관심사이며, 바운디드 컨텍스트는 그 관심사를 구분짓는 경계로 간주됩니다.
- 언제
바운디드 컨텍스트를 분할해야 하나요?- 서비스가 커짐에 따라 복잡성이 높아질 때입니다.
- 또는 모두가 동일하게 이해하고 개발하기 편하도록 경계가 필요할 때입니다.
- 요구 사항과
도메인 모델링의 차이점은 무엇인가요?- 요구사항과 모델링은 만드는 사람(=주체)에 따라 달라진다고 생각됩니다.
- 요구사항은 클라이언트가 우리에게 문제를 해결해달라는 의미이고,
- 도메인 모델링은 그러한 문제를 해결하기 위한 아이디에이션(=아이디어 도출)입니다.
- 이러한 접근 방법을 표현하기 위하여 다이어그램, 글, 그림 등 다양한 도구를 활용합니다.
- 요구사항과 모델링은 만드는 사람(=주체)에 따라 달라진다고 생각됩니다.
도메인 엔티티와 영속성 엔티티의 차이점은 무엇인가요?- 도메인 엔티티는 식별자를 갖는 무언가입니다. -> 비즈니스적으로 중요한 개념
- 영속성 엔티티는 테이블 관점에서 도출됩니다. -> 데이터베이스 저장을 위해 도출된 개념
- 이 두 개(Persistence, 도메인 주도 설계)는 높은 확률로 동일할 수도 있고, 다를 수도 있습니다.
- 어떤 엔티티가 애그리거트에서 루트 엔티티가 될 수 있나요?
- 외부에 노출되어 있는지 여부에 따라 결정됩니다.
- 즉, 외부에 노출되어도 되는 엔티티인 경우 루트 엔티티가 될 수 있습니다.
- 애그리거트와 리포지토리는 어떤 관련이 있나요?
- 애그리거트는 관련 객체들을 하나로 묶은 군집을 의미합니다.
- 이는 특정 객체의 타입이 아니라, 관련 객체들을 논리적으로 묶는 구조를 의미합니다.
레포지토리는 애그리거트 단위로 도메인 객체를 저장하고 조회하는 기능을 정의합니다.- 애그리거트(루트) 단위로 존재하며 테이블 단위로 존재하지 않습니다.
- JPARepository, CrudRepository 등의 인터페이스를 활용하여 레포지토리를 구현할 수 있습니다.
- 다만, 이는 JPA 관점에서의 레포지토리이지, DDD에서의 레포지토리 개념과 동일하지 않을 수도 있습니다.
- 애그리거트는 관련 객체들을 하나로 묶은 군집을 의미합니다.
-
[리뷰] 삶의 태도를 돌아보는 면접의 질문들 - 면접을 넘어, 일하는 태도를 고민하다
이 글을 삶의 태도를 돌아보는 면접의 질문들 책을 읽고, 책의 내용을 정리하며 필자의 개인적인 생각을 함께 정리한 것입니다.
시작하며
이 책의 제목을 보면 처음에는 ‘면접을 어떻게 잘 볼 수 있을까?’라는 궁금증에서 읽기 시작했다.
하지만 책을 읽어갈수록, 면접 기술을 배우는 것을 넘어 면접이라는 과정이 어떤 의미를 가지는지 고민하게 되었다. 특히 직장인이라면, 면접을 단순한 평가가 아니라 자신의 일하는 방식과 태도를 되돌아볼 기회로 삼을 수 있다는 점에서 더욱 의미 있는 책이었다.
이 책은 단순히 면접을 잘 보는 법을 알려주는 것이 아니라, 자신이 해왔던 일들을 돌아보고, 앞으로 어떤 방식으로 일해야 하는지 고민할 기회를 제공하는 책이다. 필자는 책을 읽으며 정리한 내용을 개인적인 경험과 해석을 덧붙여 작성했다. 따라서 본문의 내용이 실제 책과 100% 일치하지 않을 수 있다는 점을 미리 밝힌다.
-
DDD 세레나데 7기 1주차 (feat. 이벤트 스토밍)
이번 글은 DDD 세레나데 7기의 1주차에 대한 필자의 자극히 개인적인 후기입니다. 혹시 문제가 되는 부분이 있다면, 언제든 말씀해 주시면 감사하겠습니다. ☺️
Prologue
2023년, 2024년에 상반기까지는
코드에 집중해서 그런지, 2024년 하반기부터는코드보다는설계쪽에 관심이 생겼다.그래서 ‘설계를 어떻게 하면 잘할 수 있을까?’에 대해 스스로 고민을 하면서 처음에는
멀티 모듈에 대해 먼저 공부를 하게 되었다.멀티 모듈과 관련된 영상을 보면서 현업 개발자분들이 왜 사용하고 어떤 이점이 있는지를 알게 되면서 이와 관련된 글을 블로그에 작성한 바 있다.(멀티 모듈과 관련해서 이전에 작성한 글 - Kotlin, SpringBoot 기반으로 멀티 모듈 설계와 적용하기)
멀티 모듈에 대해 도움이 되었던 대표적인 영상과 자료는 아래와 같습니다. 이 외에도 다양한 영상과 자료를 참고했으나 이 글에서는 중요한 부분이 아니므로 생략했습니다.
멀티 모듈에 대해 이론적으로나마 어떤 내용인지는 이제 알게 되었다. 그런 다음에 ‘IT 회사는 현재 시점으로 지난 3년간 어떤 설계에 관심을 가지고 있을까?’에 대한 궁금증이 생겼다.
그 결과 흔히 알고 있는 여러 IT 회사에서
도메인 주도 설계(Domain Driven Design)을 현업에서 사용하는 것을 찾게 되었다. (이후 아래부터는 도메인 주도 설계를DDD라는 단어로 표현하겠다)DDD 관련 영상과 자료들은 아래와 같습니다. (
최신순으로 내림차순 정렬)이 외에도 다양한 영상과 자료가 있습니다.
-
SIPE 커뮤니티를 위한 슬랙 봇 만들기 (feat. 사이프톤)
Prologue
SIPE는 개발자들이 함께 교류하며 성장하는 IT 커뮤니티입니다. 이곳에서는 다양한 활동이 이루어지며, 그중 하나인
사이프톤은 SIPE 구성원들과 외부 참여자가 하루 동안 함께 진행하는 해커톤입니다.저는 이번 SIPE 3기의 사이프톤에서 커뮤니티에 작은 기여를 하고자
슬랙봇개발을 주제로 참여하게 되었습니다. 이번 글에서는 슬랙봇을 개발하게 된 이유와 진행 과정, 그리고 사이프톤을 마치고 난 느낌을 기록하고자 이 글을 작성하게 되었습니다.
-
2025 Dev History
2025 Dev History
- 2024 Dev History에 이어 2025년에도 내가 공부하면서 배운 내용을 꾸준히 기록해두자.
- DevHistory 3
- Java 10
- Spring 15
- SpringBoot 12
- JPA 13
- MySQL 3
- Flyway 1
- Technology 15
- GoodCode 6
- Side_Project 20
- Retrospective 4
- AlgorithmSkill 3
- LeetCode 2
- Algorithm 70
- SQL 9
- OS 14
- Database 8
- Network 7
- HTTP 7
- DataStructure 5
- Linux 3
- Woowacourse 4
- Git 9
- AssertJ 1
- IntelliJ 5
- Probability-Statistics 5
- Electronic-Finance 13
- Business-Statistics 13
- Competition 1
- Book 3
- Workout 7
- E.T.C 7