.summary(도메인 주도 설계 철저 입문)

http://www.yes24.com/Product/Goods/93384475

나루세 마사노부 저/심효섭 역

 

p25
비교수단을 객체에서 제공할 경우 새로운 속성 추가하는건 비교적 쉬워진다.

p27
값 객체로 다루어야할지에 대한 필자의 기준
- 규칙이 있는가
- 낱개로 다루어야하는가


p32
값 객체는 결코 데이터를 담는 것만이 목적인 구조체가 이나다.
값 객체는 데이터와 더불어 데이터에 대한 행동을 한곳에 모아둠으로써 자신만의 규칙을 갖는 도메인 객체가 된다.

p33
값 객체의 장점
- 표현력이 증가한다.
- 무겱성이 유지된다.
- 잘못된 대입을 방지한다.
- 로직이 코드 이곳저곳에 흩어지는 것을 방지한다.

p40
DRY(Do not Repeat Yourself)원칙에서 밝혔듯이 코드 중복을 방지하는 일은 매우 중요하다.
중복된 코드가 많아지면 코드를 수정하는 난도가 급상승한다.

p46
도메인 주도 개발에서 말하는 엔티티는 도메인 모델을 구현한 도메인 객체를 의미한다.
값 객체와 구차이점은 동일성을 통해 식별이 가능한지 여부, 속성과 별개
ex) 사람 속성의 예로 나이, 체중, 취미 등..

p47
값 객체 vs 엔티티
엔티티는
- 가변이다.
- 속성이 같아도 구분할 수 있다.
- 동일성을 통해 구별된다.

p55
생애주기의 존재 여부와 그 생애주기의 연속성 여부가 중요한 판단기준이다.
생애주기를 갖지 않거나 생애주기를 나타내는 것이 무의미한 개념이라면 우선 값 객체로서 다루는 것이 좋다.

p56
도메인 객체를 정의할 때의 장점은 다음 2가지다.
- 자기 서술적인 코드가 된다.
- 도메인에 변경사항이 있을 시 코드에 반영하기 쉽다.

p62
시스템에는 값 객체나 엔티티로 구현하기 어색한 행동도 있다.
도메인 서비스는 이런 어색함을 해결해주는 객체다.
ex) 아이디 중복여부 체크

p65
도메인 서비스는 자신의 행동을 바꿀 수 있느 ㄴ인스턴스만의 값을 갖지 않는다는 점에서 값 객체나 엔티티와 다르다.

p68
자신이 제공할 수 잇는 정보가 없는 도메인 객체를 빈혈 도메인 모델이라고 한다.

p73
도메인 서비스의 기준
- 필자는 도메인에 기초한 서비스라면 도메인 서비스여야한다.
- 애플리케이션을 만들며 필요하게 된 것이라면 도메인 서비스가 아니다. 그건 애플리케이션 서비스다.

p81
리포지토리의 책임은 도메인 객체를 저장하고 복원하는 퍼시스턴시다.

p94
테스트만을 위해 특정한 인프라를 갖추는 것은 매우 번거롭다.
인스턴스를 저장하는 매체로 메모리를 이용하고 싶을 때 가장 쉬운 방법은 딕셔너리다.

p99
UserDataModel라는 엔티티로 데이터 모델을 만든다. 
이는 도메인 객체의 엔티티와는 별개다.

p106
애플리케이션 서비스는 유스케이스를 구현하는 객체다.
애플리케이션은 일반적으로 이용자의 목적에 부응하는 프로그램을 의미한다.

p114
도메인 객체는 비공개로 남겨두고 클라이언트에 데이터 전소을 위한 객체(DTO, data transfer object)를 만들어 영기에 데이터를 옮겨 넣어 반환하는 방법이다.

p121
커맨드 객체를 사용하면 시그니처를 매번 수정할 필요가 없다.
=> 커맨드 객체로 받아서 내부에서 분기처리하여 수정내용을 처리한다.

p123
커맨드 객체는 어떤 처리의 파사드 역할을 한다.
파사드는 건물의 겉면이 내부의 복잡한 구조를 가려주듯이 복잡한 코드를 간략화해 노출하는 인터패이스를 의미한다.

p124
에러냐 예외냐
에러는 클라이언트에 실패에 대한 핸들리을 위임
예외는 에러 핸들리을 개발자에게 강제한다. 

p134
응집도를 측정하는 방법에는 LCOM(Lack of Cohesion in Methods)라는 방식이 있다.

p138
UserService -> UserRegisterService로 분리한다. 응집도를 높이는 방향으로 코딩.

p140
코드로 응집된 클래스를 패키지로 묶어준다.
UserService -> UserRegisterService, UserUpdateService 를 하나의 패키지에 넣는다.

p153
의존관계 역전 원치(DIP, Dependency Inversion Principle)
A. 추상화 수준이 높은 모듈이 낮은 모듈에 의존해서는 안 되며 두 모듈 모두 추상 타입에 의존해야 한다.
B. 추상 타입이 구현의 세부 사항에 의존해서는 안 된다. 구현의 세부 사항이 추상 타입에 의존해야 한다.

프로그램에는 추상화 수준이라는 개념이 있는데, 추상화 수준은 입/출력으로부터의 거리를 뜻한다.
추산화 수준이 낮다는 것은 기계와 가까운 구체적인 처리를 말하며, 추상화 수준이 높다는 것은 사람과 가까운 추상적인 거리를 말한다.
ex) service에서 repository를 호출하는 관계라면 repository가 service보다 추상화 수준이 낮다고 할 수 있다.

p157
Service Locator패턴
ServiceLocator객체에 의존 해소 대상이 되는 객체를 미리 등록해 둔 다음, 인스턴스가 필요한 곳에서 ServiceLocator를 통해 인스턴스를 받아 사용하는 패턴이다.
단점
- 의존관계를 외부에서 보기 어렵다.
- 테스트 유지가 어렵다.

p162
IoC Container 패턴
Dependency Injection 패턴은 의존관계 주입
- 테스트 코드에 수정을 강제하는 장점이 있다. (테스트 코드 유지에 유리하다.)
- 의존하는 객체를 만드는 코드를 여기저기 작성해야하는 단점이 있다.
DI패턴만 있을 때의 단점을 보안하기 위해 IoC Container패턴을 사용한다.
이를 이용하면 주입될 인스턴스 관리를 컨테이너에서 해주게 된다.

p170
싱글턴 패턴에 대한오해
싱글턴을 사용하는 이유는 인스턴스 개수를 하나로 제한하면서도 일반적인 객체처럼 다루기 위해서다.
static에서 누릴 수 없는 다형성과 같은 객체 지향 프로그래밍의 장점을 그대로 활용할 수 있다.

p181
Controller의 책임은 입력을 변환하는 것이다.
컨트로럴의 역할은 사용자의 입력을 모델이 요구하는 메세지로 변환해 모델에 전달하는 것이다.

p196
시퀀스를 이용해 번호를 매기는 팩토리의 구현이다.

p199
팩토리의 존재감 인식시키기
- 도메인 객체와 같은 위치의 패키지에 팩토리 클래스를 만든다.

p205
다형성의 장점을 누릴 수 있게 팩토리를 만들기도 하지만, 이와 달리 단순히 생성 절차가 복잡한 인스턴스를 만드는 코드를 모아둔 팩토리를 만드는 것도 좋은 습관이다.
'생성자 메서드 안에서 다른 객체를 생성하는가'라는 질문은 팩토리의 필요성을 나타내는 좋은 지표라고 할 수 있다.

p208
무결성이란 '서로 모순이 없고 일관적'

p212
유일 키 제약(데이터베이스 기능)에 중복 확인을 맡겼을 경우의 문제점
- 코드에 드러나지 않는 메커니즘을 알아챌 수가 없다.
- 특정 기술 기반에 의존하는 부분이 생긴다.

p219
트랜잭션 범위를 사용하는 패턴
트랜잭션 범위는 트랜잭션의 수행 범이ㅜ를 정의하기 위한 것이다. 
@Transactional은 트랜잭션 범위와 같은 기능을 제공한다.
데이터 무결성을 필요로 한다는 의미가 내포되어있음

p222
유닛오브워크를 사용하는 패턴
유닛오브워크는 어떤 객체의 변경 사항을 기록하는 객체다.
=> https://java-design-patterns.com/patterns/unit-of-work/

p250
애그리게이트
불변 조건을 유지하는 단위로 꾸려지며 객체 조작의 질서를 유지한다.
애그리게이트는 경계와 루트를 갖는다.
애그리게이트의 경계는 말 그대로 애그리게이트으ㅔ 포함되는 대상을 결정하는 경계다.
루트는 애그리게이트에 포함되는 특정한 객체다.

p253
데메테르의 법칙(디미터의 법칙)
외부에서 내부 객체를 직접 다루는 대신, 내부 객체를 삼싸는 객체에 용청하는 형태를 취한다.
=> https://mangkyu.tistory.com/147

p259
노티피케이션 객체를 이용하는 방법이 있다.
객체의 내부 데이ㅓ는 비공개로 그대로 두면서 외부에 데이터를 전달할 수 있다.
public void Notifiy(IUserNotification note) {
    note.Id(id);
    note.Name(name))
}
Public class UserDataModelBuilder: IUserNotification {
    //전달된 데이터로 UserDataModel를 만든다.
}

p266
리포지토리는 에그리게이트마다 ㅏ나씩 만든다.

p267
에그리게이트의 경계를 넘지 않는다는 불문율을 맏느는 것보다 더 나은 방법은 없을까?
그 방법은 바로 인스턴스를 갖지 않고 식별자를 갖는 방법이다.

p279
명세라는 객체를 이용하면 엔티티나 값 객체가 리포지토리를 다루지 않으면서도 이 문제를 해결할 수 있다.
명세는 객체가 조건을 만족하는지 확인하는 역할만을 수행한다.

p294
CQS(Commad-query seperation), CQRS(Command-query responsibility segregation)
객체의 메ㅓ드를 성격에 따라 커맨드와 쿼리로 크게 나눠 다르게 다루는 것이 요점인데, 프레젠테이션 계츠으이 성능적인 요구를 만족하면서도 시스템의 통제를 늦추지 않는 효과를 거둘 수 있다.

p302
아키텍쳐
- 계층형 아키텍쳐
- 헥사고날 아키텍쳐
- 클린 아키텍쳐

p315
포트앤어뎁터
포트는 애플리케이션에서 입출력이 들고나는 다날부를 의미하며
어댑터는 어떤 인터페이스를 다른 인터페이스로 변환하는 클래스를 의미한다.