Arsitektur Bersih - Terlalu Banyak Menggunakan Kelas Kasus

Saya akan masuk ke Arsitektur Bersih dan mengangkat level Android saya dari MVC ke MVP , memperkenalkan DI dengan Dagger 2, Reaktivitas dengan RxJava 2, dan tentu saja Java 8.

Dalam arsitektur bersih MVP ada lapisan antara entitas (di datastores) dan presenter yang harus mengaksesnya. Lapisan ini adalah "Use Case" . Sebuah use case itu idealnya sebuah antarmuka, yang mengimplementasikan SATU operasi pada SATU entitas.

Saya juga tahu bahwa Clear Architecture " menjerit ", dalam arti proyeknya sangat mudah dibaca karena banyaknya kelas di dalamnya.

Sekarang, dalam proyek saya, saya memiliki sekitar 6 entitas yang berbeda , dan tentu saja, setiap repositori entitas memiliki setidaknya 4 metode (biasanya mendapatkan, menambah, menghapus, memperbarui) untuk mengaksesnya .. jadi, 6 * 4 = 24 .

Jika apa yang saya mengerti sampai sekarang tentang Arsitektur Bersih, saya akan memiliki 24 UseCase.

Ini banyak kelas jika dibandingkan dengan hanya 6 controller di MVC ..

Apakah saya harus membuat 24 use case?

Saya akan sangat menghargai klarifikasi oleh seseorang yang sudah menggunakannya dengan sukses.

Terima kasih, Jack

— Jackie Degl'Innocenti
sumber

Bisakah Anda memposting tautan ke halaman yang menjelaskan Kasus Penggunaan ini secara detail, dengan kode contoh?

— Robert Harvey

Saya telah banyak mencari di Google, tetapi terutama: contoh aplikasi ini dan artikel terkait: github.com/jshvarts/OfflineSampleApp ; artikel ini: proandroiddev.com/… ; proandroiddev.com/… ; Pembicaraan ini: youtube.com/watch?v=TvsOsgd0--c&feature=youtu.be ; Dan artikel ini juga: adityaladwa.wordpress.com/2016/10/25/…

— Jackie Degl'Innocenti

Tak satu pun dari aplikasi sampel atau artikel yang Anda kutip tampaknya memiliki banyak kaitan dengan Arsitektur Bersih. Namun, mereka banyak berbicara tentang pemrograman reaktif.

— Robert Harvey

Contoh aplikasi pasti dibuat dengan paradigma Arsitektur Bersih .. Artikel-artikel lain kebanyakan .. Apa yang ingin Anda lihat @RobertHarvey?

— Jackie Degl'Innocenti

Baca jawaban saya di bawah dan balas.

— Robert Harvey

Jawaban:

Apakah saya harus membuat 24 use case?

Hanya jika semua yang Anda tulis adalah CRUD .

Lihat diagram di bawah ini:

Pernyataan Anda adalah bahwa Anda akan memiliki enam entitas yang berbeda, dan 4 metode (Buat, Baca, Perbarui dan Hapus) untuk setiap entitas. Tapi itu hanya berlaku di lingkaran kuning di tengah diagram (lapisan Entitas). Tidak ada gunanya untuk membuat 24 metode di lapisan Kasus Penggunaan yang hanya melewati panggilan CRUD ke lapisan Entitas.

A Use Case bukan "Tambahkan Catatan Pelanggan." Case Use lebih sesuai dengan garis "Jual barang ke pelanggan" (yang melibatkan entitas Pelanggan, Produk, dan Inventaris) atau "Cetak faktur" (yang melibatkan entitas yang sama, selain Header Faktur dan Item Faktur Line ).

Saat Anda membuat Use Cases, Anda harus memikirkan transaksi bisnis, bukan metode CRUD.

Agregat Bacaan Lebih Lanjut
- sekelompok objek domain yang dapat diperlakukan sebagai satu unit

— Robert Harvey
sumber

Anda menghabiskan terlalu banyak waktu untuk memikirkan pola, praktik, dan arsitektur, dan tidak cukup waktu untuk memikirkan desain perangkat lunak dasar. Yang Anda butuhkan adalah metode yang mewujudkan praktik bisnis, seperti yang saya jelaskan dalam jawaban saya.

— Robert Harvey

Ini bukan masalah memilih arsitektur. Pendapat pribadi saya: operasi CRUD yang telanjang harus berbicara langsung ke Entity Layer. Tentu saja, ini mungkin melanggar Arsitektur Bersih.

— Robert Harvey

Anda agak kehilangan intinya. Arsitektur hanyalah sarana untuk mengatur kode. Anda memecahkan masalah dengan menulis kode, bukan bergulat dengan arsitektur.

— Robert Harvey

Hei Robert, itu tidak begitu baik sehingga Anda menganggap bahwa saya tidak menulis kode. Topik jawaban saya ada di arsitektur, dan kami tidak di SO. Hormat saya, saya menemukan komentar terakhir Anda benar-benar menyesatkan dan tuli. Pertanyaannya adalah tentang UseCase di Clean Arch., Bukan menulis kode. Jika Anda mencoba mengomunikasikan sesuatu tolong jelaskan dengan lebih baik, karena saya kehilangan poin dari komentar Anda. IMHO itu tidak mungkin untuk menghindari pertimbangan Arsitektur saat mengembangkan perangkat lunak, atau setidaknya, pengembang yang baik tidak hanya menulis banyak kode. Selain itu saya mengajukan pertanyaan yang sangat spesifik dalam komentar saya, dapatkah Anda menjawab? Terima kasih

— Jackie Degl'Innocenti

Solusi untuk masalah yang Anda ajukan (aplikasi offline terlebih dahulu) tidak benar-benar ada hubungannya dengan Arsitektur Bersih. Anda tidak akan menemukan solusi untuk masalah itu dalam diagram Arsitektur Bersih.

— Robert Harvey

Anda benar jika setiap Operasi CRUD diterjemahkan dalam satu UseCase. Tetapi UseCase juga dapat terdiri dari beberapa Operasi CRUD.

UseCase adalah model terpisah yang mengumpulkan informasi dari sumber data yang berbeda dan menyiapkan komunikasi ke data sink. Mungkin ada beberapa Operasi CRUD yang terlibat.

Jadi pikirkan sebuah UseCase di mana membuat faktur untuk pelanggan DAN menciptakan juga pelanggan itu sendiri karena dia tidak ada dalam sistem. Anda memiliki satu UseCase yang menghasilkan setidaknya dua Operasi Buat dalam satu transaksi.

— oopexpert
sumber

Jadi, pola apa yang akan Anda sarankan untuk contoh CRUD dengan banyak entitas?

— Jackie Degl'Innocenti

Pandangan pribadi saya tentang ini adalah: Saya tidak punya masalah untuk memiliki banyak kelas selama mereka tidak melanggar SRP (prinsip tanggung jawab tunggal). Tapi saya sebagian besar waktu akan mendefinisikan kembali Usecases "buat entitas", "perbarui entitas", "hapus entitas" dan "perbarui entitas" menjadi "kelola entitas tipe X" yang sederhana. Seringkali Anda memberikan UI tunggal untuk mengelola satu entitas. Tetapi itulah yang harus didefinisikan oleh UseCase Anda: Cara menangani banyak pekerjaan bermanfaat untuk bisnis Anda.

— oopexpert

Ok, jadi, memiliki Use Case yang mengelola berbagai operasi yang berbeda tampaknya tidak melanggar SRP karena tampaknya hanya "mengumpulkan" metode yang lebih berbeda (dan mengalir) di UseCase yang sama tanpa itu aliran tunggal menangani lebih dari satu tanggung jawab. .. tetapi dengan cara ini bukankah kita hanya membuat pengontrol menggantikan UseCase? .. idea .. Mungkin Use Case harus dilihat sebagai layer, dan layer itu hanya harus menghormati SRP tetapi juga bisa mengimplementasikan banyak metode. Saya ingin memiliki sumber atau artikel tentang ini

— Jackie Degl'Innocenti

A Usecase IS A controller. Satu-satunya perbedaan adalah, bahwa usecase berasal dari perspektif bisnis dan pengontrol adalah pandangan teknis di atasnya. Fokus dari usecase adalah, apa yang menghasilkan nilai bisnis. Jadi usecase adalah implementasi pengontrol yang didorong oleh nilai bisnis.

— oopexpert

Setuju, pengontrol HTTP adalah cara mengelola I / O, bisa juga ada perintah konsol, reaksi peristiwa, dan sebagainya. Semua saluran I / O ini memanggil usecase yang sama. Sebuah usecase ADALAH pengontrol untuk logika bisnis, ia tidak tahu tentang saluran I / O dari mana ia dipanggil, tetapi ia tahu bagaimana mengatur entitas domain untuk melakukan pekerjaan itu.

— Dmitriy Lezhnev

Definisi Anda tentang Use Case salah, Use Case adalah kelas yang menerapkan aturan bisnis, tidak perlu menjadi operasi CRUD, itu bisa menjadi operasi multi langkah yang kompleks

— Buckstabue
sumber

Kalimat Anda tidak berarti solusi ketika Anda benar-benar perlu mengimplementasikan operasi seperti Crud, bahkan pertimbangan Anda mungkin menemukan beberapa hubungan dengan fakta bahwa Use Case harus mengamati pola di mana kita dapat mengakses ke operasi yang kompleks, bahkan multi langkah.

— Jackie Degl'Innocenti