윤니버스

08. 경계간 매핑하기 매핑하지 않기 전략 서로 다른 레이어에서 같은 모델을 사용하여 개발 공통 모델에서 각 레이어별 다른 요구사항을 개발해야됨 모든 계층의 구조가 같을 경우 해당 전략을 추천 양방향 매핑하기 전략 계층 별로 다른 모델을 사용하여 개발 다른 계층의 요구사항을 개발하지 않아도 됨 너무 많은 보일러플레이트 코드가 생김 도메인 모델이 통신하는데 사용됨 (다른 레이어의 요구에 따른 변경에 취약해짐) 완전 매핑 전략 각 연산마다 별도의 모델을 사용 더 많은 코드가 필요함 구현하고 유지보수하기 쉬움 단방향 매핑하기 전략 공통 인터페이스를 개발한 후, 각 레이어에서 구현체를 구현 계층간의 모델이 비슷할 때 유용 언제 어떤 매핑 전략을 사용할 것인가? 그때그때 다르다. 한 전략을 전체 코드에 적용할 필..

만들면서 배우는 클린아키텍처를 읽고(1/4) (tistory.com) 만들면서 배우는 클린아키텍처를 읽고 (2/4) (tistory.com) 4장 유스케이스 구현하기 도메인 모델 구현하기 Account 도메인의 컨셉 ActivityWindow에 Activity 목록을 가지고있으며, Activity 목록을 계산하여 balance를 계산 최적화를 위해 특정 기간내의 Activity만 불러오며, 그 이전의 값은 baselineBalance로 미리 계산 유스케이스 둘러보기 유스케이스는 도메인 로직만 있어야함. 즉, 입력 유효성 검증은 이미 되었다고 가정 그러나, 비즈니스 규칙의 검증은 해야됨 입력 유효성 검증 유스케이스의 입력 모델을 이용해서 입력 유효성 검증을 진행 Bean Validation API를 이용하..

만들면서 배우는 클린아키텍처를 읽고(1/4) (tistory.com) 2장. 의존성 역전하기 2.1. 단일책임원칙 SRP(Single Responsibility Principle) 컴포넌트를 변경하는 이유는 오직 하나뿐이어야한다. 장점 응집력 향상 (Enhanced Cohesion) 결합도 감소 (Reduced Coupling) 유지보수성 향상 테스트 용이 하지만, 실세계의 소프트웨어에서 컴포넌트 의존성은 매우 복잡하기때문에, 변경하는 이유는 쉽게 전파됨 시간이 흐를수록 변경하는 이유들이 많아 지며, 많이 쌓인 후 컴포넌트를 변경하는건 다른 컴포넌트의 실패로 이루어짐 결론 복잡한 아키텍처에서는 컴포넌트 간 의존성 때문에 변경할 이유가 쉽게 전이되기때문에, 클린 아키텍처를 지향하는게 좋다(?) 2.2. 부..