LECTURE NOTES

Pattern Software Design

Minggu 1
Sesi 3

The Principles and Practices of

Domain‐Driven Design

COMP6299 - Pattern Software Design

 LEARNING OUTCOMES

LO 1: Menjelaskan dan mengidentifikasi konsep pola Desain

LO 2: Menjelaskan permasalahan yang harus dipecahkan.
LO 3: Menjelaskan permasalahan bisnis dalam domain

OUTLINE MATERI (Sub-Topic):

• Apa Desain Berbasis Domain?

• Desain Berbasis Model
• Pola Implementasi Model Domain
• Pemetaan Konteks
• Arsitektur Aplikasi
• Menerapkan Prinsip, Praktek, dan Pola DDD.

COMP6299 - Pattern Software Design

 ISI MATERI

1. Apa Desain Berbasis Domain?

Desain Domain-Driven (DDD) adalah filosofi pengembangan yang
didefinisikan oleh Eric Evans
DDD adalah pendekatan untuk pengembangan perangkat lunak yang
memungkinkan tim untuk secara efektif mengelola konstruksi dan
pemeliharaan perangkat lunak untuk domain masalah yang kompleks.
a. Kompleksitas dalam perangkat lunak

Scott Millett. (2015

DDD mempunyai tantangan dalam memahami domain masalah dan

menciptakan solusi yang dapat dipelihara yang berguna untuk
memecahkan masalah di dalamnya. Solusi ini dapat tercapat dengan
memanfaatkan sejumlah pola strategis dan taktis.
Pola Strategis DDD
• Penyaringan Domain Masalah untuk Mengungkap Apa yang
Penting
• Membuat Model untuk Memecahkan Masalah Domain
• Menggunakan Bahasa Bersama untuk Mengaktifkan Kolaborasi
Pemodelan
• Mengisolasi Model dari Ambiguitas dan Korupsi
• Memahami Hubungan antara Konteks

b. Pola Taktik DDD

• Pola taktis DDD, juga dikenal sebagai blok bangunan model, adalah
kumpulan pola yang membantu menciptakan model yang efektif
untuk konteks terbatas kompleks.

COMP6299 - Pattern Software Design

 • pola tidak berlaku untuk semua model, dan masing-masing harus
diambil sesuai kemampuannya sendiri dengan gaya arsitektur yang
benar.

2. Desain Berbasis Model

a. APA ITU Domain MODEL?
• Ini dibentuk pertama sebagai model analisis melalui kolaborasi antara tim
pengembangan dan pakar bisnis selama sesi pengetatan pengetahuan
• Model hanya berisi apa yang relevan untuk menyelesaikan masalah dalam
konteks aplikasi yang sedang dibuat. Perlu terus berkembang dengan bisnis
agar tetap berguna dan valid

b. Domain versus Domain Model

• Domain mewakili area masalah yang sedang Anda tangani. Ini adalah
kenyataan yang pasti dari situasi ini.
• Model domain adalah abstraksi dari domain masalah, dinyatakan sebagai
implementasi kode yang mewakili pandangan, bukan realitas, dari masalah

c. Model Driven Design

adalah proses mengikat model analisis ke model implementasi kode,
memastikan bahwa keduanya tetap sinkron dan berguna selama evolusi.

pendekatan memungkinkan pengetahuan domain dan bahasa bersama untuk

dimasukkan ke dalam model perangkat lunak yang mencerminkan model bahasa
dan mental para pakar bisnis
d. CARA MENCIPTAKAN MODEL DOMAIN YANG EFEKTIF
Model domain dibuat untuk memenuhi masalah yang rumit, cara terbaik untuk
membuat model domain yang efektif adalah dengan

• pertama-tama fokus pada bidang aplikasi yang penting bagi bisnis

COMP6299 - Pattern Software Design

 • Abaikan bagian-bagian dari sistem yang hanya mengelola data dan di
mana sebagian besar operasi berbasis CRUD
e. Kapan Menerapkan Model Driven Design
• Masalah sederhana tidak membutuhkan solusi yang rumit. Anda tidak perlu
membuat UL untuk seluruh aplikasi Anda. Fokuskan upaya Anda dengan
pakar domain pada domain inti yang kompleks atau penting. Untuk domain
umum / pendukung, jangan sia-siakan upaya Anda, secara epik jika tidak
ada logika domain; hal itu akan membuat frustasi pakar domain Anda yang
sibuk dan membuat mereka enggan untuk membantu dengan area aplikasi
Anda yang kompleks.
• Ketika Anda menemukan area kompleksitas, Anda mengalami kesulitan
berkomunikasi dengan pemangku kepentingan, atau tim Anda bekerja di
bagian dari domain yang tidak memiliki banyak pengalaman dengan Anda,
inilah saatnya untuk keluar, membuat model, dan bekerja di UL.
• Selalu tantang diri Anda dan ajukan pertanyaan, “Apakah saya bekerja di
dalam subdomain inti? Apakah masalah ini memerlukan domain yang
kaya? Apakah bisnis peduli dengan bidang aplikasi ini? Apakah itu akan
membuat perbedaan? Apakah ini penting bagi bisnis dan apakah mereka
memiliki harapan yang tinggi terhadapnya atau mereka hanya ingin itu
berhasil? ”

3. Pola Implementasi Domain model

Ada berbagai pola yang Anda inginkan untuk menerapkan model domain dalam
kode. Sistem besar tidak semuanya dibangun dengan cara yang sama. Beberapa
bagian kurang penting daripada yang lain, dan ada banyak model untuk melayani
konteks yang berbeda.

COMP6299 - Pattern Software Design

 Beberapa model domain diimplementasikan dalam berbagai pola di dalam suatu
aplikasi. ((Scott Millett. (2015)).
a. Model domain
model domain adalah model berorientasi objek yang menggabungkan perilaku
dan data.
• Pada pandangan pertama, ini mungkin mencerminkan model data
persistence (skema data jika Anda menggunakan database relasional).
• model domain juga menggabungkan proses bisnis dan asosiasi, aturan, dan
logika domain kaya.

b. Pola model domain

Pola model domain didasarkan pada premis bahwa tidak ada database
Saat merancang model, Anda tidak memulai dengan model data; alih-alih, Anda
mulai dengan model kode — model yang didorong sebagai lawan dari desain
yang didorong data

Pola model domain ((Scott Millett. (2015)).

COMP6299 - Pattern Software Design

 Model domain dari situs lelang. (Scott Millett. (2015))
c. Skrip Transaksi

Pola skrip transaksi mengikuti gaya pengembangan prosedural daripada

pendekatan berorientasi objek.
prosedur tunggal dibuat untuk setiap transaksi bisnis Anda, dan dikelompokkan
dalam beberapa jenis manajer statis atau kelas layanan

Setiap prosedur berisi semua logika bisnis yang diperlukan untuk menyelesaikan
transaksi bisnis dari alur kerja, aturan bisnis, dan pemeriksaan validasi hingga
kegigihan dalam database.

Pola skrip transaksi. (Scott Millett. (2015))

COMP6299 - Pattern Software Design

 Pola skrip transaksi UML. (Scott Millett. (2015))

d. Tabel Modul
• Pola modul tabel memetakan model objek ke model database.
• Objek tunggal mewakili tabel atau tampilan dalam database.
• Objek bertanggung jawab untuk semua kebutuhan bersama dengan
perilaku logika bisnis.
• Manfaat dari pola ini adalah bahwa tidak ada ketidaksesuaian antara model
objek dan model database

e. Record Aktif
• Record aktif adalah variasi dari pola modul tabel yang memetakan objek ke
baris tabel sebagai lawan memiliki objek yang mewakili tabel itu sendiri.
Objek mewakili baris database (catatan) dalam keadaan sementara atau
dalam modifikasi.
• Pola record aktif adalah pola populer yang sangat efektif ketika model basis
data Anda yang cocok dengan model bisnis Anda.
• Setiap objek bisnis bertanggung jawab atas kegigihannya sendiri dan logika
bisnis terkait.
• Memiliki pemetaan satu-ke-satu antara model data dan model bisnis, seperti
dengan blog atau mesin forum

f. Model Domain Anemik

• Model domain anemik kadang-kadang disebut sebagai anti pola. Pada
pandangan pertama, polanya sangat mirip dengan model domain di mana
Anda masih akan menemukan objek domain yang mewakili domain bisnis.
Namun, perilaku apa pun tidak terdapat dalam objek domain. Sebaliknya,
itu ditemukan di luar model, meninggalkan objek domain sebagai kelas
transfer data sederhana.
• Kerugian utama dari pola ini adalah bahwa layanan domain mengambil
peran gaya kode yang lebih prosedural daripada pola skrip transaksi

COMP6299 - Pattern Software Design

 • kandidat yang baik untuk bagian-bagian dari model domain Anda yang
memiliki sedikit logika atau untuk tim yang tidak terlalu berpengalaman
dengan teknik pemrograman berorientasi objek

4. Pemetaan Konteks
Merupakan artefak penting; tanggung jawabnya adalah untuk memastikan bahwa
batas-batas antara berbagai konteks sistem didefinisikan secara eksplisit dan bahwa
setiap tim memahami titik kontak di antara mereka.
bukan dokumen yang sangat terperinci yang dibuat dalam beberapa jenis alat
arsitektur perusahaan, ini adalah diagram tingkat tinggi yang digambar tangan yang
mengomunikasikan gambaran holistik dari konteks yang sedang dimainkan.

Peta Konteks (Scott Millett. (2015))

a. Realitas Teknis

Sangatlah penting bahwa peta konteks mencerminkan realitas, menunjukkan

kode dalam keadaan saat ini daripada keadaan masa depan yang ideal. Peta
konteks tidak perlu menunjukkan detail model; sebaliknya, mereka harus
menunjukkan titik integrasi dan aliran data antara konteks yang dibatasi.
Seperti model kode dan model analisis, peta konteks harus berubah hanya
ketika kode berubah sehingga tidak memberikan kesan lanskap yang salah.
Peta harus menunjukkan kenyataan yang nyata; hanya dengan demikian akan
bermanfaat.

COMP6299 - Pattern Software Design

 Integrasi teknis pada peta konteks (Scott Millett. (2015)).

b. Realitas Organisasi
Perubahan pada proses bisnis atau penciptaan aliran kerja baru seringkali dapat
menjangkau banyak konteks yang terbatas dan menjangkau berbagai bagian
domain. Mengkoordinasikan perubahan pada skala ini seringkali membutuhkan
sebanyak mungkin manajemen tim seperti halnya perubahan teknis. Sangat
penting untuk memahami siapa yang bertanggung jawab untuk setiap konteks
yang diperlukan untuk berubah dan bagaimana perubahan ini akan terjadi. Jika
proses koordinasi dan memprioritaskan perubahan tidak dipahami, itu bisa
menjadi batu sandungan besar dan menghambat pengembangan saat tim
menunggu orang lain untuk bertindak atas permintaan perubahan.

Hubungan organisasi pada peta konteks (Scott Millett. (2015)).

COMP6299 - Pattern Software Design

c. Memetakan Realitas yang Relevan
Saat membuat peta konteks:
• cobalah untuk fokus pada bidang masalah langsung Anda; Anda perlu
memahami lanskap yang akan memengaruhi keberhasilan proyek Anda dan
bukan keseluruhan perusahaan
• fokus hanya pada konteks yang akan Anda integrasikan secara langsung
membantu Anda dalam memetakan konteks dan mencegah Anda
kehilangan fokus.
• Menandai domain inti pada peta dan menemukan hubungan antara itu dan
konteks lainnya dapat memberikan wawasan tentang kejelasannya dalam
konteks lanskap perusahaan.

d. Lapisan Anti Korupsi

Jika Anda membuat model untuk sub sistem yang berkomunikasi dengan sub
sistem lainnya sebagai bagian dari sistem yang lebih besar, Anda mungkin perlu
berinteraksi dengan model yang dibuat oleh tim yang berbeda. Model-model
lain, meskipun dibuat untuk domain yang sama, dapat diekspresikan dengan
bahasa di mana-mana yang berbeda dan dimodelkan dengan cara yang sama
sekali berbeda dengan bahasa Anda. Jika Anda tidak hati-hati mengintegrasikan
dengan model-model ini, beradaptasi dengan antarmuka mereka dapat
menyebabkan kerusakan model Anda.
Untuk menghindari korupsi dan melindungi model Anda dari pengaruh eksternal,
Anda dapat membuat lapisan isolasi yang berisi antarmuka yang ditulis sesuai
model Anda. Antarmuka mengadaptasi dan menerjemahkan ke antarmuka
konteks lain. Lapisan isolasi ini dikenal sebagai lapisan antikorupsi.

Gunakan lapisan anti korupsi untuk berintegrasi dengan kode yang tidak Anda
miliki atau tidak dapat diubah (Scott Millett. (2015)).

COMP6299 - Pattern Software Design

e. Berbagi Kernel
Jika dua tim bekerja sama secara erat dalam aplikasi yang sama, pada dua
konteks terikat yang terpisah yang memiliki banyak crossover dalam hal konsep
dan logika domain, biaya tambahan untuk menjaga tim tetap terisolasi dan
menggunakan peta terjemahan untuk menerjemahkan dari satu konteks ke
konteks lainnya dapat menjadi terlalu banyak. Dalam hal ini, mungkin lebih baik
berkolaborasi dan berbagi bagian dari model untuk memudahkan integrasi.
Model bersama ini dikenal sebagai kernel bersama. Pola ini digunakan secara
khusus jika Anda memiliki dua konteks terikat di subdomain yang sama yang
berbagi subset logika domain.

Integrasi dengan kernel bersama (Scott Millett. (2015)).

f. Layanan Host Terbuka

sistem atau komponen lain yang berkomunikasi dengan Anda akan
menggunakan beberapa jenis lapisan transformasi untuk menerjemahkan model
Anda ke dalam bentuk mereka sendiri, mirip dengan lapisan antikorupsi.
Jika banyak konsumen menggunakan logika transformasi yang sama, akan lebih
bermanfaat untuk menyediakan serangkaian layanan yang mengekspos
fungsionalitas konteks melalui kontrak eksplisit yang didefinisikan dengan jelas
yang dikenal sebagai layanan host terbuka.

COMP6299 - Pattern Software Design

Beberapa subsistem terintegrasi dengan upaya transformasi serupa (Scott Millett.
(2015)).

Integrasi dengan layanan host terbuka. (Scott Millett. (2015)).

g. Komunikasi Peta Konteks

Saat menyusun peta konteks Anda, Anda dapat menambahkan jenis hubungan
organisasi yang ada serta jenis integrasi teknis antara dua konteks terikat pada
baris yang menyatukannya. Anda juga dapat menunjukkan sisi mana dari garis
yang hulu dan mana yang hilir menggunakan huruf atau simbol, jika ada.

COMP6299 - Pattern Software Design

 Peta konteks yang menunjukkan jenis integrasi antara konteks terbatas (Scott
Millett. (2015)).

h. Pentingnya Strategis Peta Konteks

komunikasi antara konteks terikat, baik teknis dan organisasi, lebih penting bagi
tim yang memulai proyek daripada konteks terikat itu sendiri. Informasi yang
diberikan oleh peta konteks dapat memungkinkan tim untuk membuat
keputusan strategis penting yang meningkatkan keberhasilan suatu proyek. Peta
konteks adalah artefak kuat yang dapat mempercepat anggota tim baru dengan
cepat dan memberikan peringatan dini untuk potensi titik bahaya. Peta konteks
juga dapat mengungkapkan masalah dengan komunikasi dan alur kerja dalam
bisnis.
• Mempertahankan Integritas
Mempertahankan integritas penting untuk menjaga basis kode Anda fokus
pada model tunggal. Ini memungkinkan kode untuk menjadi luwes karena
perubahan apa pun hanya memengaruhi konteks terikat tunggal dan tidak
memiliki efek beriak di beberapa area domain Anda. Kelembutan inilah yang
memungkinkan Anda mengubah kode dan beradaptasi dengan cepat dan
percaya diri ketika bisnis membutuhkan perubahan proses atau logika.
• Dasar untuk Rencana Serangan
Peta konteks menyoroti bidang kebingungan dan kekacauan, dan, yang
lebih penting, di mana domain inti berada. Tim dapat menggunakan
informasi ini untuk mengidentifikasi bidang-bidang yang perlu mereka
jelaskan terlebih dahulu untuk meningkatkan keberhasilan suatu proyek:
o Area yang terlalu jauh dan di mana upaya untuk meningkatkan jauh
lebih besar daripada pengembaliannya dapat diisolasi dan ditinggalkan.
o Area yang tidak memiliki keunggulan strategis atau yang memiliki
kompleksitas rendah tidak perlu mengeluarkan biaya untuk
menciptakan bahasa di mana-mana atau mengikuti metodologi
pengembangan yang digerakkan oleh model.
o Area yang merupakan inti dari kesuksesan proyek atau kompleks
adalah kandidat untuk sisi taktis Desain Domain-Driven, dan harus

COMP6299 - Pattern Software Design

 tetap terisolasi dari konteks terbatas yang dirancang dengan buruk
untuk mempertahankan integritas.
• Memahami Kepemilikan dan Tanggung Jawab
Akuntabilitas dan tanggung jawab adalah bidang nonteknis lain yang dapat
memengaruhi suatu proyek. Menentukan kepemilikan dan manajemen tim
untuk subsistem yang perlu Anda integrasikan sangat penting untuk
memastikan perubahan dilakukan tepat waktu dan sesuai dengan apa yang
Anda harapkan. Pemetaan konteks adalah tentang investigasi dan klarifikasi;
Anda mungkin tidak dapat langsung menggambar peta konteks yang jelas,
tetapi proses klarifikasi tanggung jawab, secara eksplisit mendefinisikan
garis kabur, dan memahami aliran komunikasi sementara memetakan
konteks sama pentingnya dengan artefak yang sudah selesai.
• Mengungkap Area Kebingungan dalam Alur Kerja Bisnis
Proses bisnis yang terjadi di antara dan mengambil keuntungan dari konteks
terbatas sering ditinggalkan di tanah tanpa-manusia tanpa tanggung jawab
dan kejelasan yang jelas mengenai batasan dan metode integrasi mereka.
Peta konteks, fokus pada aspek nonteknis hubungan, dapat
mengungkapkan aliran proses bisnis yang rusak dan komunikasi antara
sistem dan kemampuan bisnis yang telah menurun seiring waktu.
Pengungkapan ini seringkali lebih bermanfaat bagi bisnis yang dapat lebih
memahami dan meningkatkan proses yang mencakup seluruh departemen
dan kemampuan. Wawasan dapat digunakan untuk mengurangi risiko
kegagalan proyek dengan mengatasi ambiguitas sejak dini dan mengajukan
pertanyaan-pertanyaan kuat yang membantu kesuksesan proyek.
• Mengidentifikasi Hambatan Nonteknis
Peta konteks mengungkapkan batas-batas departemen yang terlibat dalam
suatu proyek. Jika tim Anda tidak memiliki semua konteks dalam permainan,
koordinasi dengan tim lain dan jalur manajemen dan prioritas lainnya perlu
dilakukan. Memahami hambatan-hambatan ini di muka memberi Anda
kemungkinan keberhasilan yang lebih besar pada suatu proyek dan
memungkinkan Anda untuk mengatasi masalah nonteknis seperti
penjadwalan rilis sebelum mereka menjadi pemblokir.
• Mendorong Komunikasi yang Baik
Ketika diagram menunjukkan kepada Anda bahwa ada hubungan antara
konteks terikat Anda dan konteks terikat lainnya, Anda harus memiliki ide
yang cukup bagus bahwa Anda perlu berkomunikasi dengan tim yang
bertanggung jawab untuknya. Ketika diagram juga menunjukkan bahwa
Anda adalah tim hulu, Anda memahami bahwa tanggung jawab Anda
biasanya untuk memimpin pengambilan keputusan, dan karenanya, Anda
mungkin sering perlu memulai komunikasi.

• Membantu Pemula Baru On-Board

peta konteks yang dilihat dan terus diperbarui oleh seluruh tim secara
teratur adalah cara yang fantastis untuk memastikan semua anggota tim

COMP6299 - Pattern Software Design

 memahami gambaran yang lebih besar — atau setidaknya memiliki gagasan
tentang bagian sistem mana yang tidak cukup mereka ketahui. Jika pakar
domain mendekati Anda dengan masalah yang tidak Anda kenal, Anda dapat
membuka peta konteks untuk saran tentang siapa yang sebaiknya diajak
bicara.

5. Arsitektur Aplikasi
Mengembangkan perangkat lunak sambil mengikuti prinsip-prinsip DDD tidak
mengharuskan Anda untuk menggunakan gaya arsitektur aplikasi tertentu. Tetapi
satu hal yang harus didukung arsitektur Anda adalah isolasi logika domain Anda.
a. Lapisan Arsitektur

Ketergantungan inversi dalam arsitektur berlapis (Scott Millett. (2015)).

inti dari arsitektur adalah lapisan domain yang berisi semua logika yang
berkaitan dengan bisnis. Mengelilingi lapisan domain adalah lapisan aplikasi
yang mengabstraksi perincian tingkat rendah dari domain di belakang
antarmuka pemrograman aplikasi berbutir kasar (API) yang mewakili kasus
penggunaan bisnis aplikasi. Logika domain dan lapisan aplikasi terisolasi dan
dilindungi dari kerumitan yang tidak disengaja dari setiap klien, kerangka
kerja, dan masalah infrastruktur.
b. Lapisan
• Lapisan Domain
Lapisan domain yang berisi model abstrak tidak bergantung pada hal lain
dan bersifat agnostik terhadap teknis klien yang dilayaninya dan
penyimpanan data yang bertahan pada objek domain.
• Lapisan Layanan Aplikasi
mewakili kasus penggunaan dan perilaku aplikasi.
• Lapisan Infrastruktur
suatu aplikasi adalah rincian teknis yang memungkinkannya berfungsi.
• Lapisan Lintas Komunikasi

COMP6299 - Pattern Software Design

 untuk berkomunikasi lintas lapisan, untuk mencegah pengungkapan detail
model domain ke dunia luar.
Arsitektur Aplikasi versus Arsitektur untuk Konteks Terbatas

Konteks terikat mengintegrasikan melalui lapisan aplikasi terpisah. (Scott Millett. (2015))

6. Menerapkan Prinsip, Praktek, dan Pola DDD.

Desain Berbasis Domain (DDD)
• sebuah filosofi yang lahir dari kebutuhan untuk menyelaraskan kembali fokus
tim pengembangan menulis perangkat lunak untuk domain kompleks
• Ini bukan kerangka kerja atau serangkaian templat yang telah ditentukan yang
dapat Anda terapkan pada suatu proyek
• menekankan nilai dalam kolaborasi, eksplorasi, dan pembelajaran antara tim
bisnis dan pengembangan untuk menghasilkan perangkat lunak yang berguna
dan relevan
• DDD menyajikan pilihan pola taktis untuk membantu dengan Model-Driven
Design dan untuk membantu dalam pembuatan model domain.
• Fokus pada pola pengkodean taktis DDD menyoroti masalah yang lebih besar:
orang teknis yang hanya fokus pada pola teknis dan kode penulisan
• DDD adalah tentang menemukan apa yang perlu Anda tulis, mengapa Anda
perlu menulisnya, dan berapa banyak usaha yang harus Anda gunakan.

Agar efektif di DDD, Anda perlu yang berikut:

• Prinsip desain yang solid diperlukan untuk refactoring
• Desain yang tajam
• Tim yang fokus, termotivasi, dan berpengalaman

COMP6299 - Pattern Software Design

 SIMPULAN
• Domain Driven Design (DDD) adalah filosofi pengembangan yang dirancang
untuk mengelola pembuatan dan pemeliharaan perangkat lunak yang ditulis
untuk domain masalah yang kompleks.
• DDD adalah kumpulan pola, prinsip, dan praktik, yang dapat diterapkan pada
desain perangkat lunak untuk mengelola kompleksitas.
• Domain adalah realitas masalahnya. Model domain adalah serangkaian
abstraksi berdasarkan proyeksi domain yang dirancang untuk menangani kasus
penggunaan bisnis tertentu. Model direpresentasikan sebagai model analisis
dan model kode. Mereka satu dan sama.
• Lapisan domain berisi model domain dan terisolasi dari masalah infrastruktur
dan presentasi.
• Mengidentifikasi dan menciptakan konteks terbatas adalah salah satu aspek
terpenting dari Desain Berbasis Domain.
• Peta konteks mencerminkan keadaan saat ini. Ini memberikan pandangan
holistik tentang metode integrasi teknis dan hubungan antara konteks yang
dibatasi. Tanpa mereka, model dapat dikompromikan, dan konteks yang
terbatas dapat dengan cepat berubah menjadi bola lumpur ketika integrasi
mengaburkan batas-batas penerapan model.
• Pisahkan masalah aplikasi Anda, dan pisahkan kompleksitas bisnis dari
kompleksitas teknis dengan meletakkan aplikasi Anda.

COMP6299 - Pattern Software Design

 DAFTAR PUSTAKA
Scott Millett. (2015). Patterns, Principles, and Practices of Domain-Driven Design. 00. John
Wiley & Sons, Inc. Indianapolis
http://www.youtube.com/watch?v=RNUn2R7TptM
https://airbrake.io/blog/software-design/domain-driven-design
https://techbeacon.com/app-dev-testing/get-your-feet-wet-domain-driven-design-3-
guiding-principles
https://dzone.com/refcardz/getting-started-domain-driven?chapter=1
http://www.methodsandtools.com/archive/archive.php?id=97

COMP6299 - Pattern Software Design