도메인 주도 설계 철저 입문

도메인 주도 설계 철저 입문 - YES24

도메인 주도 설계 철저 입문 - YES24

 

후기

 

도메인 주도 개발이 궁금해서 읽은 책이다.

도메인 주도 개발은 Domain Driven Development 를 줄여서 DDD 라고도 한다. 

개발할 때 기본적으로 entity, service, repository 로 나누는 것을 밑바탕으로 깔고 간다.

이것들의 근간이 도메인 주도 개발에서 나온 것이다.

 

가장 먼저 값 객체와 엔티티를 설명한다. 값 객체와 엔티티의 차이점은 엔티티는 수명주기가 존재한다는 것이다. 예를 들어 값 객체가 자동차라면 엔티티는 '번호판이 1234인 2020년에 출고된 자동차' 라고 할 수 있다. 이 값 객체와 엔티티를 사용해서 도메인을 모델링 하게 된다.

 

저자는 도메인의 핵심 역할들이 곳곳에 퍼지지 않도록 해야 한다고 말한다. 

예를 들어 동아리를 만들 때 이름이 5글자를 넘어 갈수 없다고 하자.

이 제약이 동아리 라는 클래스의 생성자 안에 들어있다면 관리가 편하다. 만약 동아리와 관련된 다른 메서드 코드 곳곳에서 제약을 체크 하는 것은 수정 시에 모든 코드를 찾아 다녀야 하므로 좋지 않다.

또한 레포지토리를 따로 만든 이유는 서비스 코드의 가독성을 높이고 SQL 관련 레포지토리의 재사용성을 높이기 위함이라고 한다.

 

또 기억에 남는 것은, 도메인이 서로 침범 하지 말라는 것이었다.

예를 들어 동아리원을 추가하는 경우

동아리를 circle, 동아리원을 member, 새로운 동아리원을 newMember 라고 하면, 동아리원의 이름을 바꿀 경우

circle.members.add(newMember) 보다

circle.Join(newMember) 으로 구현을 하라는 것이다.

왜냐하면 동아리원의 추가는 동아리 객체의 책임 이기 때문에 멤버라는 도메인 영역을 침범하지 말라는 것이다.

 

이 외에도 깨알같이 다양한 팁들이 곳곳에 숨겨져 있다. 개발 외적으로 팀 안에서 도메인 관련 용어를 통일 시켜야 한다는 것, 도메인 전문가의 니즈를 팀장을 통해 거치는 것도 좋지만 직접 듣고 소통해보라고 하는 것 등 코딩 외적으로 개발하면서 느꼈던 공감가는 내용도 많이 있었다.

 

나는 도메인 주도 개발이 애자일과 MSA에도 영향을 끼친 것이 아닐까 하는 생각이 들었다.

과거에 거대했던 어플리케이션이 도메인 단위의 어플리케이션들로 나뉘어 MSA가 되었다.

애자일을 효과적으로 수행하기 위해 기획 팀, 디자인 팀, 개발 팀 등 수직적으로 나뉘었던 것들이 특정 도메인 서비스 팀의 기획, 디자인, 개발 로 묶이게 되면서 수평적으로 변했다.

도메인 주도 개발은 어느 새 곳곳에 스며든게 아닐까 생각해본다.

 

저자는 책의 내용은 절대적 진리가 아니며, 취사 선택해도 되고 더나은 방안이 생각할 수 있다면 그것을 따르라고 한다.

책의 마지막 구절을 인용하면서 끝내려고 한다.  

"코드를 어떻게 배치할지 그 이유는 무엇인지 스스로에게 자문하면서 최적의 솔루션 구성을 찾아가는 마음가짐을 갖기 바란다." 

항상 이러한 마음 가짐으로 코드를 작성할 수 있도록 노력해야겠다.