Panduan Struktur Proyek Aplikasi Layered MVVM, DDD, dan WPF

Saya mencoba mengatur struktur aplikasi saya di VS dan saya ingin "mencoba" dan membuktikannya di masa depan ke tingkat yang masuk akal. Aplikasi ini akan menjadi WPF menulis ulang aplikasi Winform lama yang tidak mengikuti konvensi. Tidak Ada Lapisan, Tingkatan, Akronim, dll ...

Ini adalah Aplikasi Perusahaan yang cukup besar. Saya berencana untuk menggunakan Linq To SQL sebagai DB saya dan kemungkinan besar akan selalu menjadi MS SQL. Juga saya memiliki keahlian yang ada dengannya.

Saya ingin mengikuti MVVM dan DDD semampu saya, tetapi saya bingung dengan struktur aplikasi saya saat menggabungkan ini. Biarkan saya coba dan ilustrasikan dengan beberapa contoh.

Ketika saya mengikuti MVVM, struktur folder saya mungkin terlihat seperti ini:

Views
Models
ViewModels
Helpers

tetapi bagaimana hal itu cocok dengan pendekatan berlapis DDD sederhana di mana Struktur Proyek saya mungkin menyerupai ini:

MyApp.UI
MyApp.Domain
MyApp.Data

Apakah saya meletakkan Modelsdi lapisan Domain atau apakah saya memiliki 3 versi mengatakan Person? Ini mengarah ke pertanyaan lain di mana saya akan meletakkan Repositori dan pemetaan Obyek DB ke Objek Domain? Saya akan menganggap data ...

ViewsSaya akan masuk UI tetapi ViewModelsjuga?

Akhirnya, di mana saya akan menanamkan Logika Bisnis saya?

Saya menemukan yang berikut ini pada CodePlex, Contoh DDD , dan itu sudah membantu tetapi tampaknya untuk Aplikasi Web meskipun itu mungkin tidak masalah dan ketidaktahuan saya bersinar melalui.

Jangan salah paham, saya tahu saya dapat memiliki banyak folder dan memanggilnya apa pun yang saya inginkan. Saya mencoba untuk mencari tahu di mana harus menempatkan sesuatu sehingga ini akan menjadi skala, bukan apa tempat itu seharusnya disebut.

Inti dari pertanyaan saya mungkin ditampilkan seperti ini.
Saya memiliki tblPersonobjek yang dihasilkan oleh *.dbml. Ini jelas dan akan berada di lapisan "Data" saya.
Sekarang saya akan memiliki Model, DTO, Model Domain, atau apa pun namanya dalam Layer terpisah (proyek?) Disebut Person. Saya akan membutuhkan Mapperuntuk Personuntuk tblPersonitu saya tidak yakin di mana untuk menempatkan.
Lalu, saya akan memiliki ViewModel untuk, katakanlah, EditPersonyang akan memiliki properti sendiri yang menarik Persontetapi mungkin lebih banyak juga.
Akhirnya saya memiliki View yang terikat dengan ViewModel itu ....

Supaya jelas bahwa paragraf DIISI dengan asumsi dan tebakan saya dan saya berharap seseorang akan membantu membersihkan udara bagi saya atau menawarkan wawasan di sana sehingga 6 bulan hingga satu tahun dari sekarang saya tidak menendang diri sendiri lebih dari yang saya butuhkan.

MVVM adalah pola UI dan digunakan pada klien.

Bagian-bagian dari domain di DDD yang digunakan di klien mungkin (bagian dari) Model

View dan Model View hanya klien.

Saya menempatkan Repositori dalam (atau dekat) Model karena mereka menyinkronkan Model ke back-end.

Ya, sering kali ini akan menghasilkan beberapa kelas Person di ruang nama yang berbeda. Mereka mungkin mulai sangat mirip tetapi mungkin berakhir sangat berbeda setelah beberapa iterasi atau rilis.

EDIT

Untuk memperjelas bagian tentang Gudang dan untuk menjelaskan lebih lanjut tentang posisi Logika Bisnis

Jika Anda membuat sistem yang berisi klien terpisah dan server-side / back-end Repositori dapat digunakan di klien dan server. Di klien untuk menyediakan abstraksi dari server (s) dan di server untuk memberikan abstraksi dari server lain dan sumber data. Itu hanya sebuah pola.

Adapun aturan Bisnis: jika Anda menggunakan yang ada di klien pastikan Anda menegakkannya di server juga. Jangan pernah mempercayai klien. Aturan bisnis di klien memungkinkan untuk validasi input cepat dan mencegah pulang pergi ke server.

Saya berpikir bahwa DDD berada di sisi server dan 'bocor' ke klien.

Anda memiliki arah yang benar dalam memilih pola desain MVVM untuk aplikasi WPF.

Do I put the Models in the Domain layer?

Ya, model Anda dapat ditempatkan di domain

Where would I put my Repository and mappings of DB Object to Domain Object?

Repositori Anda dapat ditempatkan di lapisan tempat Domain Anda ditempatkan. Objek pemetaan Anda (juga disebut DTO - objek transfer domain) harus ditempatkan di lapisan layanan Anda dan Anda dapat menggunakan alat pemetaan AutoMapper yang kuat untuk dengan mudah memetakan objek domain Anda ke DTO.

ViewModels also?

ViewModels Anda harus ditempatkan di sisi klien Anda (layer). Anda dapat membangun model view Anda dari satu atau lebih DTO, tergantung pada pandangan Anda.

Mengenai DDD , saya akan menyarankan untuk membaca tentang ini dan menjelaskan kepada Anda benar-benar perlu memiliki pola Desain Domain-Driven. di sini ada diskusi bahwa 95% dari semua aplikasi perangkat lunak termasuk dalam kategori “tidak begitu baik untuk menggunakan DDD”.

Sunting: referensi telah ditambahkan di atas, dan terima kasih untuk @Den!

Sebelum kita menyelidiki apa yang terjadi di mana, mari kita bicara tentang apa yang seharusnya dilakukan oleh setiap lapisan.

Titik penjualan MVVM adalah pengikatan antara tampilan dan model tampilan. Tujuannya di sini adalah untuk menghilangkan logika dalam tampilan.
Seperti View, Model harus cukup ringan dan hanya digunakan untuk mengakses informasi (data) yang diperlukan untuk view-model untuk beroperasi. Model dapat memadukan akses ke sumber data yang berbeda, tetapi seharusnya tidak memiliki logika bisnis. Dalam kebanyakan kasus, Anda memiliki satu penyimpanan data untuk dipukul. Dalam beberapa kasus Anda tidak. Jika tidak, sebaiknya gunakan Model untuk mengaburkan sumber data dari VM.

Poin implisit MVVM adalah bahwa data sudah disimpan dan proyek Anda tidak bertanggung jawab untuk mempertahankan organisasinya. Beberapa proyek cukup beruntung untuk lolos dari asumsi itu, sebagian besar proyek yang saya kerjakan belum seberuntung itu. Cukuplah untuk mengatakan bahwa Data adalah lapisan lain yang harus kita hadapi.

Saya akan menjelaskan proyek saya seperti ini:

 project.Views
 project.ViewModel
 project.Model
 project.DataStructs

dan lapisan ini dapat ditambahkan sesuai kebutuhan:

 project.Helpers

Saya memisahkan Pembantu dari sisa tumpukan sehingga tidak menjadi bingung sebagai lapisan tumpukan aplikasi Anda.

Penafian: Saya bukan ahli DDD, tapi saya mengerti inti umum dan melihat nilai dalam pendekatan.

Domain Anda akan menjadi set masalah yang Anda pertimbangkan.
Para Model Domain akan sesuai terutama untuk ViewModels yang Anda buat; sedikit di dalam Views; dan potongan kecil dalam Model / DataStructs.

Jadi bagaimana hasilnya?
JIKA Anda memiliki kemampuan untuk mengubah struktur data yang ada, maka yang baru Anda buat harus berkorelasi dengan masalah yang Anda coba selesaikan. Punya objek pelanggan? Maka Anda harus memiliki / beberapa tabel terkait dengan Pelanggan. Punya faktur atau produk? Cerita yang sama - tabel dan struktur yang memetakan ke objek bisnis tersebut harus dibuat.

Domain akan diekspresikan melalui objek ViewModel Anda dan Tampilan yang Anda sajikan dari objek tersebut. Jika Anda perlu mengedit catatan Pelanggan maka Anda akan memiliki VM untuk menangani tugas itu.

Aktif untuk pertanyaan Anda:

1. Jangan coba overlay DDD ke MVVM. Itu tidak akan berhasil. DDD bukan pola tata letak, ini adalah pendekatan untuk melihat masalah Anda secara keseluruhan.
2. Repositori dan Pemetaan akan hidup di project.Data atau project.Model yang sesuai.
3. Tidak memiliki lapisan bernama UI kecuali jika itu yang ingin Anda panggil project.Views.
4. Business Logic akan masuk dalam View-Model.