챕터1

• 왜 우리는 계층형 아키텍처로 개발하는가?
  • 1. 자유도가 높다 2. 오버엔지니어링 2. 오랜 시간동안 책이나 웹 등을 통해 잘 알려져있고 스프링이 계층으로 나눠뒀다.
• DB ID가 필요한 이유
• 계층형 아키텍처에서의 빌드 제약
  • https://d2.naver.com/helloworld/9222129
  • https://sonarcloud.io/

챕터 2

• 헥사고날이 유지보수가 좋아지는 이유
  • 도메인이 의존하는 곳이 없으니 도메인 로직에 집중할 수 있는 테스터빌리티
• 순환 의존성에 관한 얘기가 나옵니다. 각각의 의존 관계들을 도식화하지 않으면 분명 놓치거나 인지하지 못하는 의존성이 생길 것 같은데, 이럴때는 어떻게 하면 좋을까요?
  • package-private
  • 모델들을 나누고, 모델들을 공유하는 패키지가 필요하다
  • archunit
• 넓은 서비스를 잘게 나누는 것이 , *Service 네이밍이 과연 올바른가?
  • 유스케이스를 나누는 것에 대해 팀원 모두가 공감해야 함

챕터 3

• 포트의 필요성
  • 구현체를 바로 어댑터에 주입시켜도 동작은 함
  • but, 인터페이스로 뺀 가장 큰 이유는 기능 단위로 나누려고 하다보니 그런듯?
  • 테스트 코드 역시 인터페이스를 기반으로 하므로 작성이 쉬워짐
    • 구현체는 mocking을 해야하지만, 인터페이스는 원하는 결과를 내어주게 직접 만들 수 있다.
    • 코딩하는 비용이 커진다. 하지만 외부서비스(망, db) 의존성이 있을 때 인터페이스로 테스트를 용이하게 하자라는 명분
  • 인터페이스를 의존하는게 컨트롤러의 변경 가능성이 줄어들게 됨(인터페이스 분리의 원칙)
  • 퍼블릭 인터페이스를 통해 바로 입력의 제약을 확인할 수 있음
  • 여러 어댑터에서 최소 퍼블릭 인터페이스를 전달하기 위해 필요할수도 있을듯
  • 포트: 사용 설명서, 어댑터: 사용하는 클라이언트
    • 코드가 작으면 괜찮지만 코드가 커질수록 필요성을 느낄 것 같음
    • 포트와 어댑터라는 이름에서 볼 수 있듯이 포트가 중요한 역할인 것 같다. 어댑터가 어떻게 사용을 해야하는지 사용 설명서와 코어로의 진입점을 보여준다.
• 1개의 도메인이 아니고 전체적인 도메인의 헥사고날 아키텍처는 어떻게 그려질 것인가?