Desain Berbasis Domain: Layanan Domain, Layanan Aplikasi


268

Dapatkah seseorang menjelaskan perbedaan antara layanan domain dan aplikasi dengan memberikan beberapa contoh? Dan, jika suatu layanan adalah layanan domain, apakah saya akan menempatkan implementasi sebenarnya dari layanan ini dalam perakitan domain dan jika demikian, apakah saya juga akan menyuntikkan repositori ke dalam layanan domain itu? Beberapa info akan sangat membantu.

Jawaban:


358

Layanan datang dalam 3 rasa: Layanan Domain , Layanan Aplikasi , dan Layanan Infrastruktur .

  • Layanan Domain : Meringkas logika bisnis yang tidak secara alami cocok dengan objek domain, dan BUKAN operasi CRUD khas - itu akan menjadi milik Repositori .
  • Layanan Aplikasi : Digunakan oleh konsumen eksternal untuk berbicara dengan sistem Anda (pikirkan Layanan Web ). Jika konsumen memerlukan akses ke operasi CRUD, mereka akan terekspos di sini.
  • Layanan Infrastruktur : Digunakan untuk meringkas masalah teknis (mis. MSMQ, penyedia email, dll).

Menjaga Layanan Domain bersama dengan Objek Domain Anda masuk akal - mereka semua berfokus pada logika domain. Dan ya, Anda dapat menyuntikkan Gudang ke Layanan Anda.

Layanan Aplikasi biasanya akan menggunakan Layanan Domain dan Gudang untuk menangani permintaan eksternal.

Semoga itu bisa membantu!


2
Di mana Anda akan menempatkan perintah dan pertanyaan oleh CQRS? Layanan mana yang menghasilkannya dan layanan mana yang menanganinya?
inf3rno

5
Saya pikir Layanan Aplikasi harus independen dari rincian teknis seperti "layanan web", mereka digunakan oleh layanan tersebut. Lihat Layanan dalam Desain yang Didorong oleh Domain
deamon

1
@prograhammer - Contoh untuk layanan domain dapat berupa FundsTransferService, di mana model domain adalah BankAccount, transfer dapat memiliki beberapa logika bisnis yang tidak masuk langsung ke objek akun (diambil dari buku Evans DDD).
BornToCode

jadi katakan misalnya Loginuser () akan menjadi contoh layanan domain. dimana getUsers () akan menjadi layanan aplikasi ??
filthy_wizard

Keduanya lebih merupakan layanan aplikasi karena otentikasi dan seringkali juga keputusan otorisasi bukan milik domain inti.
MauganRa

114

(Jika Anda tidak ingin membaca, ada ringkasan di bagian bawah :-)

Saya juga telah berjuang dengan definisi layanan aplikasi yang tepat. Meskipun jawaban Vijay sangat membantu proses berpikir saya sebulan yang lalu, saya menjadi tidak setuju dengan sebagian dari itu.

Sumber daya lainnya

Ada sangat sedikit informasi tentang layanan aplikasi. Subjek seperti akar agregat, repositori, dan layanan domain dibahas secara luas, tetapi layanan aplikasi hanya disebutkan secara singkat atau ditinggalkan sama sekali.

Artikel MSDN Magazine Pengantar Untuk Desain Berbasis Domain menjelaskan layanan aplikasi sebagai cara untuk mengubah dan / atau mengekspos model domain Anda ke klien eksternal, misalnya sebagai layanan WCF. Ini adalah bagaimana Vijay menggambarkan layanan aplikasi juga. Dari sudut pandang ini, layanan aplikasi adalah antarmuka ke domain Anda .

Artikel Jeffrey Palermo tentang Arsitektur Bawang (bagian satu , dua dan tiga ) adalah bacaan yang bagus. Dia memperlakukan layanan aplikasi sebagai konsep tingkat aplikasi , seperti sesi pengguna. Meskipun ini lebih dekat dengan pemahaman saya tentang layanan aplikasi, itu masih tidak sejalan dengan pemikiran saya tentang masalah ini.

Pikiran saya

Saya telah memikirkan layanan aplikasi sebagai dependensi yang disediakan oleh aplikasi . Dalam hal ini aplikasi dapat berupa aplikasi desktop atau layanan WCF.

Domain

Waktu untuk contoh. Anda mulai dengan domain Anda. Semua entitas dan layanan domain apa pun yang tidak bergantung pada sumber daya eksternal diterapkan di sini. Konsep domain apa pun yang bergantung pada sumber daya eksternal ditentukan oleh antarmuka. Berikut ini adalah kemungkinan tata letak solusi (nama proyek dicetak tebal):

Solusi saya
-  My.Product.Core (My.Product.dll)
  - Layanan Domain
      IExchangeRateService
    Produk
    Produkpabrik
    IProductRepository

The Productdan ProductFactorykelas telah dilaksanakan dalam perakitan inti. ItuIProductRepository adalah sesuatu yang mungkin didukung oleh database. Implementasi ini bukan urusan domain dan oleh karena itu didefinisikan oleh antarmuka.

Untuk saat ini, kami akan fokus pada IExchangeRateService. Logika bisnis untuk layanan ini diimplementasikan oleh layanan web eksternal. Namun, konsepnya masih merupakan bagian dari domain dan diwakili oleh antarmuka ini.

Infrastruktur

Implementasi dependensi eksternal adalah bagian dari infrastruktur aplikasi:

Solusi saya
+ My.Product.Core (My.Product.dll)
- Infrastruktur My.Product (My.Product.Infrastructure.dll)
  - Layanan Domain
      XEExchangeRateService
    SqlServerProductRepository

XEExchangeRateServicemengimplementasikan IExchangeRateServicelayanan domain dengan berkomunikasi dengan xe.com . Implementasi ini dapat digunakan oleh aplikasi Anda yang menggunakan model domain Anda, dengan memasukkan perakitan infrastruktur.

Aplikasi

Perhatikan bahwa saya belum menyebutkan layanan aplikasi. Kami akan melihat itu sekarang. Katakanlah kita ingin memberikan IExchangeRateServiceimplementasi yang menggunakan cache untuk pencarian cepat. Garis besar kelas dekorator ini bisa terlihat seperti ini.

public class CachingExchangeRateService : IExchangeRateService
{
    private IExchangeRateService service;
    private ICache cache;

    public CachingExchangeRateService(IExchangeRateService service, ICache cache)
    {
        this.service = service;
        this.cache = cache;
    }

    // Implementation that utilizes the provided service and cache.
}

Perhatikan ICacheparameternya? Konsep ini bukan bagian dari domain kami, jadi ini bukan layanan domain. Ini adalah layanan aplikasi . Ini adalah ketergantungan infrastruktur kami yang mungkin disediakan oleh aplikasi. Mari kita perkenalkan aplikasi yang menunjukkan ini:

Solusi saya
- My.Product.Core (My.Product.dll)
  - Layanan Domain
      IExchangeRateService
    Produk
    Produkpabrik
    IProductRepository
- Infrastruktur My.Product (My.Product.Infrastructure.dll)
  - ApplicationServices
      ICache
  - Layanan Domain
      CachingExchangeRateService
      XEExchangeRateService
    SqlServerProductRepository
- My.Product.WcfService (My.Product.WcfService.dll)
  - ApplicationServices
      MemcachedCache
    IMyWcfService.cs
  + MyWcfService.svc
  + Web.config

Ini semua muncul bersamaan dalam aplikasi seperti ini:

// Set up all the dependencies and register them in the IoC container.
var service = new XEExchangeRateService();
var cache = new MemcachedCache();
var cachingService = new CachingExchangeRateService(service, cache);

ServiceLocator.For<IExchangeRateService>().Use(cachingService);

Ringkasan

Aplikasi lengkap terdiri dari tiga lapisan utama:

  • domain
  • infrastruktur
  • aplikasi

Lapisan domain berisi entitas domain dan layanan domain yang berdiri sendiri. Setiap konsep domain (ini termasuk layanan domain, tetapi juga repositori) yang bergantung pada sumber daya eksternal, ditentukan oleh antarmuka.

Lapisan infrastruktur berisi implementasi antarmuka dari lapisan domain. Implementasi ini dapat memperkenalkan dependensi non-domain baru yang harus disediakan aplikasi. Ini adalah layanan aplikasi dan diwakili oleh antarmuka.

Lapisan aplikasi berisi implementasi layanan aplikasi. Lapisan aplikasi juga dapat berisi implementasi tambahan antarmuka domain, jika implementasi yang disediakan oleh lapisan infrastruktur tidak memadai.

Meskipun perspektif ini mungkin tidak sesuai dengan definisi umum layanan DDD, ia memisahkan domain dari aplikasi dan memungkinkan Anda untuk berbagi perakitan domain (dan infrastruktur) antara beberapa aplikasi.


2
@ dario-g: Anda harus merekonstruksi / mengisi kembali model domain Anda dari model permintaan dan meneruskan model domain ke layanan domain. Pertanyaan ini dapat memberi Anda beberapa ide. Jika tidak, beri tahu saya dan saya akan melihat apakah saya punya waktu untuk menambahkan jawaban ke pertanyaan lain.
Niels van der Rest

1
@Tiendq: Apakah maksud Anda IExchangeRateServiceantarmuka? Ini adalah konsep domain, yaitu sesuatu yang termasuk dalam bahasa di mana-mana pelanggan Anda. Bagian lain dari domain Anda mungkin bergantung pada layanan ini, itulah sebabnya antarmuka dalam didefinisikan di lapisan domain. Tetapi karena implementasinya melibatkan layanan web eksternal, kelas pelaksana berada di lapisan infrastruktur. Dengan cara ini lapisan domain hanya peduli dengan logika bisnis.
Niels van der Rest

4
@Tiendq: Dalam arsitektur berlapis tradisional, infrastruktur biasanya adalah agnostik-domain. Tetapi dalam Arsitektur Bawang (lihat tautan dalam jawaban saya) infrastruktur mengimplementasikan dependensi eksternal domain. Tapi saya tidak akan mengatakan infrastruktur tergantung pada domain, itu hanya referensi saja. Saya telah mengambil istilah 'infrastruktur' dari Arsitektur Bawang, tetapi 'eksternal' mungkin nama yang lebih baik.
Niels van der Rest

1
@ Derek: Salah satu 'hal' itu bisa menjadi ExchangeRatecontoh, yang berisi mata uang dasar, mata uang lawan dan dan nilai tukar antara dua mata uang ini. Nilai-nilai terkait erat ini mewakili konsep 'nilai tukar' dari domain, sehingga ini tinggal di lapisan domain. Meskipun mungkin tampak seperti DTO sederhana, dalam DDD itu disebut Object Value dan itu bisa berisi logika bisnis tambahan untuk membandingkan atau mengubah contoh.
Niels van der Rest

6
Saya tidak setuju dengan bagian di mana Anda tidak setuju dengan Vijay dan inilah alasannya. CachingExchangeRateService adalah masalah infrastruktur. Meskipun Anda secara umum menerima ICache, implementasi untuk ICache itu tergantung pada teknologi yang terlibat (mis. Web, Windows). Hanya karena generiknya tidak menjadikannya layanan aplikasi. Layanan aplikasi adalah API domain Anda. Bagaimana jika Anda ingin mengungkapkan domain Anda kepada orang lain yang menulis aplikasi, apa yang akan mereka gunakan? Layanan Aplikasi, dan mereka mungkin tidak perlu caching sehingga caching impl Anda tidak berguna bagi mereka (mis. Mengapa infrastrukturnya)
Aaron Hawkins

38

Sumber daya terbaik yang membantu saya memahami perbedaan antara Layanan Aplikasi dan Layanan Domain adalah implementasi java dari contoh kargo Eric Evans, ditemukan di sini . Jika Anda tidak memuatnya, Anda dapat memeriksa internal RoutingService (Layanan Domain) dan BookingService, CargoInspectionService (yang merupakan Layanan Aplikasi).

Momen 'aha' saya dipicu oleh dua hal:

  • Membaca deskripsi Layanan di tautan di atas, lebih tepatnya kalimat ini:

    Layanan domain dinyatakan dalam bahasa dan jenis domain yang ada di mana-mana, yaitu argumen metode dan nilai pengembalian adalah kelas domain yang tepat.

  • Membaca posting blog ini , terutama bagian ini:

    Apa yang saya temukan sangat membantu dalam memisahkan apel dari jeruk adalah berpikir dalam hal alur kerja aplikasi. Semua logika mengenai alur kerja aplikasi biasanya berakhir dengan Layanan Aplikasi yang diperhitungkan dalam Lapisan Aplikasi, sedangkan konsep dari domain yang tampaknya tidak sesuai karena objek model akhirnya membentuk satu atau lebih Layanan Domain.


3
Saya setuju, ini persis bagaimana saya mendefinisikan Layanan Aplikasi, dan itu cocok dengan semua situasi yang saya temui sejauh ini. Layanan Domain berurusan dengan segala sesuatu yang berkaitan dengan objek domain, tetapi itu melampaui ruang lingkup entitas tunggal. Mis: BookReferencesService.GetNextAvailableUniqueTrackingNumber (), fokusnya jelas aturan bisnis *. Mengenai Layanan Aplikasi, persis seperti yang Anda gambarkan, sebagian besar waktu saya mulai dengan menempatkan alur kerja bisnis ini ke dalam tindakan pengontrol saya, dan ketika saya perhatikan, saya memperbaiki logika ini di lapisan layanan aplikasi. Kita dapat mengatakan bahwa lapisan ini untuk kasus penggunaan
tobiak777

1
* Dan antarmuka layanan domain tersebut dikonsumsi oleh entitas domain.
tobiak777

32

Layanan domain adalah ekstensi dari domain. Itu harus dilihat hanya dalam konteks domain. Ini bukan tindakan pengguna seperti misalnya menutup akun atau sesuatu. Layanan domain cocok di mana tidak ada negara. Kalau tidak, itu akan menjadi objek domain. Layanan domain melakukan sesuatu yang masuk akal hanya ketika dilakukan dengan kolaborator lain (objek domain atau layanan lain). Dan itu masuk akal adalah tanggung jawab lapisan lain.

Layanan aplikasi adalah lapisan yang menginisialisasi dan mengawasi interaksi antara objek domain dan layanan. Aliran umumnya seperti ini: dapatkan objek domain (atau objek) dari repositori, jalankan tindakan, dan letakkan (kembali) ke sana (atau tidak). Ia dapat melakukan lebih banyak - misalnya ia dapat memeriksa apakah objek domain ada atau tidak dan melemparkan pengecualian yang sesuai. Jadi itu memungkinkan pengguna berinteraksi dengan aplikasi (dan ini mungkin dari mana namanya berasal) - dengan memanipulasi objek dan layanan domain. Layanan aplikasi umumnya harus mewakili semua kemungkinan kasus penggunaan. Mungkin hal terbaik yang dapat Anda lakukan sebelum memikirkan domain adalah membuat antarmuka layanan aplikasi yang akan memberi Anda wawasan yang jauh lebih baik tentang apa yang sebenarnya Anda coba lakukan. Memiliki pengetahuan tersebut memungkinkan Anda untuk fokus pada domain.

Repositori secara umum dapat disuntikkan ke layanan domain tetapi ini skenario yang agak jarang. Itu adalah lapisan aplikasi yang melakukannya sebagian besar waktu.


10
"Layanan domain cocok di mana tidak ada keadaan. Kalau tidak, itu akan menjadi objek domain." membuatnya klik untuk saya. Terima kasih.
Nick

32

Dari Buku Merah (Implementing Domain Driven Design, oleh Vaughn Vernon), ini adalah bagaimana saya memahami konsep-konsep:

Objek domain ( entitas dan objek nilai ) merangkum perilaku yang diperlukan oleh (sub) domain, membuatnya alami, ekspresif, dan dapat dipahami.

Layanan domain merangkum perilaku seperti itu yang tidak sesuai dengan objek domain tunggal . Misalnya, perpustakaan buku meminjamkan Bookke Client(dengan Inventoryperubahan yang sesuai ) mungkin melakukannya dari layanan domain.

Layanan aplikasi menangani aliran kasus penggunaan, termasuk segala kekhawatiran tambahan yang diperlukan di atas domain. Sering mengekspos metode seperti itu melalui API-nya, untuk konsumsi oleh klien eksternal. Untuk membangun contoh kami sebelumnya, layanan aplikasi kami mungkin mengekspos metode LendBookToClient(Guid bookGuid, Guid clientGuid)yang:

  • Mengambil kembali Client.
  • Konfirmasikan izinnya. ( Perhatikan bagaimana kami menjaga model domain kami bebas dari masalah keamanan / manajemen pengguna. Polusi semacam itu dapat menyebabkan banyak masalah. Sebaliknya, kami memenuhi persyaratan teknis ini di sini, dalam layanan aplikasi kami. )
  • Mengambil kembali Book.
  • Memanggil layanan domain (melewati Clientdan Book) untuk menangani logika domain sebenarnya dari meminjamkan buku kepada klien. Misalnya, saya membayangkan bahwa mengonfirmasi ketersediaan buku jelas merupakan bagian dari logika domain.

Layanan aplikasi umumnya harus memiliki aliran yang sangat sederhana. Alur layanan aplikasi yang kompleks sering menunjukkan bahwa logika domain telah bocor dari domain.

Seperti yang dapat Anda lihat, model domain tetap sangat bersih dengan cara ini, dan mudah dipahami dan didiskusikan dengan para pakar domain, karena hanya berisi masalah bisnis aktualnya sendiri. The aliran aplikasi , di sisi lain, adalah juga jauh lebih mudah untuk mengelola, karena lega dari kekhawatiran domain, dan menjadi ringkas, dan mudah.


3
Saya akan mengatakan bahwa layanan aplikasi juga merupakan titik di mana dependensi diselesaikan. Metodenya adalah use case, aliran tunggal, sehingga dapat membuat keputusan berdasarkan informasi tentang implementasi konkret untuk digunakan. Transaksi basis data juga cocok di sini.
Timo

10

Layanan Domain: Metode yang tidak benar-benar pas pada satu entitas atau memerlukan akses ke repositori terdapat dalam layanan domain. Lapisan layanan domain juga dapat berisi logika domain sendiri dan merupakan bagian dari model domain sebagai entitas dan objek nilai.

Layanan Aplikasi: Layanan Aplikasi adalah lapisan tipis yang berada di atas model domain dan mengoordinasikan aktivitas aplikasi. Itu tidak mengandung logika bisnis dan tidak memiliki status entitas apa pun; namun, ia dapat menyimpan status transaksi alur kerja bisnis. Anda menggunakan layanan Aplikasi untuk menyediakan API ke dalam model domain menggunakan pola pesan Permintaan-Jawab.

Millett, C (2010). Pola Desain ASP.NET Profesional. Penerbitan Wiley. 92.


7

Layanan Domain : Layanan yang mengekspresikan logika bisnis yang bukan bagian dari Agregat Root.

  • Anda memiliki 2 Agregat:

    • Product yang berisi nama dan harga.
    • Purchase yang berisi tanggal pembelian, daftar produk yang dipesan dengan jumlah dan harga produk pada waktu itu, dan metode pembayaran.
  • Checkout bukan bagian dari kedua model ini dan merupakan konsep dalam bisnis Anda.

  • Checkoutdapat dibuat sebagai Layanan Domain yang mengambil semua produk dan menghitung harga total, membayar total dengan memanggil Layanan Domain lain PaymentServicedengan bagian implementasi Infrastruktur, dan mengubahnya menjadi Purchase.

Layanan Aplikasi : Layanan yang "mengatur" atau menggunakan metode Domain. Ini bisa sesederhana hanya Kontroler Anda.

Ini adalah tempat di mana Anda biasanya melakukan:

public String createProduct(...some attributes) {
  if (productRepo.getByName(name) != null) {
    throw new Exception();
  }

  productId = productRepository.nextIdentity();

  product = new Product(productId, ...some attributes);

  productRepository.save(product);

  return productId.value();
  // or Product itself
  // or just void if you dont care about result
}

public void renameProduct(productId, newName) {
  product = productRepo.getById(productId);

  product.rename(newName);

  productRepo.save(product);
}

Anda dapat melakukan validasi di sini seperti memeriksa apakah a Productunik. Kecuali jika Productmakhluk unik adalah invarian, maka itu harus menjadi bagian dari Layanan Domain yang dapat dipanggil UniqueProductCheckerkarena tidak dapat menjadi bagian dari Productkelas dan berinteraksi dengan beberapa Agregat.

Berikut ini adalah contoh lengkap dari proyek DDD: https://github.com/VaughnVernon/IDDD_Samples

Anda dapat menemukan banyak contoh Layanan Aplikasi dan beberapa Layanan Domain


Apakah wajib memvalidasi dan menyimpan entitas hanya di Layanan Aplikasi? Jika saya memiliki entitas A, B dan C dan semuanya terkait satu sama lain (A -> B -> C) dan operasi pada A harus menyebabkan perubahan pada B dan C dengan memanggil satu Layanan Domain dari yang lain, bagaimana cara melakukannya?
MrNVK

> Apakah wajib memvalidasi dan menyimpan entitas hanya di Layanan Aplikasi? Jika harus, maka ya. Sebagian besar waktu Anda harus memeriksa apakah ID ada karena jika tidak Anda akan bekerja pada variabel nol.
notnotmatter

1
> Jika saya memiliki entitas A, B, dan C dan semuanya terkait satu sama lain (A -> B -> C) dan pengoperasian pada A harus menyebabkan perubahan pada B dan C dengan memanggil satu Layanan Domain dari yang lain, bagaimana melakukannya ? Saya tidak yakin apa yang Anda maksud dengan "memanggil satu Layanan Domain dari yang lain", tetapi untuk reaksi terhadap perubahan Entitas, Anda dapat menggunakan Acara atau hanya mengaturnya dengan layanan Aplikasi seperti: aggregateA.doOperation (), aggregateB.doAnother ( ). Cari: Orkestra vs Koreografi
notnotmatter

Terima kasih untuk balasannya! "Memanggil satu Layanan Domain dari yang lain" - Maksud saya, jika saya memiliki operasi yang kompleks pada entitas A, maka saya harus menggunakan ADomainService. Tetapi operasi ini, selain entitas A, mempengaruhi entitas B. Operasi yang harus dilakukan pada entitas B di ADomainService juga kompleks. Jadi saya harus menggunakan BDomainService dari ADomainService. Sekarang saya meragukan pendekatan ini :) Tetapi jika saya menempatkan logika ini di ApplicationService, tidak akan merusak enkapsulasi proses bisnis yang seharusnya hanya di lapisan domain, bukan di lapisan aplikasi?
MrNVK

Anda bisa memancarkan acara dari Layanan Domain Anda jika Anda pikir itu harus dalam Layanan Domain, bukan Layanan Aplikasi.
notnotmatter

1

Pikirkan Layanan Domain sebagai objek yang mengimplementasikan logika bisnis atau logika terkait aturan bisnis pada objek domain dan logika ini sulit masuk ke dalam objek domain yang sama dan juga tidak menyebabkan perubahan status layanan domain (layanan domain adalah objek tanpa "negara" atau lebih baik tanpa negara yang memiliki arti bisnis) tetapi akhirnya hanya mengubah negara dari objek domain yang beroperasi.

Sementara Layanan Aplikasi mengimplementasikan logika level aplikatif sebagai interaksi pengguna, validasi input, logika tidak terkait dengan bisnis tetapi untuk masalah lain: otentikasi, keamanan, email, dan sebagainya .., membatasi dirinya untuk hanya menggunakan layanan yang diekspos oleh objek domain.

Contohnya adalah skenario berikut yang dipikirkan hanya untuk menjelaskan: kita harus menerapkan aplikasi utilitas domotik yang sangat kecil yang menjalankan operasi sederhana, yaitu "nyalakan lampu, ketika seseorang membuka pintu kamar rumah untuk masuk masuk dan matikan lampu ketika menutup pintu yang keluar dari ruangan ".

Menyederhanakan banyak, kami hanya mempertimbangkan 2 entitas domain: Doordan Lamp, masing-masing dari mereka memiliki 2 status, penuh hormat open/closeddan on/off, dan metode khusus untuk mengoperasikan perubahan status pada mereka.

Dalam hal ini kita memerlukan layanan domain yang menjalankan operasi khusus menyalakan lampu ketika seseorang membuka pintu dari luar untuk masuk ke ruangan, karena pintu dan objek lampu tidak dapat mengimplementasikan logika ini dengan cara yang kami anggap cocok dengan sifat mereka .

Kami dapat memanggil layanan domain kami sebagai DomoticDomainServicedan menerapkan 2 metode: OpenTheDoorAndTurnOnTheLightdan CloseTheDoorAndTurnOffTheLight, 2 metode ini dengan hormat mengubah keadaan kedua objek Doordan Lampmenjadi open/ondan closed/off.

Keadaan masuk atau keluar dari ruangan yang tidak ada di objek layanan domain dan baik di objek domain, tetapi akan diimplementasikan sebagai interaksi pengguna sederhana dengan layanan aplikasi, yang dapat kita panggil HouseService, yang mengimplementasikan beberapa event handler sebagai onOpenRoom1DoorToEnterdan onCloseRoom1DoorToExit, dan seterusnya untuk setiap kamar (ini hanya sebuah contoh untuk menjelaskan tujuan ..) , yang masing-masing akan memperhatikan tentang metode layanan panggilan domain untuk mengeksekusi perilaku yang dihadiri (kami belum mempertimbangkan entitas Roomkarena hanya merupakan contoh) .

Contoh ini, yang jauh untuk menjadi aplikasi dunia nyata yang dirancang dengan baik, memiliki satu-satunya tujuan (seperti yang lebih sering dikatakan) untuk menjelaskan apa itu Layanan Domain dan perbedaannya dari Layanan Aplikasi, harap jelas dan bermanfaat.


Ciro: Contoh Anda tidak praktis dan sangat membingungkan.
Morteza Azizi

Hai Morteza, bisakah Anda lebih spesifik? Risiko Anda hanya menjadi "penghakiman" tanpa argumen nyata. Terima kasih
Ciro Corvino
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.