DDD START

2022-09-12

chapter 1

도메인 시작

 이 챕터는 도메인 모델과, 도메인 모델을 엔티티와 밸류로 분류하여 개념을 사용하고 있다.

DDD와 MSA에 대한 시도로 블로그 등을 통해 접했던 내용이지만 아주 쉽게 설명한 글을 통해 다시 한 번 정리할 수 있었다.

 또한, 작년 우테코 PRO에서 객체지향코드를 강조하며 객체에 불명확한 set 메서드 네임에 대한 이유를 다시 보게 되면서 반가운 감이 있었다. 이를 인지한 상태에서 메서드를 정의할 때, 엔티티에서는 set이 오히려 적절하다고 생각하는 경우가 많아 예시처럼 anti pattern, 피해야하는 규칙을 생각하기 보단 우선적으로 고려하는 것에 따르는게 좋다고 생각하고 있다. 네이밍 같은 경우 책에서 얘기하는 의미 전달이다.

 또한 밸류 타입에서 불변객체 사용과 장점을 얘기 하였는데 공감하고 사용하려고 노력하는 터라 주니어에게 좋은 정보라고 생각한다.

 

2022-09-12

chapter 2

아키텍처 개요

- 아키텍처

- DIP

- 도메인 영역의 구성요소

- 인프라스트럭처

- 모듈

 이 챕터에서는 흔히 사용하고 있는 계층 구조의 구성에 대한 설명과 함께 중요한 개념이 되는 상위 계층에서 하위 계층으로의 의존만 존재하고, 하위 계층은 상위 계층을 의존하지 않는다는 규칙과, 이럴 경우 상위계층에서 하위 계층의 의존으로 인해 테스트가 힘들고, 변경에 취약한 점을 설명하고 적절하게 이를 해결하기 위한 객체지향의 원칙 중 하나인 DIP(Dependency Inversion Principle): 의존 제어 역전 원칙을 통한 해결법을 보여준다. 1장에서 느꼈던 거지만 정말 개발을 시작하는 주니어에게 필요한 지식을 쉽게 잘 설명하고 있는 것 같다.

또한, DIP의 주사항을 얘기하며 DIP의 핵심은 고수준 모듈이 저수준 모듈에 의존하지 않도록 하기 위함인데 구조만 보고 저수준 모듈에서 인터페이스를 추출하면서 DIP를 올바르게 적용한 것이라 착각할 수있는 점을 짚어줬다.

도메인 영역의 구성요소로는 엔티티, 밸류, 애그리거트, 리포지터리, 도메인 서비스가 있으며 간단한 설명을 하고 있다.]

애그리거트는 관련 객체를 하나로 묶은 것을 말한다. 대표적인 예로 주문, 배송지 정보, 주문 목록, 총결제 금액을 포함하고 있는 주문을 들 수 있다.

 

2022-09-17

chapter 3

애그리거트

 애그리거트는 프로그래밍을 하면서 자주 마주치는 개념이다. 때문에 대략적으로 이해하고 있었는데 이 챕터를 통해 좀 더 구체적으로 알게 되었다. 애그리거트는 군집화란 것만 이해하고 넘어 갈 수 있는데, 모델링을 할 때 이를 활용한다면 쉽게 표현할 수 있게 된다. 

 1. 일관성을 관리하는 기준으로 애그리거트를 나눈다.

 2. 즉 유사한 개념으로 모으는 것으로 끝나는 것이 아닌, 동일한 라이프사이크를 갖는 객체를 모아 애그리거트를 이루게 한다.

 3. 애그리거트 루트의 핵심은 일관성이 깨지지 않도록 한다.

이를 통해 단위를 나누고 추상화 한다면 쉽게 이해할 수 있는 모델 관계를 그릴 수 있다. 

이 챕터에서 다루고 있는 많은 개념은 여기서 출발하고 끝난다. 이를 바탕으로 트랜잭션 관리, 리파지토리 설계를 할 수 있을 것이다.

 

2022-09-18

chapter 4, 5

리포지터리와 모델구현, 리포지터리의 조회 기능

 애그리거트로 나눈 모델들을 저장소에 저장하고 다루는 방법을 다룬다. 실제로 위 개념을 잘 이해하고 있다 하여도 외부 저장소에 저장하고 꺼내려고 하면 많은 제약과 어려움에 부딪힌다. 자바의 표준 ORM인 JPA를 이용하여 리포지터리와 애그리거트를 구현하는 방법을 설명한다. 

 두 챕터에선 엔티티와 밸류 매핑, 밸류 컬렉션 매핑, 애그리거트 로딩 전략과 영속성 전파, 식별자 생성 기능, 동적인 조회를 위한 JPA스펙 구현, 정렬과 페이징 등 전반적인 기능을 잘 설명해주고 있고, 또한 JPA의 많은 옵션과 기능들의 예시를 보여준다.

비록 점점 더 MSA로 넘어가고, nosql사용 비중이 높아지며 모델들의 매핑 관계가 단순화되고 있지만, 유용한 옵션과 사용 예시를 잘 보여주고 있다. 특히, 무심코 쓰고 있는 JPA의 구현과 로직이 어떻게 돌아가는지 이해하는데 도움이 되는 내용이 많이 들어 있다.

2022-09-21

chapter 6 응용 서비스와 표현 영역

- 응용 서비스 구현

- 표현 영역의 역할

- 값 검증과 권한 검사

이 장에서는 MVC 패턴과 객체지향에 대해 경험이 있는 사람이라면 자연스럽게 읽어 나갈 내용들이 담겨져 있다.

사용자에게 기능을 제공하기 위해 도메인과 사용자 사이에 표현 영역과 응용 영역을 거치게 되는데 이 영역간 역할에 대한 내용이다.

흔히 controller를 표현영역, service를 응용 영역이라 하고 각 영역별 책임을 구분한다.

책에서 말하는

표현 영역의 책임

•  사용자가 시스템을 사용할 수있는 화면 흐름을 제공하고 제어
• 사용자의 요청을 알맞는 응용 서비스에 전달하고 결과를 사용자에게 제공
• 사용자의 세션을 관리

즉 사용자로부터 요청받아 필요한 작업을 수행할 응용 계층으로 연결해주고 결과를 사용자에게 전달하는 것이다.

여기서 생각할 점은 비즈니스 로직은? 응용 계층.

수행할 응용 서비스들이 여기저기 흩어져 있다면? 억지로 한 서비스에 뭉쳐 결합도와 크기를 높이지 말고 각개 호출

(결과를 반환받아 사용자에게 원하는 값을 전달하는 것은 비즈니스 로직이라기보단 표현 영역에 가까움)

단순 조회인 경우는? 굳이 응용 서비스를 만들 필요 없이 응용 계층에서 조회 전용 기능을 사용한다. 응용 서비스가 꼭 존재하고 거쳐야 한다는 강박관념을 가질 필요는 없다. 하지만 팀 내에서 최근에는 규칙에 대한 강박이 있어, 단순 조회기능이라도 반드시 응용계층을 거치는 것으로 결정 되었는데 유연함에 대해 기회가 된다면 다시 나눠보면 좋을 것 같다.

값 검사는? 필수 값, 값의 형식, 범위 등을 검증

 

응용 영역의 책임

• 사용자가 요청한 기능을 실행
• 트랜잭션 처리
• 도메인 이벤트 처리

 역할을 설명하며 응용 서비스가 도메인 영역과 표현 영역을 연결해주는 창구인 파사드(facade) 역할을 한다고 말한다.

면접에서 디자인 패턴에 대해 물어보면 파사드 패턴에 대한 얘기는 거의 없다. 들어는 봤지만 사용해보지도 않은 생소하다고 말한다. 하지만 우리는 응용 서비스에서 비즈니스 로직을 제어하고 네이밍을 이에 맞게 작성하는데 이것이 바로 파사드 패턴이라고 할 수 있다.

즉, 인지하지 못했지만 파사드 패턴을 적극적으로 사용해오고 있는 셈이다.

 

2022-09-21

chapter7 도메인 서비스

- 도메인 서비스

 

 한 애그리거트로 기능을 구현할 수 없을 때가 많다. 여기서는 결제 금액 계산 로직을 예로 두고 있다.

 이런 경우에는 어떻게 해야 할까? 주문과 같이 어느 한 애그리거트에서 담당하게 해야 할까? 이렇게 해결 할 수도 있지만 이런 경우 결제 금액 계산에서 할인 정책은 주문의 구성요소와는 거리가 멀지만 주문에서 책임을 갖게 된다. 이렇게 억지로 특정 애그리거트에서 구현하게 되면 자신의 책임의 범위를 넘어서는 기능을 구현하기 때문에 코드가 길어지고 외부에 대한 의존이 높아지게 된다. 

 도메인 서비스

 애그리거트에서 처리가 애매한 경우에는 도메인 서비스를 이용해서 도메인 개념을 명시적으로 드러내면 된다. 응용 서비스가 응용 로직을 다룬다면 도메인 서비스는 도메인 로직을 다루는 것이다.

 도메인 영역의 애그리거트나 밸류와 다른 점은 상태없이 로직만 구현하는 점이다. 도메인 서비스를 구현하는 데 필요한 상태는 전달 받아 처리한다.

 그리고 챕터에서 주의를 주는 것은 도메인 서비스 객체를 애그리거트에 주입하지 않는 것이다. 일단 기본적으로 상위 계층에서 하위 계층을 의존하는 관계에 반대로 하위 도메인에서 서비스를 의존하게 되고, 도메인의 모든 필드와 기능에서 필요하지 않고 일부 기능에서만 필요로 하는데 의존할 이유도 적은 것이다.