모든 테스트가 디비가 필요하다 (H2)

• 모두 중형 테스트가 되버린다
• ES같은 디비는 어떻게 실습할까?

• 가장 먼저 배우는 구조
• 디비 위주의 설계를 하게 된다.
• 제일 아랫단인 영속성 객체부터 만들 생각을한다.

• 주문 시스템
• 바로이런식으로 이런거 부터 생각을 한다.

• 원래는 이런걸 파악을 먼저다
• 그리고 도메인과 도메인의 관계를 파악하는게 먼저다

• 그리고 동시작업 문제.
• 특정 기능 개발은 한명만 작업해야됨
• 도메인이 죽는다.
• 무슨시스템? 도메인이 어디있찌? 파악 가능? 못함
• 객체에 대한 진지한 고민을 안해서
• 서비스가 모든 일을 다처리하는 구조

• 비즈니스 문제를 해결하는 객체 도메인

• 도메인에게 일을 시키자
• 도메인객체와 영속성 객체를 분리시켜야된다.

• 도메인이 고립되있어
• 테스트 어빌리티가 높고 문제가 되지않는다

• 의존 계층이 없다, 목킹도 필요 없다.
• 근대 솔직히 테스트 해야되나? JPA 측 문제인대

• 전에 강의했떤말을 반복한다.

• 강의에서 설명을 이렇게하는대
• 서비스는 굳이 그대로 사용하는게 더나은거같다

어떻게 변경할 것인가?

• 컨트롤러 역할은 단순함 요청받고 응답내리기
• 스프링이 알아서 잘테스트해서 패스
• 레포지토리도 마찬가지
• 강의자의 개인 의견인대 음,...
• ddD 의견에따라 도메인이 애플리케이션이 중심이니
• 서비스랑 도메인만 강의에서 집중하다

• 테스트 커버리지가 낮게나온다?
• 도메인에 경쟁력이없다 빈약하다는 얘기

• 무언가를 관통하는말
• 요즘 ddd로 개발하려고 클래스나누고 제어의 역전을 이용해서
• 심플하게하려는대
• 이 말을 듣고 뭔가 깨달았다 정말 좋은말같다.

• 레이어드 아키텍처의 단점 패키지구조
• 도메인에 집중해야되는대 도메인이 집중이 안됌

• MSA를 구현하기 좀더 수월해 진다.

• 패키지 의존성도 한번씩 확인해야됨
• 순환참조가 생길수 있음
• 참조관계가 순환하는 그림을 보고 순환참조라함
• 소프트공학에서 피해야 하는 해악

• 서비스 로직을 도메인 엔티티도 몰아 넣겠따.