클린 아키텍처-너무 많은 유스 케이스 클래스

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 개의 사용 사례를 만들어야합니까?

누군가 이미 그것을 성공적으로 사용하여 설명을 해 주셔서 감사합니다.

고마워, 잭

— 재키 데글 노노 센티
소스

예제 코드와 함께 이러한 사용 사례를 자세히 설명하는 페이지에 대한 링크를 게시 할 수 있습니까?

— Robert Harvey

나는 많이 봤지만 주로 :이 응용 프로그램 샘플 및 관련 기사 : github.com/jshvarts/OfflineSampleApp ; 이 기사 : proandroiddev.com/… ; proandroiddev.com/… ; 이 대화 : youtube.com/watch?v=TvsOsgd0--c&feature=youtu.be ; 그리고 이것도 기사 : adityaladwa.wordpress.com/2016/10/25/...

— 재키 Degl'Innocenti

인용 한 샘플 앱이나 기사는 Clean Architecture와 관련이없는 것으로 보입니다. 그러나 반응 형 프로그래밍

— Robert Harvey

샘플 앱은 반드시 Clean Architecture 패러다임으로 만들어졌습니다 .. 다른 기사들 대부분 .. @RobertHarvey를보고 싶은 것은 무엇입니까?

— Jackie Degl'Innocenti

아래 답변을 읽고 답장하십시오.

— Robert Harvey

답변:

실제로 24 개의 사용 사례를 만들어야합니까?

당신이 쓰는 모든 것이 CRUD 인 경우에만 .

아래 다이어그램을 참조하십시오.

귀하의 주장은 6 개의 다른 엔터티와 각 엔터티에 대해 4 가지 방법 (만들기, 읽기, 업데이트 및 삭제)을 갖게된다는 것입니다. 그러나 다이어그램 중간 (엔티티 레이어)의 노란색 원에만 해당됩니다. 사용 사례 계층에서 엔터티 계층으로 CRUD 호출을 전달하는 24 개의 메소드를 작성하는 것은 의미가 없습니다.

유스 케이스는 "고객 레코드 추가"가 아닙니다. 사용 사례는 "고객에게 상품 판매" (고객, 제품 및 재고 실체 포함) 또는 "인보이스 인쇄" (인보이스 헤더 및 송장 라인 항목 외에 동일한 엔터티 포함) 라인에 더 있습니다. ).

유스 케이스를 작성할 때 CRUD 메소드가 아닌 비즈니스 트랜잭션 에 대해 생각해야합니다 .

추가 읽기
집계-단일 단위로 취급 될 수있는 도메인 객체 클러스터

— 로버트 하비
소스

패턴, 실습 및 아키텍처에 대해 생각하는 데 너무 많은 시간을 소비하고 있으며 기본 소프트웨어 디자인에 대해서는 생각하는 데 시간이 충분하지 않습니다. 내 답변에서 설명한 것처럼 비즈니스 관행을 구현하는 방법 만 있으면됩니다.

— Robert Harvey

아키텍처를 선택하는 것은 문제가 아닙니다. 내 개인적인 의견 : 베어 CRUD 작업은 엔티티 계층과 직접 대화해야합니다. 물론 이것은 아마도 Clean Architecture를 위반했을 것입니다.

— Robert Harvey

당신은 요점을 놓쳤습니다. 아키텍처는 코드를 구성하는 수단 일뿐입니다. 아키텍처와 씨름하지 않고 코드 를 작성 하여 문제를 해결합니다 .

— Robert Harvey

Robert, 내가 코드를 작성하지 않는다고 가정하는 것은 그리 좋지 않습니다. 내 대답의 주제는 아키텍처에 관한 것이며 우리는 그렇게하지 않습니다. 진심으로 나는 당신의 마지막 의견이 실제로 오도하고 귀머거리를 발견합니다. 문제는 코드를 작성하지 않고 Clean Arch.의 UseCase에 관한 것입니다. 의사 소통을하려는 경우 의견의 요점이 없기 때문에 더 잘 설명해주십시오. IMHO는 소프트웨어를 개발하는 동안 아키텍처 고려 사항을 피할 수 없으며 적어도 훌륭한 개발자는 코드를 많이 쓰는 것이 아닙니다. 또한 나는 내 의견에 정말 구체적인 질문을했습니다. 응답 할 수 있습니까? 감사합니다

— Jackie Degl'Innocenti

당신이 제기 한 문제에 대한 해결책 (앱 오프라인 우선)은 실제로 Clean Architecture와 관련이 없습니다. Clean Architecture 다이어그램에서 해당 문제에 대한 솔루션을 찾을 수 없습니다.

— Robert Harvey

모든 CRUD-Operation이 하나의 UseCase로 번역 된 경우 귀하가 옳습니다. 그러나 UseCase는 여러 CRUD 작업으로 구성 될 수도 있습니다.

UseCase는 서로 다른 데이터 소스에서 정보를 수집하고 데이터 싱크와의 통신을 준비하는 분리 된 모델입니다. 여러 CRUD 작업이 관련 될 수 있습니다.

따라서 고객에 대한 송장을 생성하고 고객이 시스템 내에 없기 때문에 고객 자체를 생성하는 UseCase를 생각해보십시오. 하나의 트랜잭션에서 최소한 두 개의 작성 조작을 발생시키는 하나의 UseCase가 있습니다.

— oopexpert
소스

그렇다면 많은 엔터티가있는 CRUD의 예에 어떤 패턴을 권장합니까?

— Jackie Degl'Innocenti

이것에 대한 나의 개인적인 견해는 : SRP (단일 책임 원칙)를 위반하지 않는 한 많은 수업을 갖는 데 아무런 문제가 없습니다. 그러나 대부분의 경우 유스 케이스를 "엔티티 작성", "엔터티 업데이트", "엔티티 삭제"및 "엔터티 업데이트"를 간단한 "X 유형의 엔티티 관리"로 재정의합니다. 하나의 엔티티를 관리하기 위해 단일 UI를 제공하는 경우가 종종 있습니다. 그러나 이것이 바로 UseCase가 정의해야 할 내용입니다. 비즈니스를 위해 많은 양의 작업을 처리하는 방법.

— oopexpert

따라서 다양한 작업을 관리하는 유스 케이스를 갖는 것이 단일 플로우가 둘 이상의 책임을 처리하지 않으면 서 동일한 UseCase에서 더 다양한 메소드 (및 플로우)를 "집합"하는 것처럼 SRP를 위반하지 않는 것 같습니다. .. 그러나 이런 식으로 우리는 단지 UseCase 대신 컨트롤러를 생성하는 것이 아닙니까? .. idea .. 아마도 유스 케이스는 단순히 계층으로 보여야하며, 해당 계층은 SRP를 존중해야하지만 많은 방법을 구현할 수도 있습니다. 나는 이것에 대한 소스 나 기사를 갖고 싶다

— Jackie Degl'Innocenti

유스 케이스는 컨트롤러입니다. 유일한 차이점은 유스 케이스는 비즈니스 관점에서 비롯된 것이며 컨트롤러는 기술적 인 관점입니다. 유스 케이스의 초점은 비즈니스 가치를 창출하는 것입니다. 따라서 유스 케이스는 비즈니스 가치 중심 컨트롤러 구현입니다.

— oopexpert

HTTP 컨트롤러는 I / O 관리 방법이며 콘솔 명령, 이벤트 반응 등도있을 수 있습니다. 이 모든 I / O 채널은 동일한 사용 사례를 호출합니다. 유스 케이스는 비즈니스 로직을위한 컨트롤러이며, 호출 된 I / O 채널에 대해서는 알지 못하지만 도메인 엔티티를 조정하여 작업을 수행하는 방법을 알고 있습니다.

— Dmitriy Lezhnev

유스 케이스에 대한 정의가 잘못되었습니다. 유스 케이스는 비즈니스 규칙을 구현하는 클래스입니다. CRUD 조작 일 필요는 없습니다. 복잡한 다중 단계 조작 일 수도 있습니다.

— 벅스 탭
소스

문장이 실제로 광범위한 크루 드와 유사한 작업을 구현해야 할 때 해결책을 의미하지는 않습니다. 심지어 유스 케이스가 복잡한 작업에 액세스 할 수있는 패턴을 관찰해야한다는 사실과 관련이있을 수도 있습니다. 심지어 다단계.

— Jackie Degl'Innocenti