Clean Architecture 로 이동하여 Android 레벨을 MVC에서 MVP 로 높이고 Dagger 2가 포함 된 DI, RxJava 2에 대한 반응성 및 Java 8을 소개합니다.
에서 MVP 깨끗한 아키텍처 이 엔티티 사이의 계층 (데이터 저장소에) 및 발표자 에 액세스해야합니다. 이 계층은 “사용 사례” 입니다. 유스 케이스는 ONE 엔티티에서 ONE 조작을 구현하는 이상적인 인터페이스입니다.
또한 Clear Architecture는 ” 비명을 지르고있다 ” 는 것을 알고 있습니다. 프로젝트의 관점에서 볼 때 프로젝트의 수가 많은 클래스처럼 읽기 쉽습니다.
이제 내 프로젝트에는 6 개의 다른 엔티티 가 있으며 물론 각 엔티티 저장소에는 액세스 할 수 있는 적어도 4 개의 메소드 (일반적으로 get, add, delete, update)가 있습니다. 따라서 6 * 4 = 24 .
Clean Architecture의 지금까지 내가 이해 한 것이라면 24 개의 UseCase가 있습니다.
이것은 MVC에서 단지 6 개의 컨트롤러와 비교할 때 많은 클래스입니다 .
실제로 24 개의 사용 사례를 만들어야합니까?
누군가 이미 그것을 성공적으로 사용하여 설명을 해 주셔서 감사합니다.
고마워, 잭
답변
실제로 24 개의 사용 사례를 만들어야합니까?
당신이 쓰는 모든 것이 CRUD 인 경우에만 .
아래 다이어그램을 참조하십시오.
귀하의 주장은 6 개의 다른 엔터티와 각 엔터티에 대해 4 가지 방법 (만들기, 읽기, 업데이트 및 삭제)을 갖게된다는 것입니다. 그러나 다이어그램 중간 (엔티티 레이어)의 노란색 원에만 해당됩니다. 사용 사례 계층에서 엔터티 계층으로 CRUD 호출을 전달하는 24 개의 메소드를 작성하는 것은 의미가 없습니다.
유스 케이스는 “고객 레코드 추가”가 아닙니다. 사용 사례는 “고객에게 상품 판매” (고객, 제품 및 재고 실체 포함) 또는 “인보이스 인쇄” (인보이스 헤더 및 송장 라인 항목 외에 동일한 엔터티 포함) 라인에 더 있습니다. ).
유스 케이스를 작성할 때 CRUD 메소드가 아닌 비즈니스 트랜잭션 에 대해 생각해야합니다 .
추가 읽기
집계-단일 단위로 취급 될 수있는 도메인 객체 클러스터
답변
모든 CRUD-Operation이 하나의 UseCase로 번역 된 경우 귀하가 옳습니다. 그러나 UseCase는 여러 CRUD 작업으로 구성 될 수도 있습니다.
UseCase는 서로 다른 데이터 소스에서 정보를 수집하고 데이터 싱크와의 통신을 준비하는 분리 된 모델입니다. 여러 CRUD 작업이 관련 될 수 있습니다.
따라서 고객에 대한 송장을 생성하고 고객이 시스템 내에 없기 때문에 고객 자체를 생성하는 UseCase를 생각해보십시오. 하나의 트랜잭션에서 최소한 두 개의 작성 조작을 발생시키는 하나의 UseCase가 있습니다.
답변
유스 케이스에 대한 정의가 잘못되었습니다. 유스 케이스는 비즈니스 규칙을 구현하는 클래스입니다. CRUD 조작 일 필요는 없습니다. 복잡한 다중 단계 조작 일 수도 있습니다.