한주간 느낀점
이번주는 프로젝트의 DDD(Domain Driven Design)을 작성하는 시간을 가졌다. 참고로 우리 프로젝트의 주제는 패션 품평 및 멘토링 커뮤니티이다.
DDD를 개발을 공부하면서 처음 작성해 보았는데, 생각보다 어려웠고 작성하면서도 이해가 잘되지 않았다. 그것 때문에 DDD 관련으로 팀원들과 많은 회의를 한 주간 했었다.
새롭게 배운점
DDD
소프트웨어를 업무 도메인 모델(비즈니스 개념, 규칙, 용어)중심으로 설계, 구현 하는 방법론/ 사고방식
도메인 전문가와 개발자가 같은 언어로 모델을 다듬으며 복잡도를 줄이고 변화에 강한 시스템을 만든다.
Event storming
프로젝트 팀원들과 포스트잇을 붙이는 단계
Domian Event
도메인 내에서 중요한 사건이나 변화를 나타내는 사건을 붙인다.
왼쪽에서 오른쪽으로 시간의 변화를 나타내고 과거시제로 이름이 지어진다.
시제가 같으면 위에서 아래로 배타적인 관계를 표현한다.
External System
도메인의 외부시스템을 붙인다.
다른 이벤트와 상호작용하는 외부이벤트 혹은 인터페이스를 표현한다.
Command Deduction
시스템에 특정한 동작이나 행동을 수행하도록 요청하는 기능을 붙인다.
Hot Spot
변경이나 확장성이 빈번하게 발생할 것으로 예상되는 영역에 의문점, 메모 등을 붙인다.
Actor
도메인이나 시스템과 상호작용하는 사용자(엑터)나 시스템을 붙인다.
Aggregate
관련된 객체와 엔터티의 클러스터 역할을 하며 대표 엔터티로서 외부 객체가 해당 어그리것과 상호작용할 때 사용하는 역할을 한다.
Bounded Context
관련 있는 것들의 묶음 표현이다.
Policy
특정한 조건이 충족될 때 어떤 행동이나 연산이 발생해야 하는지를 정의한 규칙이나 지침이다.
Context Mapping
Snap E
Keep
시간관리하는 방법을 이제야 좀 몸에 적응한 것같다. 프로젝트를 진행하면서 코딩테스트 공부와 복습을 하는 법의 요령을 터득한 것같다. 한 번에 많이 진행하려고 하는 것보다는 조금씩 많은 일을 진행하는 것이 방법인 것같다.
Problem
프로젝트 회의를 진행하면서 팀원들과 여러 의견 충돌이 있었다. 다들 자기주장이 강해서 그런것 같다. 회의가 끝나고는 다들 괜찮다고 했지만, 언성이 조금씩 커지면서 알게 모르게 기분이 나빴을 수도 있었을 것이라 생각된다. 그래도 어찌저찌 DDD를 마치고 요구사항 명세서 작성과 DB 모델링을 시작할 수 있게 되었다.
Try
다음 회의 때는 조금은 배려하면서 경청하는 자세로 회의를 진행해야 겠다. 물론 각자의 강하게 의견을 주장하는 것은 나쁘지 않지만, 회의가 생각보다 길어지는 문제가 발생해서 회의 시간 내에 의견을 통합하는 법을 나 뿐만 아니라 팀원들도 알아야 겠다고 생각했다.
다음주 계획 혹은 다짐
요구사항 명세서와 DB모델링을 원활하게 끝내고 빠르게 스프링 서버 개발로 넘어가는 것이 목표이다.
