• 당연하지 !

• 준수해야되는 규칙? 룰
• 왜 굳이 이렇게까지 해야되지?
• 아키텍처를 실현할수록 계속 불편해짐
• 근대 아키텍처를 계속사용하고? 개선하는이유?
• 꼭 써야되는 이유가 있따.
• 그 이유를 찾고 구성원 모두가 공감해야됨. 아니면 장애물 덩어리

• 이런식의 아키텍쳐의 목표
• 결과적으로 의존성 역전이나 다른 경계를 긋는 여러 방법을 이용해
• 시스템에 경계를 넣고 관심사 분리하고 동시작업이 가능하게 되니 인적자원 발전
• 좋은말이 정말 많이나온다
• 인상적 ㅠㅠ

• 이전 1편강의 내용 복습이다

• 대략 이런식으로 정리

• 컨트롤러의 역할은무엇이냐?

• 이미 흔히 알고 있는 것들

• 근대 나머지는 스프링이 해주는 거라 3개가 중요하자

• 레포지토리가 어떤 역할인가?

• 애플리케이션을 어떻게 이해할까

• 허나 앞에 없이 무슨프로그램인지 알수 없다

• 전문성이 깊어질라면?

• 도메인과 유스케이스를 먼저집중하는게 먼저다

• 도메인 엔티티랑 영속성 객체를 분리할 필요가 있나?
• 책에서는 구분하지 않는 경우도 많다.
• 구분하지말자 -> ORM 왜씀? 구분하자 -> 디비랑 강결합해잔아

• 구분해야 한다와 하지말아야 된다는 양측에 주장

• 최종적으로 강의자는 3개로 분리를한다.
• 보통 현업에선 엔티티+도메인모델을 같이써 응답객체로 반환해주는 방식을씀

• 최종적으로 이런 모델 구조가 나온다.

• 원칙과 편의성 둘 사이 줄다리기가 필요함
• 어디까지 적용해야될까 원칙은 원칙
• 원칙을 모두 지키는게 좋지만 정말로 필요한가? 다른 문제
• 모델을 어디까지 세분화할것인가 정답이 없다.

핵사고날에 대한 사견

• 직접사용
• 구현체 사용 (쿼리dsl?)
• 제어의역전 방식같은데

• 잘못된 방식은 아니다
• 이미 인터페이스이기 때문에
• 테스트 할때 이렇게도 테스트 페이크 레파지토리 만들수있지만.
• 불필요한 메서드를 구현해야되는 문제점이 있다
• 그리고 디비랑 강결합.

• 이런 방식도 ?
• 페이크만들때 필요한 메서드만 구현해도 됨
• 하지만 구현체가 영속성 객체를 반환해야되서
• 이것도 강결합
• 3번째방식은 이때까지 계속 해왓던거니까 생략

• 스프링이 다해주는대?
• 굳이 유스케이스를 제대로 호출하느지 확인하기 위해 추상화한다?
• 불필요

• 추상화가 되있거나 안되있거나
• 극단적으로 2개 로 나뉜다.

• 이상적인 상황이 되기 위해선
• 얼마나 안정적인 것에 따라 다르기 때문에 해답이 없다.

• 명언이 참 와닿는다.