Kiến trúc sạch - Quá nhiều lớp trường hợp sử dụng

Tôi sẽ tham gia vào Kiến trúc sạch và nâng cấp Android của tôi từ MVC lên MVP , giới thiệu DI với Dagger 2, Reactivity với RxJava 2 và tất nhiên là Java 8.

Trong kiến trúc sạch MVP có một lớp giữa các thực thể (trong kho dữ liệu) và những người thuyết trình nên truy cập chúng. Lớp này là "Ca sử dụng" . Một trường hợp sử dụng lý tưởng là một giao diện, thực hiện MỘT hoạt động trên MỘT thực thể.

Tôi cũng biết rằng Clear Architecture " đang la hét ", theo nghĩa các dự án của nó thực sự rất dễ đọc vì số lượng lớn các lớp học trong đó.

Bây giờ, trong dự án của tôi, tôi có một cái gì đó giống như 6 thực thể khác nhau và tất nhiên, mỗi kho lưu trữ thực thể có ít nhất 4 phương thức (thường là lấy, thêm, xóa, cập nhật) để truy cập chúng .. vì vậy, 6 * 4 = 24 .

Nếu những gì tôi hiểu cho đến bây giờ về Kiến trúc sạch, tôi sẽ có 24 UseCase.

Đây là rất nhiều lớp nếu so với chỉ 6 bộ điều khiển trong MVC ..

Tôi có thực sự phải thực hiện 24 trường hợp sử dụng?

Tôi sẽ thực sự đánh giá cao sự làm rõ bởi một người đã sử dụng nó thành công.

Cảm ơn, Jack

— Jackie Degl'Innocenti
nguồn

Bạn có thể đăng một liên kết đến một trang mô tả các Ca sử dụng này một cách chi tiết, với mã ví dụ không?

— Robert Harvey

Tôi đã googled rất nhiều, nhưng chủ yếu là: mẫu ứng dụng này và bài viết liên quan: github.com/jshvarts/ OfferlineSampleApp ; bài viết này: proandroiddev.com/ . proandroiddev.com/... ; Bài nói chuyện này: youtube.com/watch?v=TvsOsgd0--c&feature=youtu.be ; Và bài viết này cũng vậy: adityaladwa.wordpress.com/2016/10/25/ trên

— Jackie Degl'Innocenti

Không có ứng dụng hoặc bài viết mẫu nào bạn trích dẫn dường như có liên quan nhiều đến Kiến trúc sạch. Họ làm, tuy nhiên, nói rất nhiều về lập trình phản ứng.

— Robert Harvey

Ứng dụng mẫu chắc chắn được thực hiện với mô hình Kiến trúc sạch .. Các bài viết khác chủ yếu .. Bạn muốn xem gì @RobertHarvey?

— Jackie Degl'Innocenti

Đọc câu trả lời của tôi dưới đây và trả lời.

— Robert Harvey

Câu trả lời:

Tôi có thực sự phải thực hiện 24 trường hợp sử dụng?

Chỉ khi mọi thứ bạn viết là CRUD .

Tham khảo sơ đồ bên dưới:

Khẳng định của bạn là bạn sẽ có sáu thực thể khác nhau và 4 phương thức (Tạo, Đọc, Cập nhật và Xóa) cho mỗi thực thể. Nhưng điều đó chỉ đúng trong vòng tròn màu vàng ở giữa sơ đồ (lớp Thực thể). Việc tạo ra 24 phương thức trong lớp Các trường hợp sử dụng chỉ đơn thuần chuyển qua các lệnh gọi CRUD đến lớp Thực thể là vô nghĩa.

Ca sử dụng không phải là "Thêm hồ sơ khách hàng." Ca sử dụng nằm dọc theo dòng "Bán một mặt hàng cho khách hàng" (liên quan đến các thực thể Khách hàng, Sản phẩm và Hàng tồn kho) hoặc "In hóa đơn" (liên quan đến các thực thể tương tự, ngoài các Mục hàng hóa đơn và Tiêu đề hóa đơn ).

Khi bạn tạo Ca sử dụng, bạn nên suy nghĩ về các giao dịch kinh doanh, không phải phương thức CRUD.

Đọc thêm
Tổng hợp - một cụm các đối tượng miền có thể được coi là một đơn vị

— Robert Harvey
nguồn

Bạn đang dành quá nhiều thời gian để suy nghĩ về các mẫu, thực tiễn và kiến trúc và không đủ thời gian để nghĩ về thiết kế phần mềm cơ bản. Tất cả những gì bạn cần là các phương pháp thể hiện các hoạt động kinh doanh, như tôi đã mô tả trong câu trả lời của mình.

— Robert Harvey

Đó không phải là một câu hỏi về việc chọn một kiến trúc. Ý kiến cá nhân của tôi: các hoạt động CRUD trần nên nói chuyện trực tiếp với Lớp thực thể. Tất nhiên, điều này có thể vi phạm Kiến trúc sạch.

— Robert Harvey

Bạn đang thiếu điểm. Kiến trúc chỉ là một phương tiện để tổ chức mã. Bạn giải quyết vấn đề bằng cách viết mã, không phải vật lộn với kiến trúc.

— Robert Harvey

Này Robert, thật tuyệt khi bạn cho rằng tôi không viết mã. Chủ đề của câu trả lời của tôi là về kiến trúc, và chúng tôi không phải về SO. Trân trọng, tôi thấy những bình luận cuối cùng của bạn thực sự sai lệch và điếc. Câu hỏi là về UseCase trong Clean Arch., Không viết mã. Nếu bạn đang cố gắng truyền đạt điều gì đó, vui lòng giải thích rõ hơn, vì tôi đang thiếu quan điểm của bạn. IMHO không thể tránh việc xem xét Kiến trúc trong khi phát triển phần mềm, hoặc ít nhất, các nhà phát triển giỏi không chỉ viết một loạt mã. Hơn nữa tôi đã hỏi một câu hỏi thực sự cụ thể trong bình luận của tôi, bạn có thể trả lời không? Cảm ơn

— Jackie Degl'Innocenti

Giải pháp cho vấn đề bạn đặt ra (ứng dụng ngoại tuyến trước tiên) thực sự không liên quan nhiều đến Kiến trúc sạch. Bạn sẽ không tìm thấy giải pháp cho vấn đề đó trong sơ đồ Kiến trúc sạch.

— Robert Harvey

Bạn đúng nếu mọi hoạt động CRUD được dịch trong một UseCase. Nhưng một UseCase cũng có thể bao gồm nhiều hoạt động CRUD.

UseCase là một mô hình riêng biệt thu thập thông tin từ các nguồn dữ liệu khác nhau và chuẩn bị liên lạc đến các nhóm dữ liệu. Có thể có nhiều hoạt động CRUD được tham gia.

Vì vậy, hãy nghĩ đến UseCase nơi tạo hóa đơn cho khách hàng VÀ cũng tự tạo khách hàng vì anh ấy / cô ấy không tồn tại trong hệ thống. Bạn có một UseCase dẫn đến ít nhất hai Hoạt động tạo trong một giao dịch.

— oopexpert
nguồn

Vì vậy, mô hình nào bạn sẽ giới thiệu cho ví dụ về CRUD với nhiều thực thể?

— Jackie Degl'Innocenti

Quan điểm cá nhân của tôi về điều này là: Tôi không có vấn đề gì khi có nhiều lớp miễn là họ không vi phạm SRP (nguyên tắc trách nhiệm duy nhất). Nhưng hầu hết thời gian tôi sẽ định nghĩa lại Usecase "tạo một thực thể", "cập nhật một thực thể", "xóa một thực thể" và "cập nhật một thực thể" thành một "thực thể quản lý loại X" đơn giản. Thường thì bạn cung cấp một UI duy nhất để quản lý một thực thể. Nhưng đó chính xác là những gì UseCase của bạn nên xác định: Cách xử lý khối lượng công việc có lợi cho doanh nghiệp của bạn.

— oopexpert

Ok, do đó, việc có Ca sử dụng quản lý các hoạt động khác nhau dường như không vi phạm SRP vì dường như chỉ "tổng hợp" nhiều phương thức (và luồng) khác nhau trong cùng một UseCase mà không có bất kỳ luồng nào xử lý nhiều hơn một khả năng đáp ứng. .. nhưng theo cách này, không phải chúng ta chỉ tạo một bộ điều khiển thay cho UseCase sao? .. ý tưởng .. Có thể trường hợp sử dụng phải được xem đơn giản là một lớp và lớp đó chỉ phải tôn trọng SRP nhưng cũng có thể thực hiện nhiều phương thức. Tôi muốn có một nguồn hoặc bài viết về điều này

— Jackie Degl'Innocenti

Một Usecase là một bộ điều khiển. Sự khác biệt duy nhất là, một usecase xuất phát từ quan điểm kinh doanh và bộ điều khiển là quan điểm kỹ thuật về nó. Trọng tâm của một usecase là, những gì đang tạo ra giá trị kinh doanh. Vì vậy, một usecase là một triển khai bộ điều khiển hướng giá trị kinh doanh.

— oopexpert

Đồng ý, bộ điều khiển HTTP là một cách quản lý I / O, cũng có thể có các lệnh console, phản ứng sự kiện, v.v. Tất cả các kênh I / O này gọi cùng một usecase. Một usecase là bộ điều khiển cho logic nghiệp vụ, nó không biết về các kênh I / O mà nó được gọi từ đó, nhưng nó biết cách phối hợp các thực thể miền để thực hiện công việc.

— Dmitriy Lezhnev

Định nghĩa của bạn về Use Case là sai, Use Case là một lớp thực hiện quy tắc kinh doanh, nó không cần phải là một hoạt động CRUD, nó có thể là một hoạt động nhiều bước phức tạp

— Buckstabue
nguồn

Câu của bạn không có nghĩa là một giải pháp khi bạn thực sự cần phải thực hiện một phạm vi rộng giống như Crud, thậm chí sự cân nhắc của bạn có thể tìm thấy một số liên quan đến thực tế rằng Ca sử dụng nên quan sát một mẫu mà chúng ta có thể truy cập vào một hoạt động phức tạp, thậm chí nhiều bước.

— Jackie Degl'Innocenti