느낀점

한 애그리거트에 대해 조회, 생성, 수정 까지 일일이 서비스 나누기 + 중복되는 기능은 헬퍼 클래스를 제공하여 재사용 하는것은 너무 많은 클래스를 제공하는게 아닌가 생각된다.
- 한 응용 서비스로 crud 를 모아서 응집도를 높이고, 공유할 로직이 있다면 private 으로 해당 서비스내 고립시키는게 더 좋지 않을까 싶지만 개인적 선호도 + 팀 컨벤션에 맞게 가면 될 것이라 생각한다.
검증 파트
- 입력된 값에 대한 검증을 한건 한건마다 하는 것만 생각했었음 → 오류들을 모아서 담아 한꺼번에 보낼 수도 있다!
- 필자가 말하고 있는 응용 서비스에서 필수 값 검증과 논리적 검증 파트를 모두하는 이점이 공감이 안된다.
조회 상황 시 컨트롤러에서 바로 DAO 를 쓰는건 사고의 폭이 좁아서 그런지 아직 따라가기 어렵다…
- 계층을 없애는 이점? 당장의 개발 편의성
- 계층이 존재했을 때 이점?
  - 중간 응용계층에 CRUD 위임하여 응집성 증가
  - 조회 시 여러 쿼리가 필요하다면 리드 트랜잭션 사용 가능
  - 조회 모델에 로직이 필요한 경우 응용 계층에서 처리 가능

6.1 표현 영역과 응용 영역

도메인과 사용자와 연결할 표현, 응용 영역 필요
- 표현 영역: 사용자 요청 해석, 응용 영역으로 연결, 응답 제공
- 응용 영역: 사용자 원하는 기능 제공, 도메인과 연결

도메인 객체간 흐름제어 제공 → 단순한 형태를 띄게 됨
- 응용 서비스가 복잡하다면 도메인 로직 일부를 구현하고 있을 가능성 있음
  - 서비스에 도메인 로직이 분산되어 있다면
    - 코드 응집성 저하
    - 코드 중복 (여러 응용 서비스에서 동일한 도메인 로직 구현 가능성)
트랙잭션 처리 제공
접근 제어 (뒤에서 다룸)
이벤트 처리 (뒤에서 다룸)