chumong

Root project - app moudle - domain module 1) ./gradlew init on root project 2) make app, domain module 3) add include sub module in root's settings.gradle rootProject . name = 'root-modules' include 'app' , 'domain' it means root project manage app, domain module as sub module 4) root's build.gralde subprojects - manage all inculded moudle in setting.gralde  5) add build.gralde to each module 6) app module add domail module as sub module dependencies { compile project( ':domain' ) } 7) add dependencies to each module 8) add each moudle when project build make each moudle in jar file when gradle build - app module bootJar { archiveFileName = 'app.jar' enabled = true } - domain module bootJar { enabled = false } jar { enabled = true } dependencies  - compile - implementation - api - runtime - testComplie - References https://jojoldu.tistory.com/123

설계는   변경과   관련이   있다 . 의존성  :  클래스   의존성 ,  패키지   의존성 ( 패키지에   포함된   클래스   사이의   의존성 ) A -> B : A 가  B 에   의존한다 . B 가   변경되면  A 에   영향이   있다 . 가이드 -  양방향   의존성을   피하라 -  다중성이   적은   방향을   피하라  : 1:N  검색 ,  삭제   등   비용이   커진다 .  -  패키지   사이의   의존성   사이클을   제거하라  *** ( 싸이클   제거 ) 리파지토리 구현 클래스를 인프라스트럭쳐 영역에 위치시켜서 인프라스트럭쳐에 대한 의존을 낮춰야한다 . 인프라스트럭쳐는 표현 , 응용 , 도메인 영역을 지원한다 . 도메인 객체의 영속성 처리 , 트랙잭션 , Rest Client 등 다른 영역에서 필요하는 하는 구현 기술 , 보조기능을 지원한다 . 객체와 디비는 다르다 . 객체는 행동 , 디비는 중복 제거를 한다 . 이걸 해결하기 위해 JPA 를 사용하지만 Lazy loading 이 문제가 된다 . 어디까지 읽어야 할까 ? 그러다 보면 조회하고 , 비즈니스 처리하고 , 널 체크하고 이런 식으로 로직이 만들어진다 . 그리고 성능문제가 발생한다 . 객체 그룹 조회 경계 모호해지며 트랜잭션 경계는 어디까지인가 ? 객체 참조가 꼭 필요할까 ?  객체참조는 결합도가 가장 높은 의존성이다 ...