Lapisan aplikasi vs lapisan domain?

Saya membaca Domain-Driven Design oleh Evans dan saya sedang membahas arsitektur berlapis. Saya baru menyadari bahwa lapisan aplikasi dan domain berbeda dan harus dipisahkan. Dalam proyek yang sedang saya kerjakan, mereka agak dicampur dan saya tidak bisa membedakannya sampai saya membaca buku (dan saya tidak bisa mengatakan itu sangat jelas bagi saya sekarang), sungguh.

Pertanyaan saya, karena keduanya menyangkut logika aplikasi dan seharusnya bersih dari aspek teknis dan presentasi, apa keuntungan dari menggambar batas keduanya?

Saya baru-baru ini membaca DDD sendiri. Ketika saya sampai di bagian ini, saya terkejut ketika mengetahui bahwa saya menemukan arsitektur 4-lapisan yang sama dengan yang dilakukan Evans. Seperti yang ditunjukkan @lonelybug, lapisan domain harus sepenuhnya diisolasi dari sisa sistem. Namun, sesuatu harus menerjemahkan nilai khusus UI (string kueri, data POST, sesi, dll.) Ke objek domain. Di sinilah lapisan aplikasi berperan. Tugasnya adalah menerjemahkan bolak-balik antara UI, lapisan data dan domain, secara efektif menyembunyikan domain dari sistem yang lain.

Saya melihat banyak aplikasi ASP.NET MVC sekarang di mana hampir semua logika ada di controller. Ini adalah upaya gagal untuk mengimplementasikan arsitektur 3-layer klasik. Pengontrol sulit untuk unit test karena mereka memiliki begitu banyak masalah khusus UI. Pada kenyataannya, menulis sebuah pengontrol sehingga tidak secara langsung peduli dengan nilai-nilai "Konteks Http" adalah tantangan yang serius dalam dirinya sendiri. Idealnya, pengontrol harus hanya melakukan penerjemahan, mengoordinasikan pekerjaan dan meludahkan respons.

Bahkan masuk akal untuk melakukan validasi dasar di lapisan aplikasi. Tidak apa-apa bagi domain untuk menganggap nilai yang masuk ke dalamnya masuk akal (apakah ini ID yang valid untuk pelanggan ini dan apakah string ini mewakili tanggal / waktu). Namun, validasi yang melibatkan logika bisnis (dapatkah saya memesan tiket pesawat di masa lalu?) Harus disediakan untuk lapisan domain.

Martin Fowler sebenarnya mengomentari seberapa rata kebanyakan lapisan domain saat ini . Meskipun sebagian besar orang bahkan tidak tahu apa itu lapisan aplikasi, ia menemukan bahwa banyak orang membuat objek domain yang agak bodoh dan lapisan aplikasi yang rumit yang mengoordinasikan pekerjaan dari objek domain yang berbeda. Saya sendiri juga bersalah. Yang penting bukanlah membangun lapisan karena beberapa buku menyuruh Anda melakukannya. Idenya adalah mengidentifikasi tanggung jawab dan memisahkan kode Anda berdasarkan tanggung jawab itu. Dalam kasus saya, "lapisan aplikasi" semacam berevolusi secara alami ketika saya meningkatkan pengujian unit.

Mengambil dari pola desain perusahaan Martin Fowler, lapisan yang paling umum adalah:

• Presentasi - ini adalah tampilan, templat presentasi yang menghasilkan antarmuka interaksi untuk aplikasi Anda (saya menggunakan interaksi jika aplikasi Anda diakses oleh sistem lain melalui layanan web atau RMI sehingga mungkin bukan antarmuka pengguna). Ini juga termasuk pengendali yang memutuskan bagaimana tindakan akan dieksekusi dan bagaimana.

• Domain - di sinilah aturan bisnis dan logika Anda berada, model domain Anda ditentukan dll

• Sumber Data - ini adalah lapisan pemetaan data (ORM) dan sumber data (database, sistem file dll)

Bagaimana Anda menggambar batas antara tiga lapisan:

• Jangan letakkan logika presentasi spesifik dalam model atau objek domain Anda

• Jangan menaruh logika di dalam halaman dan pengontrol Anda, yaitu logika untuk menyimpan objek ke database, membuat koneksi database dll, yang akan membuat lapisan presentasi Anda rapuh dan sulit untuk diuji

• Gunakan ORM yang memungkinkan Anda memisahkan akses dan tindakan sumber data dari model

• Ikuti paradigma thin controller - fat model, controller untuk mengontrol proses eksekusi yang tidak dijalankan, lebih lanjut di http://www.littlehart.net/atthekeyboard/2007/04/27/fat-models-skinny-controllers/ dan http://weblog.jamisbuck.org/2006/10/18/skinny-controller-fat-model model, tampilan dan pengontrol,

The lapisan domain model bisnis aplikasi Anda. Ini harus menjadi interpretasi Anda yang jelas tentang aturannya, dinamika komponennya, dan memuat keadaannya pada saat tertentu.

The layer aplikasi yang "khawatir" mendefinisikan pekerjaan yang harus dilakukan untuk menyelesaikan tugas aplikasi tertentu. Terutama, ia bertanggung jawab atas mandat pekerjaan domain yang diperlukan dan berinteraksi dengan layanan lain (eksternal atau tidak).

Sebagai contoh , aplikasi perangkat lunak keuangan saya memiliki operasi pengguna untuk mengubah status entitas model (entitas sebagaimana didefinisikan dalam DDD [89]):

• "Kepala operasi dapat menyetujui proposal keuangan".

Tapi, sebagai proses aplikasi, selain semua konsekuensi model dari operasi ini, saya harus mengirim komunikasi internal ke pengguna aplikasi yang lain. Jenis pekerjaan ini "diatur" di lapisan aplikasi. Saya tidak ingin lapisan domain saya berpikir tentang mengarahkan layanan pesan. (dan tentunya ini bukan tanggung jawab lapisan presentasi). Apa pun caranya, satu hal yang pasti: Saya perlu lapisan baru karena lapisan domain saya adalah semua tentang bisnis inti dan lapisan presentasi saya adalah semua tentang menafsirkan perintah pengguna dan menyajikan hasil.

Catatan:

• Bisnis adalah salah satu dari kata-kata yang sering mengarah pada beberapa interpretasi tentang maknanya, tetapi yang pasti Anda dapat menemukan banyak contoh dan pembicaraan tentang DDD;
• DDD adalah singkatan dari Domain-Driven Design book karya Eric Evans dan nomor dalam kurung siku untuk nomor halaman.

Lapisan Domain harus dirancang sebagai lapisan isolasi, yang berarti logika dan aturan bisnis tidak boleh terpengaruh dengan perubahan kode apa pun (dalam Lapisan Aplikasi, Lapisan Presentasi, dan Lapisan Infrastruktur).

Lapisan Aplikasi seharusnya dirancang untuk menyediakan beberapa fungsi tentang apa yang dapat dilakukan oleh antarmuka sistem (aplikasi) (pikirkan ini seperti API atau RESTful). Sebagai contoh, pengguna dapat login dalam suatu sistem, dan dalam aksi aplikasi ini (login), kode-kode lapisan aplikasi akan menjadi kode klien untuk Lapisan Domain (atau Lapisan Infrastruktur), di mana mengambil objek domain Pengguna dan menerapkan metode objek ini untuk mengimplementasikan fungsi 'login'.

Lapisan Aplikasi juga harus dirancang sebagai lapisan isolasi, yang berarti perilaku aplikasi tidak boleh terpengaruh dengan perubahan kode (dalam Lapisan Presentasi, Lapisan Domain, dan Lapisan Infrastruktur).

Inti dari Pemodelan Berbasis Domain adalah untuk memisahkan model domain esensial dan membuatnya ada tanpa ketergantungan pada lapisan lain dan masalah aplikasi lainnya.

Ini memungkinkan Anda untuk fokus pada domain itu sendiri tanpa gangguan (seperti mengoordinasi antara UI dan layanan kegigihan).

• Lapisan Aplikasi dan Lapisan Domain keduanya berada di bawah cakupan implementasi.
• Lapisan Aplikasi bertindak sebagai API.
• Lapisan Domain bertindak sebagai implementasi API, mengandung logika bisnis sehingga juga disebut Lapisan Logika Bisnis.

Alasan utama untuk batas-batas ini adalah pemisahan kekhawatiran . Kode yang mengakses penyimpanan data hanya perlu khawatir tentang mengakses penyimpanan data. Seharusnya tidak bertanggung jawab untuk menegakkan aturan pada data. Selain itu, UI harus bertanggung jawab untuk memperbarui kontrol di UI, mendapatkan nilai dari input pengguna dan menerjemahkannya ke sesuatu yang dapat digunakan oleh lapisan domain, dan tidak lebih. Ini harus memanggil operasi yang disediakan oleh lapisan domain untuk melakukan tindakan yang diperlukan (mis. Simpan file ini). Layanan web yang disebut harus bertanggung jawab untuk mengubah dari media transmisi ke sesuatu yang dapat digunakan oleh lapisan domain, dan kemudian memanggil lapisan domain (sebagian besar alat melakukan banyak pekerjaan untuk Anda).

Pemisahan ini, ketika diterapkan dengan benar dapat memberi Anda kemampuan untuk mengubah bagian-bagian kode Anda tanpa mempengaruhi orang lain. Misalnya, mungkin urutan pengurutan koleksi objek yang dikembalikan perlu diubah. Karena Anda tahu bahwa lapisan yang bertanggung jawab atas manipulasi data (biasanya lapisan logika bisnis) menangani hal-hal ini, Anda dapat dengan mudah mengidentifikasi di mana kode perlu diubah. Serta tidak harus mengubah cara itu diambil dari penyimpanan data, atau aplikasi yang menggunakan domain (UI dan layanan web dari contoh saya di atas).

Tujuan utamanya adalah membuat kode Anda semudah mungkin mempertahankannya.

Sebagai catatan tambahan, beberapa hal tidak dapat dimasukkan ke dalam lapisan domain tertentu (mis. Logging, validasi, dan otorisasi). Barang-barang ini biasanya disebut sebagai masalah lintas sektoral, dan dalam beberapa kasus dapat diperlakukan sebagai lapisan yang berdiri sendiri sehingga semua lapisan lain dapat melihat dan menggunakan.

Secara pribadi saya pikir pendekatan berlapis sudah ketinggalan zaman, dan bahwa pendekatan layanan lebih baik. Anda masih memiliki garis tegas di pasir siapa yang melakukan apa, tetapi itu tidak memaksa Anda untuk menjadi hirarkis. Misalnya, layanan pesanan pembelian, layanan penagihan, dan layanan pengiriman, dari perspektif aplikasi, semua layanan ini mewakili domain Anda, dan penangguhan tanggung jawab yang saya jelaskan di atas masih berlaku dalam konteks ini, baru saja diubah seperti bahwa domain Anda ada di banyak tempat, lebih lanjut menggunakan konsep pemisahan masalah.