Menurut pendapat saya, itu sama sekali tidak seperti yang dimaksudkan. Dan itu pelanggaran KERING.
Idenya adalah bahwa entitas / objek domain di tengah dimodelkan untuk mewakili domain sebaik dan senyaman mungkin. Ini adalah pusat dari segalanya dan semuanya dapat bergantung padanya karena domain itu sendiri tidak berubah sebagian besar waktu.
Jika basis data Anda di luar dapat menyimpan objek-objek itu secara langsung, maka memetakannya ke format lain demi memisahkan lapisan tidak hanya sia-sia tetapi membuat duplikat model dan itu bukan maksudnya.
Untuk memulainya, arsitektur bersih dibuat dengan lingkungan / skenario khas yang berbeda dalam pikiran. Aplikasi server bisnis dengan lapisan luar raksasa yang membutuhkan jenis objek khusus mereka sendiri. Misalnya, database yang menghasilkan SQLRowobjek dan perlu SQLTransactionsuntuk memperbarui item. Jika Anda menggunakan yang ada di tengah, Anda melanggar arah ketergantungan karena inti Anda akan bergantung pada database.
Dengan ORM ringan yang memuat dan menyimpan objek entitas, bukan itu masalahnya. Mereka melakukan pemetaan antara internal SQLRowdan domain Anda. Bahkan jika Anda perlu memasukkan @Entitiyanotasi ORM ke objek domain Anda, saya berpendapat bahwa ini tidak membuat "penyebutan" lapisan luar. Karena anotasi hanyalah metadata, tidak ada kode yang tidak secara khusus mencari mereka yang akan melihatnya. Dan yang lebih penting, tidak ada yang perlu diubah jika Anda menghapusnya atau menggantinya dengan anotasi database yang berbeda.
Sebaliknya, jika Anda mengubah domain Anda dan membuat semua pemetaan itu, Anda harus banyak berubah.
Amandemen: Di atas sedikit terlalu disederhanakan dan bahkan bisa salah. Karena ada bagian dalam arsitektur bersih yang ingin Anda membuat representasi per lapisan. Tapi itu harus dilihat dalam konteks aplikasi.
Yaitu berikut ini di sini https://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-architecture.html
Yang penting adalah bahwa struktur data yang terisolasi, sederhana, dilewatkan melintasi batas. Kami tidak ingin menipu dan melewati baris Entitas atau Database. Kami tidak ingin struktur data memiliki segala jenis ketergantungan yang melanggar Aturan Ketergantungan.
Melewati entitas dari pusat ke arah lapisan luar tidak melanggar aturan dependensi, namun disebutkan. Tetapi ini memiliki alasan dalam konteks aplikasi yang dibayangkan. Melewati entitas di sekitar akan memindahkan logika aplikasi ke arah luar. Lapisan luar perlu tahu bagaimana menafsirkan objek dalam, mereka harus melakukan apa yang seharusnya dilakukan lapisan dalam seperti "use case".
Selain itu, ia juga memisahkan lapisan sehingga perubahan ke inti tidak perlu memerlukan perubahan di lapisan luar (lihat komentar SteveCallender). Dalam konteks itu, mudah untuk melihat bagaimana objek harus mewakili secara spesifik tujuan mereka digunakan. Lapisan itu juga harus berbicara satu sama lain dalam hal objek yang dibuat khusus untuk tujuan komunikasi ini. Ini bahkan dapat berarti bahwa ada 3 representasi, 1 di setiap lapisan, 1 untuk transportasi antar lapisan.
Dan ada https://blog.8thlight.com/uncle-bob/2011/11/22/Clean-Architecture.html yang membahas di atas:
Orang lain khawatir bahwa hasil bersih dari saran saya akan menjadi banyak kode duplikat, dan banyak menyalin data secara hafal dari satu struktur data ke yang lain di seluruh lapisan sistem. Tentu saya juga tidak menginginkan ini; dan tidak ada yang saya sarankan akan mengarah pada pengulangan struktur data dan banyak sekali penyalinan di lapangan.
Itu IMO menyiratkan bahwa menyalin objek 1: 1 polos adalah bau dalam arsitektur karena Anda tidak benar-benar menggunakan lapisan yang tepat dan / atau abstraksi.
Dia kemudian menjelaskan bagaimana dia membayangkan semua "penyalinan"
Anda memisahkan UI dari aturan bisnis dengan mengirimkan struktur data sederhana di antara keduanya. Anda tidak membiarkan pengendali Anda tahu apa-apa tentang aturan bisnis. Sebagai gantinya, pengendali membongkar objek HttpRequest ke dalam struktur data vanilla sederhana, dan kemudian meneruskan struktur data itu ke objek interaksor yang mengimplementasikan use case dengan menggunakan objek bisnis. Interaksi kemudian mengumpulkan data respons ke dalam struktur data vanili lain dan meneruskannya kembali ke UI. Pandangan tidak tahu tentang objek bisnis. Mereka hanya melihat struktur data itu dan menyajikan responsnya.
Dalam aplikasi ini, ada perbedaan besar antara representasi. Data yang mengalir bukan hanya entitas. Dan ini menjamin dan menuntut kelas yang berbeda.
Namun, diterapkan pada aplikasi Android sederhana seperti penampil foto di mana Photoentitas memiliki sekitar 0 aturan bisnis dan "kasus penggunaan" yang berkaitan dengannya hampir tidak ada dan sebenarnya lebih peduli tentang caching & mengunduh (proses yang seharusnya IMO dilakukan diwakili secara lebih eksplisit), titik untuk membuat representasi terpisah dari suatu foto mulai menghilang. Saya bahkan merasa bahwa foto itu sendiri adalah objek transfer data sementara lapisan bisnis-logika-inti-nyata tidak ada.
Ada perbedaan antara "pisahkan UI dari aturan bisnis dengan melewatkan struktur data sederhana antara keduanya" dan "saat Anda ingin menampilkan foto, ganti nama itu 3 kali dalam perjalanan" .
Selain itu, titik di mana saya melihat aplikasi demo gagal mewakili arsitektur bersih adalah bahwa mereka menambahkan penekanan besar pada pemisahan lapisan demi pemisahan lapisan tetapi secara efektif menyembunyikan apa yang dilakukan aplikasi. Itu berbeda dengan apa yang dikatakan di https://blog.8thlight.com/uncle-bob/2011/09/30/Screaming-Architecture.html - yaitu
arsitektur aplikasi perangkat lunak berteriak tentang kasus penggunaan aplikasi
Saya tidak melihat penekanan pada pemisahan lapisan dalam arsitektur bersih. Ini tentang arah ketergantungan dan fokus pada mewakili inti dari aplikasi - entitas dan kasus penggunaan - di Jawa polos idealnya tanpa ketergantungan ke luar. Ini bukan soal ketergantungan pada inti itu.
Jadi jika aplikasi Anda benar-benar memiliki inti yang mewakili aturan bisnis dan kasus penggunaan, dan / atau orang yang berbeda bekerja pada lapisan yang berbeda, harap pisahkan dengan cara yang dimaksud. Jika Anda di sisi lain hanya menulis aplikasi sederhana sendiri jangan berlebihan. 2 lapisan dengan batas lancar mungkin lebih dari cukup. Dan lapisan dapat ditambahkan nanti juga.
BankAccounttetapi dengan aturan khusus aplikasi apa yang dapat Anda lakukan dengan akun itu.