DDD에 관해 꽤나 주관적인 해석을 담고 있습니다. DDD와 객체 협업에 대한 개인적인 생각나는 DDD를 좋아한다. 그 이유는 하나의 객체가 다루기 어려운 로직을 여러 객체의 협업을 통해 풀어나갈 수 있기 때문이다. 실제 비즈니스 로직을 모델링하다 보면, 단일 객체(여기서 말하는 객체란 엔티티)는 생각보다 많은 역할을 하지 못한다. 한 객체가 하는 일은 단순할 때가 많으며, 단순한 CRUD 수준이라면 유닛 테스트조차 무색하게 느껴지곤 한다.  하지만 여러 객체 간의 협업으로 모델링하면 비즈니스의 본질이 다루기 용이하고, 비로소 유닛 테스트가 검증해야 할 복잡도도 적절한 수준이 된다. (개인적으로 나는 로직이 충분히 복잡하지 않다면 테스트 코드의 가성비가 떨어진다고 생각한다.)  도메인 개요: 오징어 게임..

[주의] 이 글은 Common Sense의 범주에 벗어난 내용들이 일부 있을 수 있음을 알립니다. 그렇게 생각한 항목에 대해선🎃이모지로 표시하겠습니다. 3월에 바쁜 일이 너무 많이 있어서 밀린 포스팅이 한 가득이지만, 우선 DDD 세미나가 가장 최근에 있었기 때문에 여운이 아직 남아있을 떄 올리는 것이 좋다고 생각했다. 나는 DDD를 좋아한다. 그러나 아쉽게도 좋아한 세월에 비해 이해의 정도는 낮은 것 같았다. 공유 커널과 안티 코렙션 계층 등을 이용해서 무언가를 설계해 본적은 없기 때문이다. 이건 내가 코드 레벨에서의 이해도가 낮았기 때문에 도전 조차 못했던 것으로 느껴졌다. 그래서 그런지 평상시 좋아하는 모임에 DDD 강의가 열린다는 소식을 들었을 때는 무척 반가웠다. 발표한 사람은 평상시 모각코에서..

샘플 코드는 이곳에 있습니다 (Kotlin + Spring + JPA) 인터넷의 많은 문서들을 읽었으나 클린 아키텍처 등 고전 명서를 정독하지 않고 적은 글입니다 :) 감안 부탁드립니다.. ^^ 마침내 1년 가까이 한 번은 작성후 알아봐야지… 하고 생각만 했던 것을 작성해서 올렸다 (사실 구글링을 조금만 해보면 방대한 예시 코드들이 나온다… 어렵지 않게 공부할 수 있었다) 고대하던 헥사고날 예시코들 작성하면서 느낀 점을 기술한다… 요약 여러 형태의 설명을 해보자면 버전 1 DIP를 이용해서 비즈니스 로직을 클린하게/순수하게 두었음 버전 2 각 레이어간 인터페이스를 두어서 변경에 유연하게 만듬 구조 나처럼 레이어 아키텍처를 알고 있는 사람은 그걸 리펙터링한다고 생각해도 좋을 것 같다 기존의 레이어드 아키텍..