Apakah ini struktur solusi Visual Studio yang baik untuk desain yang digerakkan oleh domain Layanan web yang tenang?

15

Saya sedang membangun .NET 4,5 C # solusi API Web RESTful dan saya ingin seseorang untuk memberi tahu saya jika solusi proyek saya benar dan / atau bijaksana (-cukup?) Untuk solusi yang dirancang menggunakan Domain Driven Design, tolong.

Solusinya telah dibagi menjadi 6 proyek:

/Mendasarkan

(Tidak dirujuk oleh apa pun)

Proyek web dan membentuk antarmuka antara solusi dan dunia luar. Berisi pengontrol API Web. Hampir tidak mengandung logika selain mengumpulkan nilai dari objek permintaan dan meminta lapisan BizApi untuk bekerja.

/Biz.Api

(Dirujuk oleh Basis])

Menyediakan layanan domain dan memungkinkan proyek antarmuka / Base untuk memiliki akses ke objek logika bisnis domain di proyek /Biz.Domain.

/Biz.Domain

(Dirujuk oleh Biz.Api)

Menyediakan kelas domain untuk lapisan Biz.Api. Ini memberikan metode untuk memanipulasi data bisnis dalam memori.

/Dal.Db

(Dirujuk oleh Biz.Api)

Lapisan repositori basis data. Mengakses basis data dan memetakan data yang dikembalikan ke DTO internal yang ditentukan dalam lapisan / Antarmuka.

/Dal. Layanan

(Dirujuk oleh Biz.Api)

Memberikan lapisan proksi ke dependensi eksternal seperti layanan web dan memetakan data yang dikembalikan ke DTO internal yang ditentukan dalam proyek / Antarmuka.

/ Antarmuka

(Dirujuk oleh sebagian besar proyek di atas)

Berisi kelas DTO untuk meneruskan data di sekitar solusi dan antarmuka C # untuk menentukan kontrak untuk hal-hal seperti IoC.

c# rest domain-driven-design

— Matt W
sumber

"/Biz.Api Menyediakan layanan domain": maksud Anda Layanan Aplikasi? Juga, Repositori biasanya tidak mengembalikan DTO tetapi entitas (akar agregat). Dan ketergantungan antara proyek-proyek ini juga baik untuk diketahui;)

— guillaume31

Ya, maksud saya Layanan Aplikasi. Repositori mengembalikan instance kelas yang hanya menyimpan data - data ini dipetakan ke instance menggunakan, dalam hal ini, AutoMapper. Contoh yang dikembalikan tidak memiliki metode manipulasi, yang saya kumpulkan dimiliki Entitas.

— Matt W

"data ini dipetakan": antara apa dan apa? Apa yang Anda maksud dengan "memanipulasi metode"?

— guillaume31

22

Struktur folder ini terinspirasi oleh buku desain yang diimplementasikan oleh domain Implementing yang terkenal dari Vaugh Vernon.

Solusi:
├ WebService ^{_{(Layanan REST berada di sini)}}
├ WebServiceTests
├ Aplikasi ^{_{(Layanan aplikasi berada di sini)}}
├ ApplicationTests
├ Domain ^{_{(Entitas, VO, layanan Domain, pabrik domain, spesifikasi, peristiwa domain, antarmuka Repositori, antarmuka layanan infrastruktur)}}
├ DomainTests
├ Infrastruktur ^{_{(Repositori, Impl. Layanan infrastruktur., Adaptor untuk layanan eksternal)}}
└ InfrastructureTests

Saya mulai dengan Solusi kemudian membuat empat proyek untuk setiap lapisan dalam aplikasi saya kemudian empat proyek lain untuk setiap lapisan tes.

Jangan membuat folder interfacesatau servicesdi lapisan domain Anda sebagai gantinya kelas terkait harus dikelompokkan berdasarkan fungsi dalam modul.

— Songo
sumber

1

Sejauh strukturnya, bagi saya tampaknya baik-baik saja walaupun saya akan datang dengan nama-nama yang berbeda, lebih deskriptif diri, seperti "YourProjectWebApi"bukannya "Base", "Dal.External"bukannya "Dal.Services"dan sebagainya.

Mungkin ada bau di bagian "DTO internal", karena Anda seharusnya mengeluarkan entitas dari repositori dan dapat mengambil tindakan domain (bisnis) langsung pada mereka. Entitas bukan hanya milik DTO.

Saya agak mengumpulkan dari fakta yang Dal.Dbtidak memiliki ketergantungan terhadap Biz.Domain,lapisan Domain yang melakukan pemetaan antara DTO dari proyek Antarmuka (dikembalikan oleh Repositori?) Dan objek Domainnya sendiri. Ini tidak akan benar dalam arsitektur DDD state-of-the-art (== "bawang" atau "heksagonal") - lapisan Domain tidak boleh merujuk proyek lain. Untuk alasan yang sama, antarmuka Repositori harus dideklarasikan dalam Domain dan tidak Interfacesseperti yang saya duga.

— guillaume31
sumber