챕터 4

• 생성자의 힘 - aop의 validation(@Validated + @Valid)를 사용하는 경우
  • 클린 아키텍처의 관점에서 애너테이션보다 생성자를 쓰는 편이 더 낫다.
  • 각자 좋다고 생각하는 방법을 쓰자
• 풍부한 도메인 모델 vs 빈약한 도메인 모델
  • 빈약한 도메인 모델을 사용하는 경우가 우세
  • 빈약한 모델을 사용할 때에는 서비스가 200줄이지만, 풍부한 도메인 모델을 사용하면 1000줄이 될 수도 있다.
  • 요구사항이 어떻게 오느냐, 시간이 얼마나 있느냐가 일할 때는 중요하다. 급하면 일단 한 곳에 다 때려넣고, 생각하고 책임을 나누고 경계를 나누는 것은 개발자가 더 일할 것이냐 개발자의 몫이 된다.
  • 풍부한 도메인 모델을 사용하면 다른 모델의 상태를 알아야할 때가 있는데, 비즈니스 루틴이 엮여서 테스트하기 더 어려워졌다. 비즈니스 로직을 서비스로 다 올렸다.
    • Order의 상태를 변경할 때 Delivery가 들어가야할 때

챕터 5

• 각 계층에서의 유효성 검증의 차이
  • 형태적인것: 웹 어댑터의 책임
    • 이메일의 regex, 숫자의 크기, 문자의 길이
  • 유스케이스의 유효성 검증
    • 아이디가 중복됐는가?(서비스에 내려서 db의 확인이 필요한 경우)

챕터 6

• 장점
  • 영속성에서 벗어나 테스트하기 용이해진다.
• 단점
  • LazyLoading을 못 쓴다.
  • 주문상품을 가져올 때 order.getOrderItems() → order 도메인 만들 때 다 땡겨서 사용해야한다.
  • 일대다, 다대일에서 전체 다 가져와서 POJO 클래스로 만들어주어야 한다.