Pertanyaan Menghindari model domain anemik - contoh nyata


Saya mencoba memahami Model Domain Anemik dan mengapa mereka dianggap anti-pola.

Inilah contoh dunia nyata.

Saya memiliki kelas Karyawan, yang memiliki banyak properti - nama, jenis kelamin, nama pengguna, dll

public class Employee
{
    public string Name { get; set; }
    public string Gender { get; set; }
    public string Username { get; set; }
    // Etc.. mostly getters and setters
}

Selanjutnya kita memiliki sistem yang melibatkan panggilan telepon yang berputar dan permintaan situs web (dikenal sebagai 'prospek') secara merata di antara staf penjualan. Sistem ini cukup rumit karena melibatkan permintaan round-robining, memeriksa liburan, preferensi karyawan, dll. Jadi sistem ini saat ini dipisahkan menjadi layanan: EmployeeLeadRotationService.

public class EmployeeLeadRotationService : IEmployeeLeadRotationService
{
     private IEmployeeRepository _employeeRepository;
     // ...plus lots of other injected repositories and services

     public void SelectEmployee(ILead lead)
     {
         // Etc. lots of complex logic
     }
}

Kemudian di bagian belakang formulir permintaan informasi situs web kami, kami memiliki kode seperti ini:

public void SubmitForm()
{
    var lead = CreateLeadFromFormInput();

    var selectedEmployee = Kernel.Get<IEmployeeLeadRotationService>()
                                 .SelectEmployee(lead);

    Response.Write(employee.Name + " will handle your enquiry. Thanks.");
}

Saya tidak benar-benar menghadapi banyak masalah dengan pendekatan ini, tetapi seharusnya ini adalah sesuatu yang harus saya jalankan berteriak dari karena itu adalah Model Domain Anemik.

Tetapi bagi saya tidak jelas di mana logika dalam layanan rotasi memimpin harus pergi. Haruskah itu memimpin? Haruskah itu masuk ke karyawan?

Bagaimana dengan semua repositori yang disuntik dan sebagainya yang diperlukan oleh layanan rotasi - bagaimana mereka akan disuntikkan ke dalam karyawan, mengingat bahwa sebagian besar waktu ketika berhadapan dengan karyawan kita tidak memerlukan salah satu dari repositori ini?


68
2018-05-18 05:49


asal


Jawaban:


Dalam hal ini, ini bukan merupakan Model Domain Anemik. Model Domain Anemik adalah khusus tentang memvalidasi dan mengubah objek. Jadi contohnya adalah jika fungsi eksternal benar-benar mengubah keadaan Karyawan atau memperbarui rinciannya.

apa yang terjadi dalam kasus ini adalah Anda mengambil semua karyawan dan membuat pilihan salah satunya berdasarkan informasi mereka. Tidak masalah untuk memiliki objek terpisah yang memeriksa orang lain dan membuat keputusan terkait dengan apa yang ditemukannya. TIDAK OK untuk memiliki objek yang digunakan untuk transisi objek dari satu negara ke negara lain.

Contoh dari Model Domain Anemik dalam kasus Anda adalah memiliki metode eksternal

updateHours(Employee emp) // updates the working hours for the employee

yang mengambil objek Karyawan dan memperbarui jam kerjanya selama seminggu, memastikan bahwa bendera dinaikkan jika jam melebihi batas tertentu. Masalah dengan ini adalah bahwa jika Anda hanya memiliki objek Karyawan maka Anda tidak memiliki pengetahuan tentang bagaimana memodifikasi jam mereka dalam batasan yang benar. Dalam hal ini cara untuk mengatasinya adalah memindahkan metode updateHours ke dalam kelas Karyawan. Itulah inti dari pola anti-model Domain Anemik.


49
2018-05-18 06:15



Saya pikir desain Anda baik-baik saja di sini. Seperti yang Anda ketahui, model anti-pola domain anemia adalah reaksi terhadap kecenderungan menghindari perilaku yang dikodekan dalam objek domain. Tapi sebaliknya itu tidak berarti semua perilaku yang berkaitan dengan objek domain harus dienkapsulasi oleh objek itu.

Sebagai aturan praktis, perilaku yang secara intrinsik terikat pada objek domain dan didefinisikan sepenuhnya dalam hal itu contoh objek domain dapat dimasukkan dalam objek domain. Jika tidak, untuk menjaga tanggung jawab yang jelas, yang terbaik untuk memasukkannya secara eksternal dalam kolaborator / layanan seperti yang Anda lakukan.


29
2018-05-18 06:00



Semuanya ada di kepala Anda - pertimbangkan layanan rotasi untuk menjadi bagian dari model domain dan masalahnya akan hilang.

Rotasi harus menyimpan informasi tentang banyak karyawan, sehingga tidak ada timbal, atau objek karyawan. Itu memang layak untuk menjadi objek domain itu sendiri.

Hanya mengganti nama "RotationService" menjadi sesuatu seperti "Organization.UserSupportDepartment" membuatnya terlihat jelas.


14
2018-05-18 06:56



Jika model domain Anda hanya berisi peran dan hal-hal, bukan aktivitas sebagai perilaku, maka itu adalah anemia. Namun, saya berbicara tentang perilaku dalam hal a model bukan sebuah obyek. Saya berbicara tentang perbedaan di antara mereka dalam jawaban lain ... https://stackoverflow.com/a/31780937/116442

Dari pertanyaan Anda, Anda melanggar dua aturan pemodelan analisis domain pertama saya: -

  1. Perilaku dimodelkan sebagai (direkam) Aktivitas merupakan jantung dari model domain. Tambahkan terlebih dahulu.
  2. Memodelkan aktivitas domain sebagai Kelas, bukan metode.

Saya akan menambahkan aktivitas "Kirim" ke model. Dengan itu model memiliki perilaku, dan dapat menggabungkan dan bekerja sebagai kelompok objek tanpa pengontrol atau skrip eksternal.

EnquiryHandlerModel


0
2017-08-03 12:13