어그리게이트 루트와 유사한 경우
RestAPI 의 endpoint하나를 통해서 여러가지를 한꺼번에 진행할 수 있는 것들
질문 + 세부 옵션이 있는 경우
퍼블릭하게 열어줬던 부분은 질문만 있던 부분
대부분의 프로젝트에서 모든 자원에 대해서 crud를 열어두는 것보다, 한꺼번에 관리하는 경우가 편한 상황이 많음
세부 사항의 상태를 완벽하게 특정할 수 없는 경우가 생각보다 많아짐
주변 환경에 영향을 받는 경우 루트를 두는 방식으로 관리한다면 그것도 좋아보임
DIP 모킹하는 사례
우테코 코드 랜덤값 모킹하는 것
사실 대부분의 경우 Mockito를 통해서 모킹이 가능함.
인터페이스가 있으면 생기는 장점이 애매해보임
상위 레이어에 인터페이스를 두는 이유는 뭘까?
의존성의 방향이 물론 중요하다지만, 그렇게 중요한가
=> 멀티 모듈시 패키지 의존성이 양방향이면 import가 안 되도록 설정이 되는 방식을 통해서 1차적으로 확인 가능
도메인 모델은 도메인 모델로 내버려 둬야 하고, RDS의 엔티티는 RDS의 엔티티로 나눠야 한다
조금 더 고민했을 때, 애그리거트에서 모든 데이터를 변경할 메서드를 다 열어두고, 내부 OrderLine 같은 모든 구현을 숨기는 것도 좋아보임
그리고 패키지 프라이빗으로 묶으면, 안전성을 높일 수 있을 것
근데 이때 interface로
void save(Order order);같은 경우에 이걸 어떻게 저장하느냐? 불러오느냐는 모르겠음
바깥쪽에서 그 엔티티를 그대로 저장할 수 있다?
이것도 말이 안되고
getter 메서드를 다 쓸만하게 달아줘야 된다? 이것도 애매했음
지연 로딩을 제대로 쓰기 위해서 @Transaction은 응용 계층에 둔다
애플리케이션에서 Transactional같은 의존성을 다 끊으려다보면 복잡해지는 경우가 많기에, 적당한 타협이 필요함
루트 단위에서 적절한 처리가 필요하다는 내용이 있음
그 내부 구현은 어떻게 되든 전혀 상관 없음
응용 계층에서 여러 트랜잭션을 만드는 쪽이 더 깔끔할 경우가 많음. 한 애그리거트는 하나만 다루는 방향으로 작성
이때 팀 표준, 기술 제약, UI 구현의 편리일 때 다른 트랜잭션을 호출하도록 허용한다
이때 애그리거트단위로 조회시 장점이 db를 바꾸기가 쉽다
최적화 할 부분이 명확해지기에 다른 외부 구현을 어떻게 되든 상관없이 확실하게 보장한다는 장점이 있다
이때 로직이 응용 서비스 레이어로 가게 되는 문제가 있음
이를 팩토리를 통해서 래핑하는 것이 가능함
public class Store{
public Product createProduct(ProductId newProductId, ProductInfo pi){
if(isBlocked()) throw
return ProductFactory.create(new ProductId,getId(),pi)
}
}이때 한 곳에 뭉친다고 되어는 있지만, 사실 바로 ProductFactory 를 호출하는 문제가 있을 수 있긴 함
이걸 안 쓴다면 모듈을 단위로 private 해줘야 되기도 하고, 약간 이런 생각들이 있긴 함
질문
Order라고 하는 커다란 entity가 있을 때
이를 저장하고, 불러오려면 어떻게 해야 하나?
다시 고민해볼만한 내용
하나의 패키지 private으로 묶은 내부 상황에서도 과연 get, set을 줄여야 하나?
아닐것 같음
또한 고민해볼 만한 부분
https://techblog.woowahan.com/2637/
배민 멀티모듈 설계에서 domain부분이
repository, entity, 도메인서비스
이렇게 3가지가 모이는데, domain에서 entity 설정관련 코드들이 존재할 경우 이 코드는 infrastructure에 의존한다고 볼 수도 있는데, 이는 어떻게 생각하게 되는지?
양방향 의존성을 없앤다는 생각을 할 경우 멀티모듈을 활용하는 부분에 대해서 장점이 크게 나올 수 있을 것 같음
module 안에 subproject로 멀티 모듈을 가져다 놓을 경우에
의존성이 끊어짐
루트에 대해서만 dependency를 놓을 경우에, 안정성을 극대화 시킬 수 있을 것으로 보임
root
|-- my-parent
| |-- build.gradle
| |-- settings.gradle
| |-- module-a
| | |-- build.gradle
| | |-- submodule-aa
| | | |-- build.gradle
| |-- module-b
| | |-- build.gradle
예시
