Mengomunikasikan antar lapisan dalam DDD

Membaca literatur DDD saya datang dengan lapisan berikut:

• Application Dunia Orang Luar (Pengendali, Crons, dll)
• Application Services(atau UseCases) - yang mengatur beberapa Layanan Domain atau Layanan Infrastruktur. Mereka dipanggil dari Outside World. Mereka tahu apa yang harus dilakukan
• Domain Services - yang berisi bagaimana hal-hal dilakukan (mengandalkan antarmuka repositori)

Pertanyaan : Apakah ada praktik terbaik bagaimana berkomunikasi antar lapisan?

Yang saya tahu: - Application servicesharus mengembalikan "data yang diinginkan" untuk diekspos dan beberapa "keberhasilan" transaksi (peringatan, kesalahan, info) - Data yang Application Servicedikembalikan, harus dikumpulkan dari Domain Servicesdan / atau dikumpulkan untuk dikumpulkan Infrastructure Services.

Controller <-> Application Service <-> Domain Service          
                                   <-> Infrastructure Service

Ini adalah beberapa pemikiran ambigu saya:

• Haruskah semua metode di Application Servicememiliki DTO spesifik yang berisi "permintaan" sebagai parameter? Seperti AddItemToCardCommandDto(yang merangkum semua data yang dibutuhkan). Bagaimana dengan generik ResultObjectyang hanya memiliki beberapa metode seperti getResultdan hasErrorrsatau getMessages?

• Bagaimana seharusnya mengembalikan DomainServicedata dan kesalahan? Haruskah mereka mengembalikan kesalahan dengan pengecualian? Tampaknya aneh karena bagi saya Bussines Validation harus dipanggil DomainServiceskarena mereka adalah bagian dari aturan bisnis.

Saya akan mengatakan memiliki DTO akan mencairkan desain Model. Kita bisa lolos dengan tidak menggunakan DTO dengan refactoring Model kita dan merancang API kita untuk menggunakan objek model refactored.

Jawaban atas pertanyaan 1: Layanan aplikasi dapat memiliki metode dengan tanda tangan

void addItemToCard(Item item, Card card);

Metode dapat memiliki tipe kembali atau tidak, berdasarkan pada jenis operasi yang ingin kita lakukan dan data yang ingin kita transfer lintas lapisan. Anda perlu memastikan bahwa setiap lapisan memiliki antarmuka yang ditentukan dan lapisan yang berbeda berbicara satu sama lain melalui antarmuka itu untuk semua komponen dalam aplikasi.

Misalnya:

List<Items> getItemsOnCard(String cardID);
//returns list of items or empty list if no item can be found.

List<Offers> getOffersApplicableOnCardForItem()
//should return list of Offers or empty list if no item can be found. Should not return a null if no items can be found

Memastikan bahwa semua metode mematuhi perilaku yang sama lebih penting dalam menjaga antarmuka tetap utuh.

Jawab pertanyaan 2:

Saya pikir DDD merekomendasikan memiliki 3 layer jika saya mengingatnya dengan benar. Memiliki kecerdasan domain di lapisan aplikasi membantu dan menandakan bahwa aplikasi Anda terikat ke domain dan memiliki konteks terbatas. Anda dapat menambahkan lapisan tambahan jika Anda merasa 3 tidak cukup. Pengecualian dapat digunakan untuk membuat informasi lintas lapisan. Data dapat dimuat di dalam placeholder pengecualian khusus untuk bisnis.

Saya harap ini menjawab beberapa pertanyaan yang Anda miliki.