Lapisan aplikasi vs lapisan domain?


47

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?

Jawaban:


36

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.


9
Saya tidak berpikir apa yang Anda nyatakan di sini benar: "Namun, sesuatu harus menerjemahkan nilai-nilai khusus UI (string kueri, data POST, sesi, dll.) Menjadi objek domain. Di sinilah lapisan aplikasi berperan". Apa yang Anda maksudkan adalah dalam istilah DDD lapisan "Presentasi". Layer Aplikasi seharusnya berurusan dengan masalah pipa ledeng, konkurensi, dan lintas sektoral, hanya menjadi pembungkus kecil di atas Layer Domain. Apa yang Anda gambarkan akan sesuai dengan (sub) lapisan dalam Lapisan Presentasi.
melahap elysium

23

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:


17

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.

6

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).


2
Setidaknya dalam literatur seperti Domain-Driven Design (Evans), diakui bahwa layer-layer tersebut memiliki ketergantungan satu arah ... faktanya, pada suatu titik kode Anda bergantung pada sesuatu . UI tergantung pada Aplikasi, tetapi tidak sebaliknya. Aplikasi tergantung pada Domain, tetapi tidak sebaliknya. Domain pada Infrastruktur, bukan sebaliknya.

1
Ketergantungan adalah tentang bagaimana pemrograman Anda, lapisan isolasi adalah tentang bagaimana Anda mendesain lapisan sistem Anda. Ketergantungan satu arah tidak merusak konsep isolasi di sini, karena ketika Anda pemrograman, kode lapisan atas harus bergantung pada antarmuka lapisan yang lebih rendah daripada kelas implementasi.
stevesun21

Itu bagus dan semuanya di atas kertas, tetapi dalam praktiknya, persyaratan bisnis menghasilkan perubahan yang dapat memengaruhi antarmuka lapisan aplikasi sedemikian rupa sehingga perubahan muncul melalui lapisan presentasi, dan kadang-kadang hingga ke lapisan penyimpanan. Itu saja yang saya

Desain lapisan isolasi tidak berarti tidak ada perubahan yang diizinkan di masa depan. Sebaliknya, itu membuat perubahan jauh lebih mudah - lebih mudah untuk diuji dan lebih mudah memperkirakan pekerjaan. Ya, persyaratan bisnis baru berarti Anda mungkin perlu mengubah dari atas ke bawah, bukankah cara Anda menerapkan fungsi yang ada sebelumnya? Jika Anda dapat mendesain setiap lapisan berdasarkan prinsip SOLID, maka Anda mungkin menemukan bahwa Anda bisa menggunakan kembali fungsi yang sudah ada dari lapisan bawah.
stevesun21

3

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).


Lalu, sumber data (ORM) ada di dalam domain?
Maykonn

@ Maykonn - Bisa jadi. Namun, ORM bukanlah sumber data. Ini adalah alat antara kode Anda dan sumber data aktual (database relasional). Bagaimana Anda mengakses data seharusnya tidak menjadi perhatian domain - pembangun dan pabrik dapat mengatasinya (dan ORM jika Anda memilikinya).
Oded

Saya setuju. Dan saya salah tentang sumber data dan ORM. Terima kasih!
Maykonn

3
  • 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.

masukkan deskripsi gambar di sini


tidak pernah seperti itu dengan cara ini .... Saya merasa tercerahkan
Nikos

2

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.


Saya ingin tahu tentang penempatan logika otorisasi, dan dari apa yang saya coba pahami, ini cocok dengan 'lapisan aplikasi'. Maukah Anda berbagi wawasan tentang mengapa mungkin bukan yang terbaik untuk memuatnya di dalam lapisan logika itu?

1
Itu adalah jenis pertanyaan yang sempurna untuk situs ini. Anda harus mempostingnya, sehingga setiap orang memiliki kesempatan untuk menjawab.
Charles Lambert

@tuespetre Bisakah Anda memberikan tautan ke pos itu?
drizzie
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.