Objek Nilai vs Entitas (Desain Didorong Domain)


92

Saya baru saja mulai membaca DDD. Saya tidak dapat sepenuhnya memahami konsep objek Entitas vs Nilai .. Dapatkah seseorang menjelaskan masalah (pemeliharaan, kinerja, dll.) Yang dapat dihadapi sistem ketika objek Nilai dirancang sebagai objek Entitas? Contoh akan sangat bagus ...


3
Di sini saya menulis daftar lengkap (IMO) perbedaan antara keduanya: enterprisecraftsmanship.com/2016/01/11/…
Vladimir

Jawaban:


109

Dikurangi menjadi perbedaan esensial, identitas penting untuk entitas, tetapi tidak masalah untuk objek nilai. Misalnya, Nama seseorang adalah objek nilai. Entitas Pelanggan mungkin terdiri dari Nama pelanggan (objek nilai), Daftar <Order> OrderHistory (Daftar entitas), dan mungkin Alamat default (biasanya objek nilai). Entitas Pelanggan akan memiliki ID, dan setiap pesanan akan memiliki ID, tetapi Nama tidak boleh; Secara umum, dalam model objek, identitas Alamat mungkin tidak menjadi masalah.

Objek nilai biasanya dapat direpresentasikan sebagai objek yang tidak berubah; mengubah satu properti dari objek nilai pada dasarnya menghancurkan objek lama dan membuat yang baru, karena Anda tidak terlalu mementingkan identitas seperti halnya konten. Benar, metode instance Equals pada Name akan mengembalikan "true" selama properti objek identik dengan properti instance lain.

Namun, mengubah beberapa atribut dari suatu entitas seperti Pelanggan tidak menghancurkan pelanggan; entitas Pelanggan biasanya bisa berubah. Identitasnya tetap sama (setidaknya setelah objek tersebut dipertahankan).

Anda mungkin membuat objek nilai tanpa menyadarinya; kapan pun Anda mewakili beberapa aspek Entitas dengan membuat kelas yang sangat detail, Anda mendapatkan objek nilai. Misalnya, kelas IPAddress, yang memiliki beberapa batasan pada nilai yang valid tetapi terdiri dari tipe data yang lebih sederhana, akan menjadi objek nilai. EmailAddress bisa berupa string, atau bisa juga objek nilai dengan kumpulan perilakunya sendiri.

Sangat mungkin bahkan item yang memiliki identitas dalam database Anda tidak memiliki identitas dalam model objek Anda. Tapi kasus paling sederhana adalah gabungan dari beberapa atribut yang masuk akal bersama. Anda mungkin tidak ingin memiliki Customer.FirstName, Customer.LastName, Customer.MiddleInitial, dan Customer.Title saat Anda dapat membuatnya bersama sebagai Customer.Name; mereka mungkin akan menjadi beberapa bidang dalam database Anda pada saat Anda memikirkan tentang persistensi, tetapi model objek Anda tidak peduli.


Di manakah objek yang tidak dapat dibagikan yang tidak dapat dibagikan cocok? Jika di seluruh alam semesta hanya ada satu referensi ke suatu objek, identitas objek tersebut tidak akan relevan meskipun bisa berubah. Menurut saya, sesuatu adalah suatu entitas jika terdapat suatu acuan yang dapat digunakan mengamati suatu aspek keadaan yang dapat berubah tanpa acuan tersebut digunakan untuk mengubahnya . Jika sesuatu tidak melekat pada dunia luar dan entah itu tidak dapat diubah atau hanya ada satu referensi padanya yang ada di manapun di alam semesta, maka skenario di atas tidak dapat terjadi dan itu adalah sebuah nilai.
supercat

Sesuatu seperti an int[1]mungkin merupakan nilai yang tidak dapat dibagikan yang tidak dapat dibagikan, nilai yang dapat dibagikan (jika tidak ada hal yang menyimpan referensi yang akan menulis padanya), atau sebuah entitas (jika ada dua atau lebih referensi, dan salah satunya dapat digunakan untuk menulis nilai-nilai yang dapat dibaca menggunakan yang lain). Sayangnya, saya tahu tidak ada dukungan bahasa di Java atau .NET untuk mencegah objek kelas yang merangkum nilai-nilai yang bisa berubah secara tidak sengaja berubah menjadi entitas.
supercat

@supercat, Jika yang Anda maksud tidak ada dukungan sederhana langsung, saya setuju, tetapi saya melakukan ini dengan menghilangkan akses publik ke konstruktor, hanya menggunakan pabrik statis untuk membuat instance baru, dan membatasi semua akses ke status melalui properti hanya-baca (Tanpa penyetel) .
Charles Bretana

40

Objek apa pun yang secara kolektif ditentukan oleh semua atributnya adalah objek nilai. Jika salah satu atribut berubah Anda memiliki contoh baru dari objek nilai. Inilah mengapa objek nilai didefinisikan sebagai tidak dapat diubah.

Jika objek tidak sepenuhnya ditentukan oleh semua atributnya, maka ada subset atribut yang membentuk identitas objek. Atribut yang tersisa dapat berubah tanpa mendefinisikan ulang objek. Jenis objek ini tidak dapat didefinisikan dengan tetap.

Cara yang lebih sederhana untuk membedakannya adalah dengan memikirkan objek nilai sebagai data statis yang tidak akan pernah berubah dan entitas sebagai data yang berkembang dalam aplikasi Anda.


7

Jenis Nilai:

  • Jenis nilai tidak ada dengan sendirinya, bergantung pada jenis entitas.
  • Objek Tipe Nilai milik Objek Tipe Entitas.
  • Umur instance tipe nilai dibatasi oleh umur instance entitas pemilik.
  • Tiga tipe Nilai: Dasar (tipe data primitif), Komposit (Alamat) dan Koleksi (Peta, Daftar, Array)

Entitas:

  • Jenis entitas bisa ada sendiri (Identity)
  • Suatu entitas memiliki siklus hidupnya sendiri. Itu mungkin ada secara independen dari entitas lain.
  • Misal: Person, Organization, College, Mobile, Home dll. Setiap benda memiliki identitasnya masing-masing

Tidak terkait dengan DDD :(
HydTechie

6

Saya tidak tahu apakah yang berikut ini benar, tetapi saya akan mengatakan bahwa dalam kasus objek Alamat, kami ingin menggunakannya sebagai Objek Nilai alih-alih Entitas karena perubahan pada entitas akan tercermin pada semua objek tertaut ( Seseorang misalnya).

Ambillah kasus ini: Anda tinggal di rumah Anda dengan beberapa orang lain. Jika kita akan menggunakan Entity for Address, saya berpendapat bahwa akan ada satu Address unik yang ditautkan ke semua objek Person. Jika satu orang pindah, Anda ingin memperbarui alamatnya. Jika Anda akan memperbarui properti Entitas Alamat, semua orang akan memiliki alamat yang berbeda. Dalam kasus Objek Nilai, kami tidak akan dapat mengedit Alamat (karena tidak dapat diubah) dan kami akan dipaksa untuk memberikan Alamat baru untuk Orang itu.

Apakah ini terdengar benar? Saya harus mengatakan bahwa saya juga masih bingung tentang perbedaan ini, setelah membaca buku DDD.

Selangkah lebih maju, bagaimana ini akan dimodelkan dalam database? Apakah Anda akan memiliki semua properti objek Alamat sebagai kolom di tabel Person atau apakah Anda akan membuat tabel Alamat terpisah yang juga akan memiliki pengenal unik? Dalam kasus terakhir, orang-orang yang tinggal di rumah yang sama masing-masing akan memiliki contoh yang berbeda dari sebuah objek Alamat, tetapi objek tersebut akan sama kecuali untuk properti ID mereka.


1
"Ambil kasus ini: Anda tinggal di rumah Anda dengan beberapa orang lain. Jika kita akan menggunakan Entitas untuk Alamat, saya berpendapat bahwa akan ada satu Alamat unik yang ditautkan ke semua objek Orang". Saya pikir masing-masing dari orang-orang itu memiliki contoh Alamatnya sendiri, tetapi mereka kebetulan sama (sepertinya masing-masing dari mereka dapat memiliki uang kertas 5 dolar, tetapi itu tidak berarti bahwa itu adalah uang kertas yang sama)
Prokurors

"tetapi itu tidak berarti bahwa itu adalah uang kertas yang sama" - Saya kira ini tergantung pada apakah seseorang menetapkan atau tidak properti tambahan pada uang kertas (misalnya tanggal dikeluarkan, lokasi fisik di luar angkasa, dll); kalau tidak mereka akan sama. Dan saya kira sama untuk perangkat lunak: Alamatnya sama atau tidak tergantung pada properti yang kita butuhkan / ingin pertimbangkan.
adrhc

4

alamat dapat berupa entitas atau objek nilai yang bergantung pada proses bisnis. Objek alamat dapat berupa entitas dalam aplikasi jasa kurir tetapi alamat dapat menjadi objek nilai di beberapa aplikasi lain. dalam hal identitas aplikasi kurir untuk objek alamat


2

Saya bertanya tentang ini di utas lain dan saya pikir saya masih bingung. Saya mungkin membingungkan pertimbangan kinerja dengan pemodelan data. Dalam aplikasi Katalog kami, Pelanggan tidak berubah sampai perlu. Kedengarannya bodoh - tetapi 'pembacaan' data pelanggan jauh melebihi 'tulis' dan karena banyak permintaan web semuanya mencapai 'set aktif' objek, saya tidak ingin terus memuat Pelanggan berkali-kali. Jadi saya menuju ke jalan yang tidak bisa diubah untuk objek Pelanggan - muat, simpan, dan layani yang sama ke 99% permintaan (multi-utas) yang ingin melihat Pelanggan. Kemudian, ketika pelanggan mengubah sesuatu, dapatkan 'editor' untuk membuat Pelanggan baru dan membatalkan yang lama.

Perhatian saya adalah jika banyak utas melihat objek pelanggan yang sama dan itu bisa berubah, maka ketika satu utas mulai mengubahnya, kekacauan terjadi di utas lainnya.

Masalah saya sekarang adalah, 1) apakah ini masuk akal, dan 2) cara terbaik untuk melakukan ini tanpa menduplikasi banyak kode tentang properti.


1

3 perbedaan antara EntitiesdanValue Objects

  • Identifier vs persamaan struktural: Entitas memiliki pengidentifikasi, entitas sama jika mereka memiliki pengidentifikasi yang sama. Objek Nilai di luar tangan memiliki persamaan struktural, kami menganggap dua nilai objek sama ketika semua bidang sama. Objek nilai tidak boleh memiliki pengenal.

  • Mutability vs immutability: Value Objects adalah struktur data yang tidak berubah sedangkan entitas berubah selama waktu hidup mereka.

  • Umur: Objek Nilai Harus Dimiliki Entitas


1

Dalam kalimat yang sangat sederhana yang dapat saya katakan, kami memiliki tiga jenis persamaan:

  • Identifikasi kesetaraan : kelas memiliki file id dan dua objek dibandingkan dengan nilai bidang id mereka.
  • Kesetaraan referensi : jika referensi ke dua objek memiliki alamat yang sama di memori.
  • Kesetaraan struktural : dua objek sama jika semua anggotanya cocok.

Kesetaraan pengenal hanya mengacu pada Entitas dan persamaan struktural mengacu pada Objek Nilai saja. Sebenarnya Value Objects tidak memiliki id dan kita bisa menggunakannya secara bergantian. juga objek nilai harus tidak dapat diubah dan entitas dapat berubah dan objek nilai tidak akan memiliki tabel dalam database.

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.