Bagikan melalui

Mendesain model domain layanan mikro

Petunjuk / Saran

Konten ini adalah kutipan dari eBook, Arsitektur Layanan Mikro .NET untuk Aplikasi .NET Kontainer, tersedia di .NET Docs atau sebagai PDF gratis yang dapat diunduh yang dapat dibaca secara offline.

Unduh PDF

Arsitektur Layanan Mikro .NET untuk Aplikasi .NET Dalam Kontainer: gambar kecil sampul eBook.

Tentukan satu model domain kaya untuk setiap layanan mikro bisnis atau Konteks Terikat.

Tujuan Anda adalah membuat satu model domain kohesif untuk setiap layanan mikro bisnis atau Konteks Terikat (SM). Namun, perlu diingat bahwa layanan mikro SM atau bisnis terkadang dapat terdiri dari beberapa layanan fisik yang berbagi satu model domain. Model domain harus mengambil aturan, perilaku, bahasa bisnis, dan batasan dari satu Konteks Terikat atau layanan mikro bisnis yang diwakilinya.

Pola Entitas Domain

Entitas mewakili objek domain dan terutama didefinisikan oleh identitas, kelangsungan, dan persistensinya dari waktu ke waktu, dan tidak hanya oleh atribut yang terdiri darinya. Seperti yang dikatakan Eric Evans, "objek yang terutama didefinisikan oleh identitasnya disebut Entitas." Entitas sangat penting dalam model domain, karena mereka adalah dasar untuk model. Oleh karena itu, Anda harus mengidentifikasi dan merancangnya dengan hati-hati.

Identitas entitas dapat melintasi beberapa layanan mikro atau Konteks Terikat.

Identitas yang sama (yaitu, nilai yang sama Id , meskipun mungkin bukan entitas domain yang sama) dapat dimodelkan di beberapa Konteks Terikat atau layanan mikro. Namun, itu tidak menyiratkan bahwa entitas yang sama, dengan atribut dan logika yang sama akan diimplementasikan dalam beberapa Konteks Terikat. Sebagai gantinya, entitas di setiap Konteks Terikat membatasi atribut dan perilaku mereka untuk yang diperlukan di domain Konteks Terikat tersebut.

Misalnya, entitas pembeli mungkin memiliki sebagian besar atribut seseorang yang ditentukan dalam entitas pengguna di profil atau layanan mikro identitas, termasuk identitas. Tetapi entitas pembeli dalam layanan mikro pemesanan mungkin memiliki lebih sedikit atribut, karena hanya data pembeli tertentu yang terkait dengan proses pesanan. Konteks setiap layanan mikro atau Konteks Terikat berdampak pada model domainnya.

Entitas domain harus menerapkan perilaku selain menerapkan atribut data.

Entitas domain di DDD harus menerapkan logika domain atau perilaku yang terkait dengan data entitas (objek yang diakses dalam memori). Misalnya, sebagai bagian dari kelas entitas pesanan, Anda harus memiliki logika bisnis dan operasi yang diterapkan sebagai metode untuk tugas seperti menambahkan item pesanan, validasi data, dan perhitungan total. Metode entitas mengelola invarian dan aturan entitas daripada membiarkan aturan tersebut tersebar di lapisan aplikasi.

Gambar 7-8 menunjukkan entitas domain yang mengimplementasikan tidak hanya atribut data tetapi operasi atau metode dengan logika domain terkait.

Diagram memperlihatkan pola Entitas Domain.

Gambar 7-8. Contoh desain entitas domain yang mengimplementasikan data plus perilaku

Entitas model domain mengimplementasikan perilaku melalui metode, yaitu, itu bukan model "anemic". Tentu saja, terkadang Anda dapat memiliki entitas yang tidak menerapkan logika apa pun sebagai bagian dari kelas entitas. Ini dapat terjadi pada entitas anak dalam agregat jika entitas anak tidak memiliki logika khusus karena sebagian besar logika ditentukan dalam akar agregat. Jika Anda memiliki layanan mikro yang kompleks dengan logika yang diterapkan di kelas layanan, bukan di entitas domain, Anda mungkin terjebak dalam model domain anemik, seperti yang dijelaskan di bagian berikut.

Model domain berlimpah versus model domain anemik

Dalam postingnya AnemicDomainModel, Martin Fowler menjelaskan model domain anemic dengan cara ini:

Gejala dasar dari Anemic Domain Model adalah bahwa pada awalnya terlihat seperti hal yang nyata. Ada objek, banyak dinamai sesuai kata benda di ruang domain, dan objek ini terhubung dengan hubungan dan struktur kaya yang dimiliki model domain sejati. Tangkapan datang ketika Anda melihat perilaku, dan Anda menyadari bahwa hampir tidak ada perilaku pada objek-objek ini, membuatnya sedikit lebih dari kantong getter dan setter.

Tentu saja, ketika Anda menggunakan model domain anemic, model data tersebut akan digunakan dari sekumpulan objek layanan (secara tradisional bernama lapisan bisnis) yang menangkap semua domain atau logika bisnis. Lapisan bisnis berada di atas model data dan menggunakan model data sama seperti data.

Model domain anemia hanyalah desain dengan gaya prosedural. Objek entitas anemis bukanlah objek yang nyata karena tidak memiliki perilaku (metode). Mereka hanya menyimpan properti data dan dengan demikian bukan desain berorientasi objek. Dengan menempatkan semua perilaku ke dalam objek layanan (lapisan bisnis), Anda pada dasarnya berakhir dengan kode spaghetti atau skrip transaksi, dan oleh karena itu Anda kehilangan keuntungan yang disediakan model domain.

Terlepas dari itu, jika layanan mikro atau Konteks Terikat Anda sangat sederhana (layanan CRUD), model domain anemic dalam bentuk objek entitas hanya dengan properti data mungkin cukup baik, dan mungkin tidak layak menerapkan pola DDD yang lebih kompleks. Dalam hal ini, ini hanya akan menjadi model persistensi, karena Anda telah sengaja membuat entitas hanya dengan data untuk tujuan CRUD.

Itulah sebabnya arsitektur layanan mikro sangat cocok untuk pendekatan multi-arsitektur tergantung pada setiap Konteks Terikat. Misalnya, dalam eShopOnContainers, layanan mikro pemesanan mengimplementasikan pola DDD, tetapi layanan mikro katalog, yang merupakan layanan CRUD sederhana, tidak.

Beberapa orang mengatakan bahwa model domain anemik adalah anti-pola. Itu benar-benar tergantung pada apa yang Anda terapkan. Jika layanan mikro yang Anda buat cukup sederhana (misalnya, layanan CRUD), mengikuti konsep "anemic domain model" bukanlah anti-pola. Namun, jika Anda perlu mengatasi kompleksitas domain layanan mikro yang memiliki banyak aturan bisnis yang terus berubah, model domain anemik mungkin kontra-pola untuk layanan mikro atau Konteks Terikat tersebut. Dalam hal ini, merancangnya sebagai model kaya dengan entitas yang berisi data plus perilaku serta menerapkan pola DDD tambahan (agregat, objek nilai, dll.) mungkin memiliki manfaat besar untuk keberhasilan jangka panjang layanan mikro seperti itu.

Sumber daya tambahan

Pola Objek Nilai

Seperti yang telah dicatat Eric Evans, "Banyak objek tidak memiliki identitas konseptual. Objek-objek ini menggambarkan karakteristik tertentu dari suatu hal."

Entitas memerlukan identitas, tetapi ada banyak objek dalam sistem yang tidak, seperti pola Objek Nilai. Objek nilai adalah objek tanpa identitas konseptual yang menjelaskan aspek domain. Ini adalah objek yang Anda buat untuk mewakili elemen desain yang hanya menyangkut Anda sementara. Anda peduli tentang apa mereka, bukan siapa mereka. Contohnya termasuk angka dan string, tetapi juga dapat menjadi konsep tingkat yang lebih tinggi seperti grup atribut.

Sesuatu yang merupakan entitas dalam layanan mikro mungkin bukan entitas di layanan mikro lain, karena dalam kasus kedua, Konteks Terikat mungkin memiliki arti yang berbeda. Misalnya, alamat dalam aplikasi e-niaga mungkin tidak memiliki identitas sama sekali, karena mungkin hanya mewakili sekelompok atribut profil pelanggan untuk seseorang atau perusahaan. Dalam hal ini, alamat harus diklasifikasikan sebagai objek nilai. Namun, dalam aplikasi untuk perusahaan utilitas daya listrik, alamat pelanggan bisa menjadi penting untuk domain bisnis. Oleh karena itu, alamat harus memiliki identitas sehingga sistem penagihan dapat langsung ditautkan ke alamat. Dalam hal ini, alamat harus diklasifikasikan sebagai entitas domain.

Seseorang dengan nama dan nama keluarga biasanya merupakan entitas karena seseorang memiliki identitas, bahkan jika nama dan nama keluarga bertepatan dengan sekumpulan nilai lain, seperti jika nama tersebut juga merujuk ke orang yang berbeda.

Objek nilai sulit dikelola dalam database relasional dan ORM seperti Entity Framework (EF), sedangkan dalam database berorientasi dokumen lebih mudah diimplementasikan dan digunakan.

EF Core 2.0 dan versi yang lebih baru menyertakan fitur Entitas Yang Dimiliki yang memudahkan untuk menangani objek nilai, seperti yang akan kita lihat secara rinci nanti.

Sumber daya tambahan

Pola Agregat

Model domain berisi kluster entitas dan proses data yang berbeda yang dapat mengontrol area fungsionalitas yang signifikan, seperti pemenuhan pesanan atau inventarisasi. Unit DDD yang lebih halus adalah agregat, yang menjelaskan kluster atau sekelompok entitas dan perilaku yang dapat diperlakukan sebagai unit kohesif.

Anda biasanya menentukan agregat berdasarkan transaksi yang Anda butuhkan. Contoh klasik adalah pesanan yang juga berisi daftar item pesanan. Item pesanan biasanya merupakan entitas. Namun, entitas tersebut akan menjadi entitas anak dalam agregat pesanan, yang juga akan berisi entitas pesanan sebagai entitas akarnya, biasanya disebut akar agregat.

Mengidentifikasi agregat bisa sulit. Agregat adalah sekelompok objek yang harus konsisten bersama-sama, tetapi Anda tidak bisa hanya memilih sekelompok objek dan memberi label sebagai agregat. Anda harus mulai dengan konsep domain dan memikirkan entitas yang digunakan dalam transaksi paling umum yang terkait dengan konsep tersebut. Entitas yang perlu konsisten secara transaksional adalah apa yang membentuk agregat. Memikirkan operasi transaksi mungkin adalah cara terbaik untuk mengidentifikasi agregat.

Pola Akar Agregat atau Entitas Induk

Agregat terdiri dari setidaknya satu entitas: akar agregat, juga disebut entitas akar atau entitas utama. Selain itu, ia dapat memiliki beberapa entitas anak dan objek nilai, dengan semua entitas dan objek bekerja sama untuk menerapkan perilaku dan transaksi yang diperlukan.

Tujuan akar agregat adalah untuk memastikan konsistensi agregat; ini harus menjadi satu-satunya titik masuk untuk pembaruan pada agregat melalui metode atau operasi di kelas agregat root. Anda harus membuat perubahan pada entitas dalam agregat hanya melalui akar agregat. Ini adalah penjaga konsistensi agregat, mengingat semua aturan invarian dan konsistensi yang mungkin perlu Anda patuhi dalam agregat Anda. Jika Anda mengubah entitas anak atau objek nilai secara independen, akar agregat tidak dapat memastikan bahwa agregat berada dalam status valid. Ini akan seperti meja dengan kaki longgar. Mempertahankan konsistensi adalah tujuan utama akar agregat.

Pada Gambar 7-9, Anda dapat melihat contoh agregat seperti agregat pembeli, yang berisi satu entitas (Pembeli sebagai akar dari agregat). Agregat pesanan berisi beberapa entitas dan objek nilai.

Diagram membandingkan agregat pembeli dan agregat pesanan.

Gambar 7-9. Contoh agregat dengan beberapa atau satu entitas

Model domain DDD terdiri dari agregat, agregat hanya dapat memiliki satu entitas atau lebih, dan juga dapat menyertakan objek nilai. Perhatikan bahwa agregat Pembeli dapat memiliki entitas anak tambahan, tergantung pada domain Anda, seperti dalam layanan mikro pemesanan pada aplikasi referensi eShopOnContainers. Gambar 7-9 hanya menggambarkan kasus di mana pembeli memiliki satu entitas, sebagai contoh agregat yang hanya berisi akar agregat.

Untuk mempertahankan pemisahan agregat dan menjaga batas yang jelas di antara mereka, ini adalah praktik yang baik dalam model domain DDD untuk melarang navigasi langsung antara agregat dan hanya memiliki bidang kunci asing (FK), seperti yang diimplementasikan dalam model domain layanan mikro Pemesanan di eShopOnContainers. Entitas Pesanan hanya memiliki bidang kunci asing untuk pembeli, tetapi bukan properti navigasi EF Core, seperti yang ditunjukkan dalam kode berikut:

public class Order : Entity, IAggregateRoot
{
    private DateTime _orderDate;
    public Address Address { get; private set; }
    private int? _buyerId; // FK pointing to a different aggregate root
    public OrderStatus OrderStatus { get; private set; }
    private readonly List<OrderItem> _orderItems;
    public IReadOnlyCollection<OrderItem> OrderItems => _orderItems;
    // ... Additional code
}

Mengidentifikasi dan bekerja dengan agregat membutuhkan penelitian dan pengalaman. Untuk informasi selengkapnya, lihat daftar Sumber daya tambahan berikut ini.

Sumber daya tambahan

SebelumnyaBerikutnya