Sore tadi berdiskusi dengan pak dosen Agung mengenai topik kekinian, dampak AI pada Software Engineering, kemudian tersebutlah penggunaan terms Agentic Software Engineering.

Sekarang kita eksplor pembahasan Agentic Software Engineering ini di berbagai sumber di Internet dan AI :D

Pencarian sering mengarah ke tulisan dari Ahmed E. Hassan di antaranya:

• Agentic Software Engineering: Foundational Pillars and a Research Roadmap — https://arxiv.org/abs/2509.06216

• Agentic Software Engineering: The rise of AI Teammates — https://link.springer.com/collections/aaaihgcafc

• Agentic Software Engineering book — https://agenticse-book.github.io/

Pendekatannya sebagai Software Engineering versi ke-3 (SE 3.0), dimana urutannya:

1. Software Engineering versi awal (SE 1.0) adalah versi klasik dimana manusia seluruhnya yang coding.

2. Software Engineering versi berikutnya lagi (SE 2.0) dimana AI menjadi asisten.

3. Dan jadi lebih menarik ketika Software Engineering SE 3.0, ketika sejajar antara AI Agent dengan manusia, jadi AI menjadi anggota tim dalam development software.

Beralih lagi sudut pandang lain, kalo Deloitte, menuliskan dampak Agentic AI ke Software Engineering (ada juga pdf yang bisa dibaca di halaman tersebut), melihat dari sudut pandang software development life cycle (SDLC) ke agent orchestrated development life cycle (AO-DLC).

Satu lagi yang menarik adalah penyebutan Agentic Engineering, yang didokumentasikan sebagai Agentic Engineering Pattern oleh Simon Willison, mungkin ada yang mengenalnya sebagai salah satu co-creator framework Django (Python Web), atau mengenalnya dari pengujian LLM menggambar pelican riding a bicycle.

Ngomong-ngomong tentang Agentic Engineering, Addy Osmani membuat tulisan Agentic Engineering yang menarik juga, dikenal sebagai tech leader di Google, juga punya banyak buku yang menarik. Di artikel itu disebutkan bahwa terms Agentic Engineering mengacu ke tulisan Andrej Karpathy di X, terkait nama yang ingin dibedakan dari vibe coding (dimana post dibuat setahun sebelumnya), kemudian mengarah pada Agentic Engineering:

• Agentic: karena default saat ini kita nggak coding sendiri seperti masa klasik Software Engineering, hampir 99% waktu kita mengorkestrasi agents yang mengerjakan dan kita yang mengawasi.

• Engineering: untuk menekankan sebenarnya ada keilmuan, seni, dan keahlian dibalik ini. Kemampuan yang tentunya bisa dipelajari dan dikuasai, serta memiliki kedalaman (mastery) ilmunya tersendiri dan berbeda dari coding yang klasik.

Masih seputar terms dari Andrej Karpathy, ada artikel dari IBM yang bahas Agentic Engineering dilengkapi juga dengan video YouTube membandingkan Agentic Engineering dengan Software Engineering.

Dan masih terus mencari tentang Agentic Software Engineering ini..

​Weekend project: diving back into Linux chroot because I really wanted a native Linux environment on my phone! 💪📱

​Everyone’s first thought is probably: "Just use Termux!"

Well, not quite. This journey actually started with me digging into virtualization, specifically the Android Virtualization Framework (AVF). Unfortunately, my current work phone (a Samsung powered by Snapdragon, huge thanks to Dicoding for the device 😍) doesn’t support AVF the way modern Google Pixels do. Waiting for it to arrive on this architecture feels like a long shot.

​So, I shifted gears and got inspired by proot. It’s incredibly clever how it utilizes ptrace to intercept system calls and translate them on the fly, effectively creating a virtual root filesystem without needing actual root access. This is the exact magic Termux adapted to run various Linux distros on Android.

​Bonus level unlocked 🔓: Navigating around Android's W^X (Write XOR Execute) restrictions. This security mitigation is notoriously known for keeping similar apps stuck at Target SDK 28. Finding a way to bypass this and bump it up to SDK 35 is an interesting challenge, especially if I ever decide to publish this on the Play Store.

​For this weekend, the goal was to understand and implement proot without relying on the Termux environment—just wiring it up to a simple Android UI. Just for fun, I’m also porting a bunch of the initialization scripts into Rust 🦀 so I don’t have to rely too much on bash/mksh.

​You can check out the mess/progress here: https://github.com/oonid/pr

​Oh, and this whole deep dive suddenly made me fully grasp a brilliant article written by Yohanes Nugroho a year ago about using seccomp for syscall interception in Linux and Android. Everything just clicks now! 😁

Read it here: https://blog.compactbyte.com/2025/04/27/seccomp-untuk-intersepsi-syscall-di-linux-dan-android/

​If pak Riza Satria (my lecturer) is still teaching Systems Programming, this could be a pretty fun use case for the class! 🧐

​#AndroidDev #Linux #RustLang #SystemsProgramming #Termux #WeekendProject

(Cross-posted from LinkedIn)

After doing this across several repositories in github.com/oonid, another feeling started to appear. It was not about whether the applications worked. Most of the time I knew what I had asked the agent to do, I had followed the implementation, and I could read the code afterward.

The uncomfortable part came when I tried to hold the whole project in my head.

I could recognize a module and remember the purpose of a feature, but sometimes the connections between them were less clear than I expected. Some decisions had happened several coding sessions earlier. Other parts had changed as the agent worked through a problem and found a better implementation. I had seen those changes when they happened, but seeing something is different from keeping it as part of my understanding.

This was a strange experience because these were my own projects. I was not joining an unfamiliar codebase written by another team. I had started the projects, made the main decisions, worked with the coding agent, and reviewed what it produced. Still, the software could move far enough that I needed to study my own project again.

The application could work while my understanding of it was already becoming incomplete.

That distinction has become important to how I think about AI-assisted software development.

A working application gives us many useful signals. It compiles. Tests pass. An API responds correctly. A feature behaves as expected. We may also have linting, static analysis, benchmarks, code review, and other forms of verification. All of these tell us something about the software.

They do not tell us how well the person responsible for the software understands it.

This problem existed long before coding agents. I have worked with enough software to know that nobody keeps every detail of a large system in their head. We depend on abstraction for that reason. We think about a database as a database instead of remembering every page written to disk. We think about a service through its responsibilities and interfaces instead of remembering every function.

AI changes the rate at which new abstractions, dependencies, files, and decisions can enter a project.

Before using coding agents heavily, implementing a new subsystem also forced me to spend time inside that subsystem. I wrote the code, made many small choices, encountered errors, fixed them, and slowly became familiar with the result. Some of that work was mechanical, but the time spent doing it also had an educational side effect: I was learning the system while creating it.

With an AI coding agent, part of that process is compressed. I can remain involved in the decisions while delegating much more of the implementation. This is one of the reasons the tool is productive. But it also means that an old relationship between production time and learning time starts to change.

I began to see this as an education problem as much as a software engineering problem.

Producing an answer and learning something

Education has dealt with a similar distinction for a long time.

A student can produce the correct answer without having a strong understanding of the subject. A learner may remember a procedure for solving a mathematics problem and become very good at applying it to exercises that have the same shape. The result is correct, so from the outside the learning process seems successful.

Change the problem slightly and the limitation becomes visible.

The student may know which formula to use but not why it works. Another student may be able to follow a worked example but struggle to solve a similar problem later without looking at the example again. In both cases, something has been learned, but the knowledge is not yet flexible enough to use in a different situation.

This is close to what I experience when reading AI-generated code and explanations.

While the code is in front of me, I can follow it. When an agent explains why a module is structured in a certain way, the explanation can be clear and useful. At that moment I may feel that I understand the design.

Later I discover whether that understanding stayed with me.

Can I explain the same part of the system when the original explanation is no longer open? Can I predict which other component will be affected when I change it? Can I connect a design decision from two weeks ago with a problem I am seeing today?

There is a familiar distinction in learning between recognition and recall. Recognizing something when we see it is easier than rebuilding it from memory. The same problem appears when we read source code. A function can look familiar without giving us a useful mental model of the larger system around it.

AI can make recognition very easy. It can continuously provide the missing explanation, locate the relevant code, summarize a module, and answer another question. These are useful capabilities, and I use them. But there is a risk that the tool becomes part of the memory loop. I understand the system while the assistant is present because the assistant can keep reconstructing the missing context for me.

For some tasks that may be perfectly fine. We already use documentation, search engines, IDEs, and reference books as external memory.

Software engineering, however, also requires judgment. When we design an architecture, review a risky change, investigate a production problem, or decide which trade-off is acceptable, we need enough of the system in our own mental model to reason across several pieces at once.

The amount we need to remember is not everything. The important part is knowing enough of the structure and its relationships to reason about the consequences of a decision.

Code review is also a learning activity

This way of thinking changed how I look at code review.

I used to think about review mainly in terms of software quality. I would look for incorrect behavior, design problems, missing tests, security issues, confusing names, or code that would be difficult to maintain. I still care about all of those things.

With AI-assisted development, I now see another purpose in the review process. Review is one of the places where I can update my own understanding of what the system has become.

This matters because the size of a diff does not tell us how much our mental model needs to change. A large mechanical refactoring may preserve the architecture almost completely. A very small modification may introduce a new assumption that changes how two parts of the system interact.

Git is good at showing textual change. It does not automatically tell me how much of my understanding needs to change with it.

This is also where the education perspective becomes useful. When a learner already understands a topic, we normally do not teach the entire subject again every time one new concept is introduced. We connect the new information to what the learner already knows.

Software could be approached in a similar way.

Suppose I understood a project yesterday. Today an agent changes twelve files. I probably do not need a new explanation of the entire repository. I need to know which concepts were added, which relationships changed, whether an old assumption no longer holds, and which parts of my previous understanding can remain as they were.

That is a much smaller learning problem, but it requires more than a diff.

It requires some representation of what the system meant before the change and what it means afterward.

More information does not automatically help

My first instinct was that better documentation might solve much of this. Documentation certainly helps, and I still consider it necessary, but I started to see a limitation there too.

An AI coding agent can generate documentation very quickly. It can create module descriptions, architecture summaries, diagrams, comments, and explanations of almost any part of a repository. The amount of available information is no longer the main limitation.

I can easily imagine reaching a point where the project contains more documentation than I have time to read.

Education has a useful lesson here as well. Giving a learner more material does not guarantee more learning. A textbook can contain everything required to understand a subject while a student remains confused. The order of ideas matters. Prior knowledge matters. Examples matter. Practice matters. Sometimes the learner needs a diagram, sometimes a concrete case, and sometimes they need to try explaining the idea themselves.

There is also cognitive load. Our working memory has limits, so presenting every available detail at once can make understanding harder. Good teaching manages that load by deciding what needs attention now and what can remain in the background.

Software tools rarely think this way. A repository browser gives us files. Git gives us commits and diffs. Static analysis gives us findings. A graph may give us hundreds or thousands of relationships. An AI assistant can summarize all of them.

Every one of those outputs may be correct, yet the human still has to decide what matters.

That is where my thinking about makna started to change.

The early idea was strongly connected to observing development activity. If an AI agent changes software, it seemed useful to capture what the agent did and connect that activity to the state of the repository. The history between a request and the resulting code contains information that Git alone does not preserve.

But collecting more evidence does not solve the comprehension problem by itself.

A complete recording of an agent session could include prompts, tool calls, file modifications, compiler output, test results, retries, and many intermediate actions. It could be an accurate history and still be exhausting for a human to read.

So I started separating three different problems in my head.

First, we need to know what happened. That requires evidence from the coding agent, repository, Git, compiler, tests, and other sources.

Then we need to understand what those observations mean for the software. A changed file is an observation, but the engineering meaning may be that a component gained a new responsibility, an interface changed, or a dependency moved across a boundary.

Finally, the human needs a useful way to learn from that knowledge.

These ideas eventually became the Observation, Knowledge, and Comprehension planes in makna. I did not start with those names. They appeared after trying to separate problems that initially looked like one problem.

The third plane is the one I find especially important now.

A system can collect correct evidence and build an accurate model of software while still failing to help the engineer understand it. Comprehension has its own requirements because people learn in a different way from databases storing facts.

Keeping my mental model up to date

Thinking about learning also led me to a more specific idea.

I do not need makna to teach me my entire project every morning. Most of what I understood yesterday is probably still useful today.

What I need is a way to notice when that understanding should change.

If an agent adds a helper function, my architectural understanding may stay exactly the same. If the agent moves persistence responsibility from one component to another, I need to update part of my mental model even if the code change itself is small.

If a new service appears, I need to learn what role it has and how it connects to the rest of the system. If an old abstraction disappears, I should stop carrying that abstraction in my head. And if the implementation changes while the architectural meaning remains stable, I may only need a brief note.

This eventually led us to the concept of ComprehensionDelta in makna: the difference between what a person needed to understand about the previous state and what they need to understand about the new state.

I like this idea because it connects the history of software with the process of learning it.

The repository has a history.

The engineering model has a history.

Our understanding has a history too.

AI coding agents make the first history move faster. makna is an attempt to help the third one keep up.

I still want AI to help me write more software. My experience with it has been productive enough that going back to the old way of doing everything manually would make little sense to me. The problem I want to work on is what happens after that productivity gain.

When I return to one of my own projects, I want to remain close enough to it that I can explain the important parts, follow how they changed, and make the next engineering decision with a mental model I can trust.

The application working is one result.

Understanding what I have built is another.

For a software developer, this is exciting. I can spend more time thinking about architecture and problems instead of typing every line of code. Projects that might have taken much longer can now move forward very quickly.

After doing this for a while, however, I noticed something uncomfortable.

My repositories were growing faster than my understanding of them.

I could open a project and recognize the code. I knew what I had asked the coding agent to build, and I had reviewed many of the changes when they were created. The application worked and the tests could pass, yet sometimes I needed time to rebuild the larger picture in my head. I had to remember how the components were connected, why a certain design was chosen, what had changed during several AI-assisted sessions, and which decisions still mattered.

That moment stayed with me because I was not looking at someone else’s project. These were my projects. I had been involved from the beginning.

AI had helped me produce more software, but my ability to produce software had increased faster than my ability to keep all of that software in my head.

This is different from saying that AI writes bad code. In many cases, I am impressed by how useful coding agents have become. The problem can appear even when the generated code is good.

Software engineering has always required us to manage complexity, but AI changes the rate at which that complexity can arrive. A developer can now create, modify, and extend a system much faster, while human learning still takes time. We need to read, connect ideas, remember decisions, and gradually build a mental model of the system.

That difference between the speed of software production and the speed of human understanding became one of the reasons I started thinking about makna.

I want to explore whether we can keep the productivity of AI-assisted development without becoming disconnected from the software we are creating.

If AI helps us write more code, I think we also need better ways to keep understanding what that code becomes.

https://tokio.rs/tokio/tutorial/setup

Aplikasi bisnis dibangun dengan prinsip domain dan bounded context, sementara sistem data — terutama data lake dan data warehouse — dikelola secara terpusat oleh tim analitik.

to be continued.

Perangkat lunak perlu bereaksi terhadap berbagai kejadian yang muncul di waktu berbeda, dari berbagai sumber, dan kadang tanpa koordinasi langsung.

Inilah konteks di mana Event-Driven Architecture (EDA) menjadi relevan.

Sementara Domain-Driven Design (DDD) fokus pada memahami dan memodelkan domain bisnis,

Event-Driven Architecture fokus pada mengalirkan informasi tentang perubahan domain ke seluruh sistem.

to be continued.

Namun, kenyataannya sering jauh dari harapan: setelah dipecah menjadi banyak service, tim justru kebingungan mengelola dependensi, data tersebar, dan komunikasi antar sistem menjadi mimpi buruk.

Vlad Khononov menyebut fenomena ini dengan sangat tepat:

“Microservices are not the destination — they are the outcome of understanding your domain.” — Vlad Khononov, Learning Domain-Driven Design (2022)

Dengan kata lain, microservices bukan tujuan, melainkan konsekuensi logis dari penerapan DDD yang baik.

Microservices dan Janji Kemerdekaan

Secara konsep, microservice architecture adalah tentang memecah sistem besar menjadi unit-unit kecil yang dapat dikembangkan, dirilis, dan diskalakan secara independen.

Setiap microservice:

• Menangani satu fungsi bisnis tertentu,

• Memiliki data sendiri,

• Dan bisa dikelola oleh satu tim otonom.

Tujuannya terdengar sederhana: independence and scalability. Namun dalam praktiknya, banyak organisasi gagal karena tidak memahami batas domain sebelum membagi service.

“Without understanding domain boundaries, splitting a monolith creates distributed chaos, not distributed systems.” — Khononov, 2022

Dan di situlah peran DDD menjadi sangat penting.

Hubungan DDD dan Microservices

DDD memberi fondasi berpikir yang kuat untuk menentukan batas alami dari setiap microservice, yaitu melalui konsep bounded context.

• DDD Concept: Bounded Context

  • Padanan Microservices: Microservice Boundary

  • Tujuan: Memisahkan logikadan model bisnis secara mandiri

• DDD Concept: Ubiquitous Language

  • Padanan Microservices: Service API Contract

  • Tujuan: Bahasa dan istilah konsisten dalam satu tim

• DDD Concept: Context Map

  • Padanan Microservices: Service Interaction Diagram

  • Tujuan: Hubungan antar service dan pola komunikasinya

• DDD Concept: Communication Pattern

  • Padanan Microservices: API/Event Integration

  • Tujuan: Cara service berkoordinasi tanpa coupling

Jadi, bounded context dalam DDD bukan sekadar konsep abstrak, ia adalah peta alami yang membantu kita menentukan microservice yang sehat.

Bounded Context Sebagai Panduan Desain Microservice

Banyak kegagalan microservice berasal dari salah memotong sistem: dibagi berdasarkan lapisan teknis (UI, backend, database), bukan area bisnis.

Hasilnya: service terlalu kecil, saling bergantung, dan kehilangan makna bisnis.

DDD membantu memotong sistem secara semantik, bukan struktural.

Contoh: Daripada membagi berdasarkan teknologi:

/user-api
/payment-service
/database-service

DDD akan mendorong pembagian berdasarkan domain:

/billing-context
/inventory-context
/customer-context

Setiap context punya logika, data, dan bahasa sendiri, itulah microservice yang benar-benar “domain-driven”.

Integrasi Antar Microservice: Komunikasi Antara Context

Ketika kita punya banyak bounded context (atau microservice), komunikasi di antaranya harus dikelola dengan hati-hati.

DDD memperkenalkan communication patterns yang juga relevan di dunia microservices, seperti:

• Customer–Supplier

• Conformist

• Partnership

• Separate Ways

Dalam konteks arsitektur terdistribusi, pola-pola ini bisa diterjemahkan sebagai:

• Customer–Supplier → satu service tergantung API dari service lain,

• Conformist → mengikuti format upstream tanpa perubahan,

• Partnership → dua tim berkolaborasi erat,

• Separate Ways → berjalan mandiri tanpa integrasi real-time.

Misalnya:

// Contoh komunikasi event-driven antar microservice
#[derive(serde::Serialize, serde::Deserialize)]
struct OrderPlaced {
    order_id: u64,
    total: f64,
}

fn publish_order_placed(order: OrderPlaced) {
    // publish ke message broker (Kafka, NATS, dll)
    println!("Publishing event: {:?}", order);
}

Pendekatan event-driven ini menjaga agar microservice tetap otonom, karena setiap service bereaksi terhadap event, bukan memanggil service lain secara langsung.

Tantangan Microservice di Dunia Nyata

Meski konsepnya indah, arsitektur microservices membawa kompleksitas baru.

Khononov mengingatkan, bahwa:

“Microservices move complexity from code to communication.” — Vlad Khononov, 2022

Mari lihat beberapa jebakan umum yang sering terjadi:

1. Over-segmentation (Service Terlalu Kecil)

Engineer terlalu semangat memecah sistem hingga setiap fungsi menjadi satu service. Akibatnya, integrasi menjadi rumit dan deployment berantakan.

Solusi: Pastikan setiap service punya makna domain utuh (bounded context lengkap), bukan sekadar endpoint CRUD.

2. Shared Database

Beberapa service masih berbagi database yang sama, ini menghapus batas konteks.

Solusi: Setiap service memiliki database sendiri, bahkan jika data yang disimpan mirip. Gunakan event untuk sinkronisasi, bukan query silang.

3. Communication Hell

Service saling memanggil API secara berantai (A → B → C → D). Jika satu mati, semuanya ikut gagal.

Solusi: Gunakan asynchronous messaging (event-driven) untuk mengurangi coupling antar service.

4. Terlalu Banyak Infrastruktur

Microservice memerlukan CI/CD pipeline, monitoring, logging, service mesh, dan sebagainya. Untuk tim kecil, overhead ini bisa lebih mahal daripada manfaatnya.

Solusi: Mulai dari modular monolith, struktur monolit yang sudah terpisah per context. Jika sudah stabil, baru evolusikan ke microservice sejati.

Modular Monolith Sebagai Titik Awal

Khononov menyarankan pendekatan yang realistis:

“Start with a modular monolith. Split it when you must, not when you can.” — Khononov, 2022

Artinya, kamu bisa mulai dengan sistem monolit tunggal, tapi struktur internalnya sudah mengikuti prinsip bounded context.

Contoh struktur folder dalam Rust:

src/
 ├── billing/
 │    ├── domain.rs
 │    ├── service.rs
 │    └── repository.rs
 ├── inventory/
 │    ├── domain.rs
 │    └── service.rs
 └── main.rs

Ketika skala sistem tumbuh, tiap folder domain ini bisa dengan mudah dipecah menjadi microservice independen, karena sejak awal, batas context-nya sudah jelas.

DDD sebagai Landasan Microservice Sehat

Inti dari pesan Khononov sangat sederhana tapi krusial:

“Without DDD, microservices are just distributed monoliths.” — Vlad Khononov (2022)

DDD membantu kita:

1. Menentukan batas yang sehat (bounded contexts),

2. Menjaga otonomi antar tim,

3. Mencegah duplikasi logika bisnis,

4. Menghindari coupling antar service.

Dengan kata lain, DDD adalah kompas yang menunjukkan di mana memotong sistem. Microservices hanyalah hasil fisik dari pemotongan itu.

Ringkasnya, Microservices yang Bermakna

Microservices bukan soal ukuran kecil, tapi soal batas makna yang jelas. Sebuah microservice seharusnya mencerminkan satu domain bisnis yang utuh, bukan sekadar satu tabel di database atau satu endpoint di API gateway.

DDD membantu kita menemukan batas itu, bukan lewat intuisi arsitek, tapi lewat percakapan lintas tim, pemahaman domain, dan bahasa umum yang disepakati.

“Good microservices emerge from good domain models.” — Vlad Khononov, Learning Domain-Driven Design (2022)

Referensi

Khononov, V. (2022). Learning Domain-Driven Design: Aligning Software Architecture and Business Strategy. O’Reilly Media.

Dan memang benar. Vlad Khononov sendiri menekankan sejak awal bahwa Domain-Driven Design bukanlah metode magis yang menjamin keberhasilan proyek, melainkan sekumpulan pola pikir dan alat bantu untuk memahami serta mengelola kompleksitas.

Dalam bab ini, kita akan melihat bagaimana DDD diterapkan secara pragmatis di dunia nyata, termasuk kesalahpahaman umum, jebakan organisasi, dan strategi agar tetap waras dalam menghadapi kenyataan.

Kenyataan #1: Tidak Semua Sistem Butuh DDD

Salah satu kesalahan paling sering ditemui di dunia profesional adalah menerapkan DDD di semua tempat.

Padahal, tidak semua sistem punya kompleksitas yang layak untuk itu.

DDD diciptakan untuk domain yang:

• Kompleks secara bisnis, bukan hanya teknis.

• Penuh ambiguitas dan aturan yang berubah cepat.

• Memerlukan komunikasi intens antara developer dan domain expert.

Kalau sistem kamu hanya mencatat data CRUD (Create, Read, Update, Delete), maka memakai DDD lengkap akan terasa seperti menggunakan bazooka untuk memecahkan telur.

“DDD is not for every project — it’s for the ones where business complexity rules.” — Vlad Khononov, Learning Domain-Driven Design (2022)

Jadi, if it’s simple, keep it simple. Gunakan pendekatan ringan seperti Transaction Script atau Active Record untuk modul sederhana, dan hanya terapkan DDD penuh pada bagian yang benar-benar strategis.

Kenyataan #2: Organisasi Lebih Sulit dari Kode

DDD sering kali gagal bukan karena engineer tidak paham model, tapi karena organisasi tidak siap untuk cara berpikir kolaboratif.

Di dunia nyata:

• Tim terpisah oleh silo,

• Komunikasi antar departemen buruk,

• “Ahli domain” tidak selalu punya waktu untuk berdiskusi,

• Dan setiap tim punya KPI sendiri-sendiri.

Hasilnya? Setiap orang punya versi modelnya sendiri, dan ubiquitous language yang ideal di buku berubah jadi babel language di kantor.

“The real challenge of DDD is not modeling the software — it’s modeling the organization.” — Khononov, 2022

Strategi realistis: Mulai dari lingkar kecil, satu tim yang mau berkolaborasi penuh. Bangun bounded context pertama di situ, dan buktikan hasilnya. Setelah berhasil, baru tularkan ke tim lain.

Kenyataan #3: Bounded Context Itu Tidak Harus Rapi

Di teori, bounded context terlihat jelas: setiap domain punya batas logis, bahasa sendiri, dan modelnya tidak tumpang-tindih.

Tapi di dunia nyata, batas itu sering kabur:

• Ada konteks yang saling tumpang tindih,

• Ada istilah yang “nyasar” karena kebutuhan API,

• Kadang satu tim harus mengurusi dua domain karena alasan praktis.

Dan itu tidak apa-apa.

DDD bukan tentang kesempurnaan arsitektur, tapi tentang kesadaran terhadap batasan. Selama tim sadar di mana batas tanggung jawabnya, DDD tetap hidup.

“It’s okay if your boundaries are blurry — as long as you know they’re blurry.” — Khononov, 2022

Contohnya, dua tim mungkin sama-sama menggunakan istilah Order. Tapi yang penting adalah:

• Mereka tahu makna “Order” di masing-masing context,

• Dan mereka tidak saling memaksakan model satu sama lain.

Kenyataan #4: Model Akan Selalu Berubah

Sering kali, tim DDD pemula ingin membuat domain model final sebelum mulai coding. Padahal, seperti dibahas di Bab 11, model domain itu hasil belajar, bukan hasil perencanaan.

Model yang baik bukan yang paling stabil, tapi yang paling mudah beradaptasi.

Praktik nyata: Gunakan pendekatan event-driven untuk memantau perubahan domain. Setiap kali muncul event baru yang tidak masuk akal, itu tanda modelmu butuh revisi.

Misalnya:

// Model awal
enum OrderStatus {
    Pending,
    Paid,
}

// Setelah bisnis menambah fitur refund
enum OrderStatus {
    Pending,
    Paid,
    Refunded,
}

Model berkembang bukan karena salah di awal, tapi karena bisnis berubah dan pengetahuan bertambah.

Kenyataan #5: Kompromi Itu Wajar

Setiap proyek di dunia nyata berhadapan dengan tiga tekanan utama:

1. Waktu: deadline yang ketat,

2. Sumber daya: tim kecil, beban besar,

3. Teknologi warisan (legacy): keputusan lama yang sulit diubah.

Dan di tengah tekanan itu, idealisme DDD kadang harus dikompromikan.

“A pragmatic architect knows when to bend the rules.” — Khononov, 2022

Kompromi tidak berarti menyerah. Yang penting adalah tahu kapan dan kenapa melanggar prinsip.

Contoh kompromi sehat:

• Sementara gunakan model anemik (tanpa logika bisnis di entitas), lalu perlahan refactor ketika domain makin jelas.

• Tulis event secara manual dulu tanpa bus, lalu evolusikan jadi event-driven architecture saat skalanya cukup besar.

• Gunakan shared database sementara untuk sinkronisasi antar context, tapi tandai sebagai temporary coupling.

Kunci keberhasilan DDD di dunia nyata adalah transparansi dalam kompromi.

Kenyataan #6: DDD Adalah Perjalanan, Bukan Tujuan

Banyak tim berpikir bahwa “menerapkan DDD” adalah milestone yang bisa dicapai. Padahal, DDD itu bukan proyek — ia cara berpikir yang berkelanjutan.

DDD yang sehat terlihat bukan dari diagram yang indah, tapi dari komunikasi yang lancar antar tim, pemahaman yang jelas tentang domain, dan model yang tumbuh bersama bisnis.

“The success of DDD is not measured in aggregates, but in shared understanding.” — Vlad Khononov (2022)

Ketika orang bisnis, developer, dan QA bisa berbicara tanpa translator, itulah saat DDD benar-benar hidup, bahkan tanpa disebut DDD.

Kenyataan #7: Legacy Systems Bisa Diperbaiki Bertahap

Banyak perusahaan tidak memulai dari nol. Mereka punya sistem lama, penuh logika bercampur, dan database yang menua.

Kabar baiknya: DDD bisa diterapkan secara bertahap.

Mulailah dari memetakan domain dan event dengan EventStorming (Bab 12). Temukan bounded context tersembunyi di dalam monolit, dan pisahkan secara evolusioner.

Contohnya, dari monolit besar, ekstrak satu domain kecil seperti Invoice Management menjadi microservice mandiri dengan domain model sendiri.

Dengan cara itu, DDD menjadi strategi perbaikan berkelanjutan, bukan proyek overhaul besar.

Heuristik untuk Bertahan di Dunia Nyata

Khononov menutup buku ini dengan beberapa heuristik penting bagi praktisi DDD:

• Heuristik: Mulai dari percakapan, bukan kode.

  • Penjelasan: DDD lahir dari dialog dengan domain expert.

• Heuristik: Desain secukupnya.

  • Penjelasan: Tidak semua bagian butuh arsitektur kompleks.

• Refactor berdasarkan pembelajaran.

  • Penjelasan: Evolusi model harus mengikuti realitas bisnis.

• Gunakan bahasa bisnis di kode.

  • Penjelasan: Nama-nama class, function, dan event harus masuk akal bagi non-engineer.

• Toleransi terhadap kekacauan.

  • Penjelasan: Di awal, model pasti berantakan — dan itu normal.

• Rayakan perbaikan kecil.

  • Penjelasan: Setiap domain yang jadi lebih mudah dipahami adalah kemenangan.

Ringkasnya, DDD yang Sejati Adalah DDD yang Hidup

Pada akhirnya, DDD bukan tentang pola, agregat, atau bounded context yang sempurna. DDD adalah tentang membawa makna bisnis ke dalam perangkat lunak dengan cara yang bisa berkembang bersama waktu.

Di dunia nyata, DDD yang berhasil bukan yang 100% sesuai buku, tapi yang 100% dipahami oleh orang-orang yang membangunnya.

“Perfect DDD doesn’t exist — but meaningful DDD does.” — Vlad Khononov, Learning Domain-Driven Design (2022)

Referensi

Khononov, V. (2022). Learning Domain-Driven Design: Aligning Software Architecture and Business Strategy. O’Reilly Media.

melainkan menyatukan pemahaman antara orang-orang yang berbicara bahasa berbeda:

engineer, product manager, domain expert, dan stakeholder bisnis.

Setiap orang membawa perspektifnya sendiri:

• Engineer berpikir dalam entitas dan API,

• Product manager berpikir dalam fitur,

• Domain expert berpikir dalam proses dan peraturan bisnis.

Dan sering kali, perbedaan bahasa ini membuat diskusi berputar tanpa hasil.

Nah, EventStorming hadir untuk menjembatani semua itu.
Ini bukan teknik coding, tapi teknik berpikir dan berkolaborasi visual agar tim memahami domain dengan cara yang sama.

“EventStorming is a workshop-based method to explore complex domains by focusing on domain events.” — Vlad Khononov, Learning Domain-Driven Design (2022)

Apa Itu EventStorming?

Secara sederhana, EventStorming adalah cara memetakan alur bisnis dengan menulis peristiwa-peristiwa (event) yang terjadi di domain, biasanya di atas dinding atau papan besar dengan sticky notes berwarna.

Kata “Storming” di sini menggambarkan proses eksplorasi yang intens dan cepat, bukan diskusi formal yang kaku.
Tujuannya bukan langsung “mendesain arsitektur,” tapi mendapatkan pemahaman utuh tentang bagaimana domain bekerja dari perspektif semua pihak.

Kata kuncinya:
Semua orang bisa berkontribusi, semua ide valid, dan peristiwa (event) adalah bahasa pemersatu.

Kenapa EventStorming Penting dalam DDD

DDD berfokus pada pemahaman domain.
Tapi sering kali, pengetahuan domain tidak tertulis dengan rapi,
ia tersebar di kepala orang-orang, dokumen lama, atau asumsi tim.

EventStorming membantu:

1. Menyatukan semua stakeholder di satu ruangan (atau papan digital).

2. Menyingkap logika bisnis tersembunyi lewat diskusi natural.

3. Membentuk bahasa umum (ubiquitous language) dari kejadian nyata di domain.

4. Menemukan batas-batas alami (bounded contexts) berdasarkan pola peristiwa.

Dengan kata lain, EventStorming adalah cara tercepat untuk “menemukan domain model” sebelum menulis satu baris kode pun.

Prinsip Utama: Berpikir dalam “Event”

Daripada bertanya “entitas apa yang kita butuhkan?”, facilitator EventStorming akan memulai dengan pertanyaan sederhana: “Apa saja yang terjadi di domain ini?”

Setiap jawaban ditulis dalam format Domain Event, sesuatu yang terjadi di masa lalu dan relevan bagi bisnis.

Contohnya:

• OrderPlaced

• PaymentReceived

• ShipmentSent

• CustomerRegistered

Setiap event ditempel di dinding dari kiri ke kanan, menggambarkan urutan waktu.

Dari situ, perlahan terbentuk narasi: bagaimana proses bisnis berjalan, siapa yang terlibat, dan di mana kompleksitas muncul.

Warna dan Artefak Utama

EventStorming biasanya menggunakan sticky note dengan warna berbeda, yang masing-masing mewakili artefak penting dalam domain.

• Oranye: Artefak Domain Event

  • Artinya: Sesuatu yang terjadi di masa lalu

• Biru: Artefak Command

  • Artinya: Tindakan yang menyebabkan Event

• Kuning: Artefak External System / Policy

  • Artinya: Sistem atau aturan luar yang memicu tindakan

• Merah muda: Artefak Actor / User

  • Artinya: Siapa yang menjalankan command

• Hijau: Artefak View / Read Model

  • Artinya: Informasi yang dilihat pengguna

• Ungu: Artefak Aggregate / Entity

  • Artinya: Unit logika bisnis yang menangani command

Tidak semua workshop butuh semua warna. Fokusnya bukan estetika, tapi pemahaman bersama tentang hubungan sebab-akibat di domain.

Fase-Fase EventStorming

Menurut Khononov (2022), proses EventStorming umumnya terdiri dari beberapa tahap yang semakin mendalam.

1. Big Picture EventStorming

Tujuannya: menemukan alur bisnis secara keseluruhan.

Peserta dari berbagai fungsi (bisnis, teknis, operasional) diminta menuliskan semua event penting dalam proses.
Hasilnya sering kali berantakan — dan itu bagus! Karena di sanalah percakapan penting muncul.

Contoh:
Ketika seseorang menulis PaymentFailed, peserta lain mungkin bertanya,
“Lho, itu terjadi sebelum atau sesudah OrderCancelled?”
Diskusi seperti itu mengungkap aturan bisnis implisit yang selama ini tidak pernah terdokumentasi.

2. Process-Level EventStorming

Setelah gambaran besar terbentuk, tim bisa memperdalam satu proses spesifik, misalnya Order Fulfillment.
Di tahap ini, kita mulai melihat command, actor, dan aggregate yang terlibat.

Misalnya:

• Command: PlaceOrder

• Aggregate: Order

• Event: OrderPlaced

• Actor: Customer

Dan mungkin muncul insight seperti: “Kalau stok tidak cukup, event OrderRejected bisa muncul.”

Dari sini, kita mulai melihat pola bounded context dan logika bisnis yang nyata.

3. Design-Level EventStorming

Tahap ini paling teknis, dilakukan biasanya oleh engineer dan arsitek sistem.
Di sini, event dan command diterjemahkan ke dalam komponen desain seperti:

• Aggregate (logika domain utama)

• Saga / Process Manager (mengatur alur lintas aggregate)

• Read Model / Projection (untuk query data)

• External System Integration (pihak ketiga)

Contoh dalam Rust (sketsa sederhana):

struct Order {
    id: u64,
    status: OrderStatus,
}

impl Order {
    fn place(&mut self) -> OrderPlaced {
        self.status = OrderStatus::Placed;
        OrderPlaced { order_id: self.id }
    }
}

struct OrderPlaced {
    order_id: u64,
}

Dari event yang awalnya hanya sticky note oranye, kini kita bisa melihat kode yang berbicara dengan bahasa bisnis yang sama.

Temuan yang Sering Muncul dari EventStorming

EventStorming bukan hanya latihan pemetaan, ini adalah alat diagnosis organisasi.

Beberapa temuan umum:

• Ambiguitas istilah: orang berbeda menyebut hal yang sama dengan istilah berbeda.

• Kekosongan tanggung jawab: ada event tanpa command yang jelas.

• Masalah komunikasi antar tim: event muncul di satu context tapi dikonsumsi di context lain tanpa koordinasi.

• Aturan bisnis tersembunyi: “oh ternyata itu otomatis dibatalkan kalau lewat 24 jam!”

Setiap temuan seperti ini adalah pengetahuan domain baru, dan itulah nilai utama EventStorming.

Nilai Praktis bagi Engineer

Bagi engineer, EventStorming terasa seperti cheat code untuk memahami domain baru.

Alih-alih membaca dokumen setebal 50 halaman atau menebak-nebak lewat backlog Jira, kita bisa melihat alur bisnis hidup di depan mata.

Kita tahu:

• Event apa yang penting,

• Siapa yang memicunya,

• Kondisi apa yang menyebabkannya gagal,

• Dan bagaimana satu bounded context memengaruhi yang lain.

Setelah workshop, kode yang kita tulis jadi jauh lebih dekat dengan cara bisnis berpikir.

EventStorming dan Bounded Context

Salah satu hasil alami dari EventStorming adalah munculnya pola pemisahan alami antar bagian domain.

Ketika papan mulai “penuh”, kita bisa mulai melihat klaster event yang saling erat, itulah kandidat bounded context.

“Bounded contexts don’t come from architects — they emerge from understanding.” — Vlad Khononov, 2022

Bounded context yang ditemukan dengan cara ini jauh lebih realistis, karena tumbuh dari percakapan lintas tim, bukan dari diagram PowerPoint.

Kapan Menggunakan EventStorming

Gunakan EventStorming ketika:

• Tim baru akan memulai proyek besar,

• Domain masih kabur atau penuh asumsi,

• Ada ketegangan antar tim atau model yang tidak selaras,

• Atau ketika organisasi ingin membangun ubiquitous language.

Sebaliknya, untuk sistem kecil atau domain yang sudah stabil, EventStorming mungkin berlebihan, cukup gunakan diagram alur sederhana.

Tips Memfasilitasi EventStorming

1. Mulai dari event, bukan dari entitas.
   Jangan tanya “objek apa yang kita punya?”, tapi “apa yang terjadi?”

2. Dorong partisipasi semua pihak.
   Tidak ada jawaban salah. Justru ketidaksepakatan itu bahan diskusi.

3. Gunakan papan besar dan sticky notes.
   Visualisasi itu penting, otak manusia lebih cepat memahami pola.

4. Beri ruang untuk chaos.
   Di awal pasti berantakan, tapi dari kekacauan itu muncul struktur.

5. Akhiri dengan insight, bukan diagram sempurna.
   Tujuan utama: pemahaman bersama, bukan artefak yang rapi.

Ringkasnya, ini adalah Percakapan yang Mengubah Cara Berpikir

EventStorming bukan alat teknis, ia alat manusiawi.
Ia mengubah cara tim memahami domain dari debat tentang solusi menjadi percakapan tentang kejadian nyata.

Setelah workshop, semua orang, baik engineer, PM, maupun ahli bisnis, akan mulai berbicara dengan bahasa yang sama. Dan itu, dalam semangat DDD, adalah kemenangan terbesar.

“Software design is a communication game. EventStorming makes the rules visible.” — Vlad Khononov, Learning Domain-Driven Design (2022)

Referensi

Khononov, V. (2022). Learning Domain-Driven Design: Aligning Software Architecture and Business Strategy. O’Reilly Media.

Di artikel-artikel sebelumnya, kita belajar bahwa domain model itu hidup. Ia berkembang seiring perubahan bisnis dan pemahaman tim.

Tapi bukan hanya model domain yang perlu berevolusi. Keputusan desain dan arsitektur pun harus mengikuti — karena yang kita tahu hari ini belum tentu benar besok.

“Good design decisions are not permanent. They are just good for now.” — Vlad Khononov, Learning Domain-Driven Design (2022)

Inilah inti dari bab ini: desain yang baik adalah desain yang bisa tumbuh bersama waktu dan pengetahuan.

Mengapa Desain Harus Berevolusi

Kita sering berpikir desain itu seperti kontrak: sekali diputuskan, harus dijaga mati-matian. Padahal, dunia bisnis bergerak cepat. Aturan baru muncul, model berubah, skala sistem bertambah, bahkan teknologi pun bergeser.

Keputusan yang dulu tepat bisa jadi tidak relevan hari ini. Maka, desain yang sehat bukan yang “tidak berubah”, tapi yang mudah berubah tanpa menyakitkan.

Contoh sederhana:

Awalnya sistem pembayaran hanya mendukung cash dan transfer bank, jadi cukup enum sederhana:

enum PaymentMethod {
    Cash,
    BankTransfer,
}

Tiga bulan kemudian, muncul kebutuhan baru: QRIS, kartu kredit, e-wallet, bahkan voucher internal.

Kalau arsitektur kita kaku, perubahan kecil seperti ini bisa menyentuh banyak tempat sekaligus — error di mana-mana. Tapi kalau modelnya fleksibel, kita cukup menambah varian baru tanpa mengubah bagian lain:

enum PaymentMethod {
    Cash,
    BankTransfer,
    CreditCard(String),
    EWallet(String),
    Voucher(String),
}

Desain yang bisa berevolusi seperti ini menunjukkan bahwa arsitektur kita adaptif terhadap perubahan pengetahuan.

Desain Itu Proses Pembelajaran

Khononov menjelaskan bahwa desain bukan hasil akhir dari perencanaan panjang, melainkan hasil iterasi dari proses belajar.

Setiap diskusi dengan domain expert, setiap bug, dan setiap perilaku pengguna membawa insight baru tentang domain. Dengan setiap wawasan baru itu, kita perlu memperbarui model, dan kadang mengubah keputusan desain sebelumnya.

“Design is learning, and learning means change.” — Vlad Khononov, 2022

Desain DDD bukan soal menemukan struktur paling indah, tapi soal menemukan struktur yang paling menggambarkan kenyataan saat ini.

Perbedaan Antara Desain yang Kaku dan Desain yang Berevolusi

Aspek Desain Kaku

• Fokus: Kepastian

• Tujuan: Menghindari perubahan

• Strategi: Rencana besar di awal

• Efek samping: Cepat usang

• Pola pikir: “Sudah benar dari awal”

Aspek Desain Berevolusi

• Fokus: Adaptasi

• Tujuan: Menyambut perubahan

• Strategi: Iterasi kecil dan terus-menerus

• Efek samping: Selalu relevan

• Pola pikir: “Kita belajar setiap hari”

Desain kaku lahir dari ketakutan akan salah. Desain yang berevolusi lahir dari rasa ingin tahu dan keberanian untuk mengoreksi diri.

Teknik: Menunda Keputusan Secara Sengaja

Salah satu prinsip desain penting yang diperkenalkan dalam buku ini adalah delaying decisions — menunda keputusan desain sampai kita punya cukup informasi.

Istilah ini sering disebut Last Responsible Moment:

“Ambil keputusan selambat mungkin, tapi tidak sampai terlambat.”

Artinya, jangan buat keputusan desain besar saat masih banyak ketidakpastian. Ambil keputusan yang paling ringan dulu, yang bisa dengan mudah diubah nanti.

Contoh: Daripada langsung memilih pattern besar seperti CQRS + Event Sourcing, mulailah dengan Layered Architecture. Begitu sistem makin kompleks dan kebutuhan audit muncul, kamu bisa evolusikan jadi CQRS.

Atau, daripada menentukan teknologi database di awal, abstraksikan akses datanya lewat Repository Interface. Kalau nanti migrasi dari SQLite ke PostgreSQL, domain model tetap aman.

trait OrderRepository {
    fn save(&self, order: &Order);
    fn find_by_id(&self, id: u64) -> Option<Order>;
}

Keputusan kecil ini menjaga fleksibilitas tanpa mengorbankan arah.

Prinsip: Keputusan Harus Proporsional dengan Pengetahuan

Khononov menyebut bahwa setiap keputusan desain adalah pertukaran antara pengetahuan dan risiko.

• Semakin sedikit pengetahuan yang kita punya, semakin besar risiko salah mengambil keputusan.

• Maka, keputusan harus sepadan dengan tingkat pemahaman kita saat itu.

Jangan terlalu dini membuat keputusan besar atas asumsi mentah. Sebaliknya, jangan juga terlalu lama menunda hingga tim kehilangan arah.

Prinsip ini mendorong pola pikir evolutionary architecture, arsitektur yang tidak selesai di atas kertas, melainkan terus dibentuk dari pengalaman nyata.

Tanda-tanda Kamu Butuh Mengubah Desain

1. Banyak “if” di mana-mana. Itu tanda model sudah tidak mencerminkan domain lagi.

2. Aturan bisnis sulit dijelaskan lewat kode. Mungkin modelmu sudah terlalu teknis.

3. Istilah di kode dan di meeting mulai berbeda. Bahasa umum (ubiquitous language) sudah melenceng.

4. Perubahan kecil memengaruhi banyak bagian. Tanda struktur sistem sudah terlalu rapuh.

5. Tim mulai takut refactor. Ini gejala klasik desain yang membatu.

Kalau ini mulai terasa, jangan panik. Itu bukan kegagalan, itu sinyal bahwa kamu sudah belajar sesuatu yang baru, dan saatnya model ikut berubah.

Pendekatan: Continuous Refinement

Evolusi desain tidak butuh revolusi besar setiap enam bulan. Cukup lakukan refinement kecil secara terus-menerus.

Langkah sederhananya:

1. Identifikasi pain point. Misalnya entitas tertentu jadi terlalu besar.

2. Diskusikan dengan domain expert. Apakah ada istilah atau proses baru?

3. Perbaiki model. Pecah aggregate, ubah value object, atau tambahkan event.

4. Uji asumsi. Pastikan perubahan benar-benar memudahkan pemahaman bisnis.

5. Rilis kecil. Jangan tunda sampai “semua siap”.

Refinement yang berkelanjutan jauh lebih sehat daripada refactor masif yang menakutkan.

Mengelola Tekanan dan Trade-off

Kadang manajemen ingin keputusan cepat: “Pilih framework sekarang!” Atau: “Kita harus finalkan model minggu ini!”

Dalam konteks DDD, tugas engineer bukan hanya membuat kode, tapi juga melindungi proses belajar. Artinya, jangan biarkan tekanan waktu membunuh kesempatan untuk memahami domain dengan benar.

Kita boleh mengambil keputusan pragmatis sementara — asal sadar bahwa itu keputusan sementara, dan siap diperbaiki nanti.

“Every temporary decision is a debt — pay it back when knowledge grows.” — Vlad Khononov, 2022

Kode Sebagai Dokumentasi Evolusi

Model domain yang baik seharusnya menjadi dokumentasi hidup tentang cara bisnis bekerja saat ini. Jangan takut kalau modelmu berbeda dari enam bulan lalu — itu tanda kamu belajar.

Gunakan git commit, test case, dan domain event sebagai jejak sejarah evolusi keputusan desain.

Contoh:

// Sebelum
enum DeliveryStatus {
    Pending,
    Delivered,
}

// Setelah memahami proses retur
enum DeliveryStatus {
    Pending,
    Delivered,
    Returned(String), // alasan pengembalian
}

Setiap perubahan semacam ini adalah bukti bahwa sistemmu menyesuaikan diri dengan realitas bisnis, bukan sebaliknya.

Ringkasan mengenai Desain yang Tumbuh Bersama Pengetahuan

DDD bukan hanya tentang membuat model domain, tapi tentang membangun sistem yang terus belajar.

Desain yang baik tidak kaku. Ia tumbuh bersama tim, bersama bisnis, dan bersama waktu.

Prinsip utamanya sederhana:

• Jangan kunci keputusan sebelum waktunya.

• Jangan takut mengubah arah saat pengetahuan bertambah.

• Dan yang paling penting: pastikan perubahan desain selalu mengikuti makna bisnis, bukan sekadar selera teknis.

“The best design is the one that fits the current understanding of the domain — and is ready to change when that understanding grows.” — Vlad Khononov, Learning Domain-Driven Design (2022)

Referensi

Khononov, V. (2022). Learning Domain-Driven Design: Aligning Software Architecture and Business Strategy. O’Reilly Media.

Jika di pembahasan sebelumnya kita belajar tentang semua elemen keren di DDD — dari bounded context, aggregate, sampai communication patterns, mungkin kini muncul pertanyaan praktis:

“Kapan sih kita benar-benar perlu pakai DDD? Apakah semua bagian sistem harus pakai domain model penuh?”

Jawabannya singkat tapi penting: tidak selalu. Dan di sinilah kita mulai masuk ke inti bab ini: design heuristics — kumpulan prinsip berpikir agar kita tahu seberapa dalam menerapkan DDD, dan kapan harus berhenti sebelum berlebihan.

Heuristik: Bukan Aturan, Tapi Kompas

Kata heuristic berarti “petunjuk praktis untuk membuat keputusan yang baik dalam kondisi tidak pasti.” Dalam konteks DDD, heuristik membantu kita memilih pendekatan desain yang seimbang antara nilai bisnis dan biaya implementasi.

DDD bukan dogma. Ia bukan tentang “semua harus punya domain model lengkap.” Ia adalah cara berpikir agar sistem kita mencerminkan realitas bisnis secukupnya — tidak kurang, tapi juga tidak berlebihan.

“Heuristics are not rules — they are good advice for most situations.” — Vlad Khononov, Learning Domain-Driven Design (2022)

Prinsip Dasar 1: Gunakan Kompleksitas dengan Bijak

DDD diciptakan untuk domain yang kompleks secara bisnis, bukan sekadar teknis. Kalau sistem kamu hanya memindahkan data antar tabel tanpa aturan khusus, maka DDD penuh justru akan memperlambat tim.

Bayangkan sistem sederhana seperti user management, login, atau report generator. Fungsi-fungsi itu bisa selesai dengan cepat pakai pola Transaction Script atau Active Record.

Tapi ketika mulai muncul hal-hal seperti:

• “kalau pengguna premium, logika perhitungan komisinya berbeda,”

• “status langganan berubah otomatis tergantung perilaku,”

• “ada peraturan bisnis yang saling bertabrakan,”

maka itu tanda domain mulai kompleks. Dan di situlah Domain Model menjadi alat yang tepat.

Heuristik #1: Semakin kompleks logika bisnis, semakin layak DDD digunakan.

Prinsip Dasar 2: Model Harus Menghasilkan Nilai Bisnis

Kadang engineer terjebak membangun model yang indah tapi tidak berdampak. DDD tidak mengejar keindahan teknis, tapi kejelasan makna bisnis.

Sebelum membuat entitas, aggregate, atau event, selalu tanyakan:

“Apakah model ini membantu tim memahami atau memecahkan masalah bisnis?”

Kalau jawabannya tidak, mungkin kamu sedang membuat arsitektur demi arsitektur.

Contoh sederhana:

Katakan kita sedang membangun sistem pembelian tiket.

Model yang bermanfaat:

struct Ticket {
    id: u64,
    status: TicketStatus,
}

enum TicketStatus {
    Reserved,
    Paid,
    Cancelled,
}

Model yang “terlalu DDD tapi tidak berguna”:

struct TicketAggregate {
    id: u64,
    ticket_entity: TicketEntity,
    ticket_state: TicketState,
    ticket_repository: Arc<dyn Repository>,
}

Yang satu berbicara tentang tiket dan statusnya, yang lain berbicara tentang framework dan istilah arsitektur. Model yang baik selalu dekat dengan bahasa domain, bukan dengan jargon teknis.

Heuristik #2: Model yang baik berbicara dalam bahasa bisnis, bukan bahasa framework.

Prinsip Dasar 3: Pisahkan Domain yang Penting dari yang Biasa

Tidak semua bagian sistem punya nilai strategis yang sama. Beberapa bagian adalah core domain — di sanalah keunggulan kompetitif bisnis berada. Yang lain hanyalah supporting atau bahkan generic subdomain.

Gunakan tenaga DDD di tempat yang paling berdampak.

Jenis Domain Fokus Pendekatan Core Domain Inovasi, keunggulan kompetitif Domain Model penuh (DDD taktis lengkap) Supporting Domain Mendukung operasi Pola sederhana seperti Active Record Generic Domain Umum untuk semua bisnis Gunakan library atau SaaS

Contoh nyata:

• Core Domain: algoritme rekomendasi di e-commerce.

• Supporting Domain: sistem pembayaran internal.

• Generic Domain: login, autentikasi, logging.

Heuristik #3: Investasikan DDD di tempat yang memberi nilai strategis terbesar.

Prinsip Dasar 4: Jangan Jadikan DDD Sebagai Target, Tapi Sebagai Alat

Engineer yang baru mengenal DDD sering terlalu semangat: semua hal dibuat Aggregate, semua entitas punya Repository, semua event dicatat.

Padahal DDD bukan checklist, melainkan toolbox. Gunakan hanya alat yang relevan untuk masalah di depan mata.

Heuristik #4: DDD bukan tujuan akhir, melainkan sarana untuk memahami dan menyelesaikan kompleksitas.

Ciri bahwa kamu terlalu jauh: model makin abstrak, tapi semua orang di tim justru makin bingung. Ciri bahwa kamu tepat: model membantu tim berdebat tentang bisnis, bukan tentang kode.

Prinsip Dasar 5: Evolve, Don’t Freeze

Model domain bukan kontrak permanen. Ia seharusnya tumbuh bersama pemahaman bisnis.

Ketika aturan bisnis berubah, biarkan model ikut berevolusi. Jangan terjebak pada rasa takut “merusak arsitektur yang sudah rapi.”

Heuristik #5: Model yang hidup lebih berguna daripada model yang sempurna.

Misalnya, awalnya kamu hanya punya dua status pembayaran: Pending dan Paid. Lalu muncul kebutuhan “Refunded”. Tambahkan saja, meskipun awalnya belum semua proses mendukung.

enum PaymentStatus {
    Pending,
    Paid,
    Refunded,
}

Model berkembang, pengetahuan bertambah — persis seperti bisnisnya.

Prinsip Dasar 6: Biarkan Bounded Context Mengatur Diri Sendiri

Ketika sistem tumbuh besar, mudah tergoda membuat “model universal” yang bisa dipakai semua tim. Padahal itu berbahaya.

Model yang terlalu umum akan kehilangan makna di setiap konteks. Lebih baik setiap bounded context punya modelnya sendiri — walau istilahnya sama tapi maknanya berbeda.

Contoh nyata:

• Di Sales Context, “Customer” berarti orang yang membeli produk.

• Di Support Context, “Customer” berarti orang yang sedang punya tiket bantuan aktif.

Keduanya sah. Yang penting, mereka tidak saling memaksakan makna.

Heuristik #6: Hargai otonomi bounded context — lebih baik model ganda yang jelas daripada model tunggal yang membingungkan.

Prinsip Dasar 7: Arsitektur Ada untuk Melayani Domain

Jangan biarkan framework atau pola arsitektur membatasi desain domain. Ingat bahwa model domain adalah pusat dari sistem, bukan lapisan di bawah framework.

Kalau framework ORM memaksa semua entitas harus punya id integer, padahal di domain kamu lebih masuk akal pakai code sebagai identitas, maka ubahlah framework, bukan domainnya.

struct Product {
    code: String, // Bukan ID auto-increment
    name: String,
}

Heuristik #7: Framework boleh diganti, domain tidak.

Prinsip Dasar 8: Ubiquitous Language Adalah Tes Terbaik

Kalau kamu ingin tahu seberapa sehat model domainmu, lihat bagaimana tim berbicara tentang bisnisnya.

Kalau engineer, PM, dan ahli domain bisa bicara tentang “Order”, “Refund”, dan “Shipment” tanpa kebingungan — artinya modelmu sudah bekerja. Kalau tiap meeting diwarnai “maksud kamu order yang di database atau order yang di API?”, artinya modelmu butuh perbaikan.

Heuristik #8: Jika bahasa di kode dan di percakapan bisnis sama, kamu sedang menerapkan DDD dengan benar.

Ringkasnya, Pragmatism is the Real DDD

DDD bukan sekadar teori elegan untuk sistem besar. Ia adalah cara berpikir untuk memastikan bahwa software yang kita bangun selalu berbicara tentang bisnis, bukan sekadar data.

Namun, setiap engineer yang matang tahu:

• Tidak semua sistem butuh domain model penuh,

• Tidak semua konteks perlu aggregate,

• Dan tidak semua tim siap hidup dengan kompleksitas DDD sejak hari pertama.

Gunakan heuristics sebagai kompas, bukan peta mutlak. Tugas kita bukan membuat DDD sempurna, tapi membuat sistem yang bermakna, terpelihara, dan berumur panjang.

“The goal of DDD is not to apply all its patterns, but to use the right ones, in the right context, for the right reasons.” — Vlad Khononov, Learning Domain-Driven Design (2022)

Referensi

Khononov, V. (2022). Learning Domain-Driven Design: Aligning Software Architecture and Business Strategy. O’Reilly Media.

“Bagaimana kalau model kita harus berkomunikasi dengan model dari tim lain?”

Dalam organisasi besar, setiap tim biasanya bekerja di bounded context yang berbeda, masing-masing dengan bahasa, istilah, dan prioritasnya sendiri. Tantangannya adalah bagaimana bounded context ini bisa saling berbicara tanpa saling merusak model satu sama lain.

Di sinilah communication patterns dalam DDD berperan. Ia membantu kita menjembatani dunia yang berbeda, agar integrasi antar sistem tidak membuat domain model kita rusak atau kehilangan makna.

Mengapa Komunikasi Itu Rumit

Komunikasi antara bounded context bukan sekadar “kirim data lewat API”. Masalah sebenarnya bukan di teknologinya, tapi di perbedaan makna.

Bayangkan dua tim:

• Tim Sales menggunakan istilah “Customer” untuk siapa pun yang pernah melakukan transaksi.

• Tim Support menyebut “Customer” hanya untuk pengguna aktif yang punya kontrak dukungan.

Ketika kedua sistem bertukar data tentang Customer, data itu mungkin valid secara teknis, tapi salah makna secara bisnis. Itulah mengapa DDD menekankan bahwa komunikasi antar bounded context harus punya kontrak yang jelas, baik secara teknis maupun semantik.

Hubungan Upstream dan Downstream

Dalam DDD, hubungan antar bounded context digambarkan seperti aliran sungai:

• Upstream → konteks yang mengirim data atau keputusan,

• Downstream → konteks yang menerima dan menyesuaikan diri dengan upstream.

Hubungan ini penting karena menentukan arah pengaruh, siapa yang memengaruhi siapa.

Contoh sederhana

Misalnya ada dua tim:

• Team Orders mengelola pemesanan pelanggan.

• Team Shipping mengurus pengiriman barang.

Ketika pesanan dikonfirmasi, Orders mengirim event ke Shipping untuk memulai proses pengiriman.

Orders (upstream) ---> Shipping (downstream)

Jika tim Orders mengubah format event tanpa koordinasi, tim Shipping akan terkena dampaknya. Jadi, downstream selalu lebih sensitif terhadap perubahan upstream. Inilah mengapa kita perlu communication pattern yang tepat, untuk mengatur dinamika semacam ini.

Pola-Pola Komunikasi antar Context

DDD memperkenalkan beberapa pola utama untuk menggambarkan cara bounded context saling berinteraksi. Masing-masing mencerminkan tingkat kolaborasi dan kekuasaan yang berbeda.

1. Partnership

Dalam Partnership, dua tim bekerja sangat erat, mereka berbagi tujuan dan menegosiasikan setiap perubahan bersama.

Mereka bisa dianggap “sekutu” yang membangun solusi bersama, dengan jadwal rilis dan kontrak yang disepakati dua arah.

“Changes are negotiated together.” — Vlad Khononov (2022)

Pola ini cocok bila dua sistem bergantung kuat satu sama lain dan punya siklus hidup yang sinkron. Misalnya antara tim “Billing” dan “Subscription” di platform SaaS.

Tantangannya: koordinasi butuh komunikasi intensif, jadi lebih cocok untuk organisasi kecil atau modul yang sangat terintegrasi.

2. Customer–Supplier

Dalam pola ini, supplier menyediakan data atau layanan yang digunakan oleh customer. Supplier biasanya memiliki kekuasaan lebih besar karena menentukan struktur data dan kontrak API.

“When the supplier has the power.” — Khononov (2022)

Jika tim supplier berubah, tim customer harus menyesuaikan diri.

Untuk melindungi domain model-nya sendiri, tim customer bisa membuat Anticorruption Layer (ACL), lapisan penerjemah antara model supplier dan model internalnya.

Contoh:

// Model dari supplier (mungkin dari API eksternal)
struct ExternalOrder {
    order_id: String,
    value: f64,
}

// Model internal di domain kita
struct InternalOrder {
    id: u64,
    total: f64,
}

// Anticorruption Layer (penerjemah)
impl From<ExternalOrder> for InternalOrder {
    fn from(eo: ExternalOrder) -> Self {
        InternalOrder { id: eo.order_id.parse().unwrap(), total: eo.value }
    }
}

ACL memastikan model domain kita tidak terkontaminasi oleh model pihak lain. Domain kita tetap bersih, meskipun harus berinteraksi dengan dunia luar.

3. Conformist

Kadang, tim downstream tidak punya pilihan selain menyesuaikan diri sepenuhnya dengan upstream, baik format data, struktur model, maupun jadwal rilisnya.

Inilah pola Conformist. Pola ini sering muncul saat:

• Sistem upstream adalah produk eksternal atau pihak ketiga.

• Atau tim downstream terlalu kecil untuk memengaruhi perubahan di upstream.

Misalnya, sistem kita membaca data dari layanan pemerintah atau vendor eksternal — mau tidak mau, kita harus “conform”.

Walau kurang ideal, Conformist tetap bisa dikelola dengan baik asalkan dokumentasi kontraknya jelas.

4. Open Host Service dan Published Language

Kadang, satu bounded context melayani banyak konsumen. Daripada menyesuaikan diri dengan masing-masing, lebih efisien kalau dia menyediakan satu antarmuka publik yang stabil.

Pola ini disebut Open Host Service, dan bahasa komunikasinya disebut Published Language.

• Open Host Service → API publik yang terbuka untuk konsumsi banyak sistem.

• Published Language → format data dan istilah yang disepakati (misalnya JSON schema, gRPC proto, atau message contract).

Contoh sederhana:

// Published Language: kontrak publik API
#[derive(serde::Serialize)]
struct OrderDto {
    order_id: u64,
    total: f64,
    status: String,
}

Dengan Published Language, upstream tidak perlu menyesuaikan setiap downstream. Semua berkomunikasi lewat kontrak publik yang stabil, mirip seperti “bahasa diplomatik” antar negara.

5. Separate Ways

Tidak semua bounded context harus saling bicara. Kadang, lebih baik mereka berjalan sendiri-sendiri dengan domain model masing-masing.

Pola Separate Ways digunakan saat:

• Integrasi terlalu rumit dibanding manfaatnya,

• Atau dua sistem hanya berbagi data secara sinkronisasi batch, bukan real-time.

“Sometimes the cost of integration outweighs the benefits.” — Khononov (2022)

Dalam praktiknya, ini justru bisa lebih efisien: tim jadi bebas bereksperimen dan merilis fitur tanpa bergantung satu sama lain.

Menggunakan Context Map

Untuk memvisualisasikan hubungan antar bounded context dan pola komunikasinya, DDD menggunakan Context Map — semacam peta hubungan antar tim atau sistem.

Contohnya:

[Sales Context] ---> [Shipping Context] ---> [Support Context]
       |                   |                       |
    (Customer–Supplier)  (Partnership)         (Separate Ways)

Context Map membantu kita menjawab:

• Siapa upstream, siapa downstream?

• Pola komunikasi apa yang digunakan?

• Siapa yang perlu berkoordinasi untuk perubahan?

Dengan peta ini, arsitektur organisasi menjadi lebih transparan, dan konflik semantik bisa diantisipasi sejak awal.

Ketika Komunikasi Gagal

Kesalahan paling umum dalam integrasi antar context adalah menganggap komunikasi sekadar urusan teknis. Padahal, communication patterns adalah tentang hubungan antar manusia dan tim, bukan hanya antar sistem.

Masalah seperti:

• “API-nya berubah sepihak,”

• “Istilah ‘customer’ di mereka artinya beda,”

• atau “Kita tidak tahu kapan upstream akan rilis versi baru,” semuanya berakar pada komunikasi lintas domain yang buruk.

DDD mengajarkan bahwa solusi teknis harus lahir dari kesepahaman semantik dan kolaborasi antar tim.

Ringkasnya, Komunikasi yang Berarti

Setiap bounded context adalah dunia kecil dengan bahasanya sendiri. Tapi dunia ini tidak bisa hidup sendirian, ia harus berbicara dengan dunia lain.

Communication patterns membantu kita menjaga agar percakapan itu bermakna dan sehat, bukan sekadar pertukaran data.

Arsitektur yang bagus melindungi model dari gangguan teknis, tapi komunikasi yang bagus melindungi model dari kesalahpahaman makna.

Dan pada akhirnya, seperti yang sering diingatkan Khononov: “Domain-Driven Design bukan hanya tentang model dan kode, tapi tentang orang-orang yang berbicara dengan bahasa yang sama.”

Referensi

Khononov, V. (2022). Learning Domain-Driven Design: Aligning Software Architecture and Business Strategy. O’Reilly Media.

Inilah peran architecture patterns, arsitektur perangkat lunak yang membantu memisahkan logika bisnis dari hal-hal teknis, agar domain model tidak tenggelam di tengah “kebisingan” infrastruktur.

Arsitektur Itu Bukan Soal Layer Saja

Kebanyakan engineer mendengar kata “arsitektur” lalu langsung berpikir tentang layered architecture, lapisan presentasi, logika bisnis, dan data. Padahal, arsitektur dalam konteks DDD bukan cuma soal membagi layer, tapi menentukan bagaimana model domain berinteraksi dengan bagian lain dari sistem.

Arsitektur adalah cara menjaga agar domain model tetap berdaulat, tidak dikendalikan oleh framework, database, atau API eksternal.

Dalam DDD, domain model adalah “raja”, dan arsitektur adalah istana yang melindunginya.

Mengapa Butuh Pola Arsitektur?

Tanpa pola arsitektur yang jelas, kode domain akan cepat “tercemar” oleh hal-hal teknis. Awalnya mungkin cuma satu query SQL di dalam entitas, lalu satu logika HTTP handler di service. Lama-lama model domain kehilangan fokus, menjadi campuran antara logika bisnis, UI, dan infrastruktur.

Inilah yang menyebabkan Big Ball of Mud, sistem yang sulit dipahami karena semua bagian saling menempel tanpa batas yang jelas.

Pola arsitektur membantu kita menetapkan batas tanggung jawab (separation of concerns) antara:

• Domain logic (apa yang bisnis lakukan),

• Application logic (kapan bisnis dijalankan),

• dan Infrastructure logic (bagaimana bisnis dijalankan di dunia nyata).

Beberapa Pola Arsitektur Umum

Buku Khononov (2022) membahas beberapa pola arsitektur yang sering digunakan dalam implementasi DDD: Layered Architecture, Ports and Adapters (Hexagonal Architecture), dan CQRS. Mari kita bahas satu per satu dengan contoh sederhana.

1. Layered Architecture, Struktur Paling Umum

Arsitektur berlapis ini mungkin paling dikenal. Biasanya terdiri dari tiga atau empat lapisan:

+------------------------+
|   Presentation Layer   |
+------------------------+
|   Application Layer    |
+------------------------+
|   Domain Layer         |
+------------------------+
|   Infrastructure Layer |
+------------------------+

• Presentation Layer Menangani interaksi dengan pengguna atau sistem lain (API, UI, CLI).

• Application Layer Mengatur flow atau urutan operasi — kapan bisnis dieksekusi.

• Domain Layer Tempat Entity, Value Object, dan Domain Service berada.

• Infrastructure Layer Berisi detail teknis seperti database, file system, atau network.

Contoh sederhana (Rust):

// Domain Layer
struct Order {
    id: u64,
    total: f64,
}

impl Order {
    fn confirm(&mut self) {
        println!("Order {} dikonfirmasi", self.id);
    }
}

// Application Layer
fn confirm_order(order_repo: &mut impl OrderRepository, id: u64) {
    if let Some(mut order) = order_repo.find_by_id(id) {
        order.confirm();
        order_repo.save(order);
    }
}

// Infrastructure Layer
trait OrderRepository {
    fn find_by_id(&self, id: u64) -> Option<Order>;
    fn save(&mut self, order: Order);
}

Layered architecture mudah dipahami, cocok untuk banyak aplikasi. Namun, jika tidak dijaga dengan disiplin, lapisan bisa bocor, logika bisnis sering naik ke Application Layer atau turun ke Infrastructure Layer.

2. Ports and Adapters (Hexagonal Architecture)

Kadang disebut juga Hexagonal Architecture, pola ini dikembangkan oleh Alistair Cockburn. Tujuannya: memisahkan domain dari dunia luar lewat port (antarmuka) dan adapter (implementasi teknis).

Bayangkan domain sebagai inti heksagon, dan setiap sisi dihubungkan oleh “port” yang bisa dipasang atau dilepas sesuai kebutuhan: API, database, atau event queue.

           +-----------------------+
           |    Presentation API   |
           +-----------+-----------+
                       |
         +-------------+-------------+
         |       Domain Core         |
         | (Entities, Services, etc) |
         +-------------+-------------+
                       |
           +-----------+-----------+
           | Infrastructure / DB   |
           +-----------------------+

Kuncinya: Domain tidak tahu siapa yang memanggilnya, dan tidak peduli siapa yang menyimpan datanya.

Contoh sederhana (Rust):

// Port (interface)
trait PaymentGateway {
    fn pay(&self, amount: f64) -> bool;
}

// Domain core
struct PaymentService<'a> {
    gateway: &'a dyn PaymentGateway,
}

impl<'a> PaymentService<'a> {
    fn process(&self, amount: f64) {
        if self.gateway.pay(amount) {
            println!("Pembayaran berhasil!");
        } else {
            println!("Pembayaran gagal.");
        }
    }
}

// Adapter (implementasi)
struct FakeGateway;

impl PaymentGateway for FakeGateway {
    fn pay(&self, _amount: f64) -> bool {
        true
    }
}

Dengan pola ini, kita bisa mengganti implementasi PaymentGateway tanpa menyentuh kode domain. Mau pakai Midtrans, Stripe, atau simulator lokal, tinggal ganti adapter-nya.

3. CQRS (Command Query Responsibility Segregation)

CQRS memisahkan dua jenis operasi utama sistem:

• Command → mengubah data (buat, ubah, hapus).

• Query → membaca data.

Tujuannya agar keduanya bisa berevolusi dengan kebutuhan berbeda, misalnya skala, performa, atau keamanan.

Dalam sistem sederhana, Command dan Query bisa digabung. Tapi dalam sistem kompleks, pemisahan ini membuat sistem lebih efisien dan mudah dioptimasi.

Contoh sederhana (Rust):

// Command handler
fn confirm_order(order_repo: &mut impl OrderRepository, id: u64) {
    if let Some(mut order) = order_repo.find_by_id(id) {
        order.confirm();
        order_repo.save(order);
    }
}

// Query handler
fn get_order_details(order_repo: &impl OrderRepository, id: u64) -> Option<Order> {
    order_repo.find_by_id(id)
}

Kita bisa punya dua pipeline terpisah, satu untuk memproses perubahan, satu untuk membaca data (misalnya dari cache atau database yang dioptimalkan untuk query). CQRS sering dikombinasikan dengan Event Sourcing agar setiap perubahan bisa dilacak dengan mudah.

Memilih Pola yang Tepat

Tidak ada arsitektur yang “paling benar.” Pola yang ideal tergantung dari:

• Kompleksitas domain,

• Skala sistem,

• Kebutuhan integrasi, dan

• Tim yang mengelola.

Sebagai panduan umum:

• Gunakan Layered Architecture untuk sistem yang masih tumbuh.

• Gunakan Hexagonal Architecture jika ingin model domain benar-benar independen dari framework atau infrastruktur.

• Gunakan CQRS bila ada kebutuhan pemisahan beban baca/tulis yang signifikan.

Menghindari Arsitektur yang Membelenggu

Sering kali engineer terjebak pada arsitektur yang mereka anggap “suci”, sampai akhirnya domain model malah dikorbankan demi mematuhi struktur. DDD justru sebaliknya: arsitektur harus melayani domain, bukan sebaliknya.

Kuncinya adalah menjaga boundaries tetap jelas, tapi tidak kaku. Ketika model domain berkembang, arsitektur boleh ikut menyesuaikan, selama tujuannya sama: melindungi logika bisnis dari gangguan teknis.

Ringkasnya, Arsitektur Sebagai Penjaga Makna

Arsitektur bukan tentang folder, file, atau diagram. Ia tentang cara melindungi makna bisnis di dalam sistem kita.

Layer, port, dan adapter hanyalah alat untuk memastikan kode kita tetap bercerita tentang domain, bukan tentang framework. Karena pada akhirnya, sistem yang paling bertahan lama bukan yang paling modern arsitekturnya, tapi yang paling setia pada makna bisnis yang dilayaninya.

Referensi

Khononov, V. (2022). Learning Domain-Driven Design: Aligning Software Architecture and Business Strategy. O’Reilly Media.

Setelah kita membangun fondasi Domain Model, lengkap dengan Entity, Value Object, Aggregate, Repository, dan kawan-kawan, muncul pertanyaan besar berikutnya: “Bagaimana model domain kita tetap relevan ketika bisnis berubah?”

Di dunia nyata, bisnis tidak pernah diam. Aturan baru muncul, prioritas berubah, bahkan istilah yang dulu dianggap jelas bisa bergeser maknanya. Maka, Domain Model pun harus tumbuh dan berevolusi. Bab ini membahas bagaimana kita bisa menyempurnakan model tanpa membuat sistem runtuh.

Model Domain Bukan Arsitektur Sekali Jadi

Kesalahan umum dalam menerapkan DDD adalah menganggap domain model sebagai desain permanen. Padahal, model itu seharusnya hidup dan berubah mengikuti pemahaman baru tentang domain.

Khononov (2022) menekankan bahwa DDD bukan tentang mencari model yang sempurna di awal, melainkan mendekati pemahaman yang lebih baik seiring waktu. Setiap diskusi dengan ahli domain, setiap bug, dan setiap fitur baru bisa memperkaya model kita.

Bayangkan model domain seperti peta kota. Saat pertama kali dibuat, mungkin hanya berisi jalan utama. Tapi seiring waktu, kita tambahkan gang kecil, lampu merah, dan area baru — bukan karena peta awal salah, tapi karena pengetahuan kita bertambah.

Proses Refinement: Dari Model Kasar ke Model Tajam

1. Mulai dari Model Kasar

Pada awal proyek, buatlah model sederhana dulu — tidak masalah kalau belum lengkap. Fokus pada pemahaman dasar: apa saja konsep utama dan bagaimana mereka berhubungan.

Misalnya kita membangun sistem untuk pengiriman paket. Model awal bisa sesederhana ini:

struct Package {
    id: u64,
    status: String,
}

impl Package {
    fn deliver(&mut self) {
        self.status = "Delivered".to_string();
    }
}

Masih sederhana, tapi cukup untuk memulai percakapan dengan ahli domain.

2. Kembangkan Melalui Umpan Balik

Setiap kali bisnis atau stakeholder memberi masukan (“Bagaimana kalau pelanggan bisa menjadwalkan ulang pengiriman?”), kita ubah model agar mencerminkan realitas baru itu.

enum DeliveryStatus {
    Pending,
    InTransit,
    Delivered,
    Rescheduled(String), // alasan atau tanggal baru
}

struct Package {
    id: u64,
    status: DeliveryStatus,
}

Model berkembang mengikuti kebutuhan bisnis, bukan sebaliknya. Perubahan ini adalah bentuk refinement, bukan “refactor tanpa arah”.

3. Evaluasi Bahasa Umum (Ubiquitous Language)

Setiap istilah di model harus sama artinya bagi semua pihak, engineer, product owner, dan ahli domain.

Kalau tim mulai bilang “Shipment” di tempat yang seharusnya “Package”, itu tanda bahasa umum mulai kabur. Periksa model, ubah nama kelas, fungsi, dan variabel agar kembali konsisten dengan istilah bisnis yang terbaru.

Inilah kenapa DDD mendorong kode yang “bercerita seperti domain”-nya.

Pola Umum dalam Evolusi Model

1. Split dan Merge Aggregate

Saat sistem bertumbuh, aggregate yang dulu terasa ideal bisa jadi terlalu besar. Kita mungkin perlu memisahkannya agar tidak menimbulkan transaction contention atau performance bottleneck.

Misalnya awalnya kita punya Order yang juga menyimpan Payment dan Shipment di dalamnya. Tapi seiring waktu, tim pembayaran dan pengiriman berkembang terpisah.

Maka kita pisahkan menjadi tiga aggregate dengan batas yang jelas.

// Awalnya semua di Order
struct Order {
    id: u64,
    payment_status: String,
    shipment_status: String,
}

// Setelah displit
struct Order {
    id: u64,
}

struct Payment {
    order_id: u64,
    status: String,
}

struct Shipment {
    order_id: u64,
    tracking_code: String,
}

Kini setiap tim bisa berinovasi di domain-nya tanpa saling menunggu.

2. Mengubah Entity menjadi Value Object (atau sebaliknya)

Kadang sebuah objek awalnya dianggap penting secara identitas, tapi belakangan ternyata tidak.

Contoh: pada tahap awal, kita buat Address sebagai Entity karena kita pikir pengguna bisa memperbaruinya dan kita perlu menyimpannya secara unik. Tapi kemudian kita sadar bahwa Address hanya bagian dari Order dan tidak pernah digunakan secara terpisah.

Maka kita ubah menjadi Value Object.

#[derive(Clone, PartialEq, Eq)]
struct Address {
    street: String,
    city: String,
    postal_code: String,
}

Sebaliknya, jika suatu saat kita butuh melacak alamat pelanggan secara historis, Address bisa dipromosikan lagi menjadi Entity.

3. Menambah Domain Event untuk Dekoupling

Ketika sistem makin besar, modul-modul akan saling tergantung. Untuk mencegah kekacauan, kita bisa menambahkan Domain Event agar komunikasi antarmodul tidak saling menempel.

struct OrderCreated {
    order_id: u64,
}

struct SendEmailOnOrderCreated;

impl SendEmailOnOrderCreated {
    fn handle(event: &OrderCreated) {
        println!("Email konfirmasi untuk order {} dikirim!", event.order_id);
    }
}

Dengan event, Order tidak perlu tahu cara mengirim email, dan modul notifikasi bisa bereaksi secara independen. Ini membuat sistem lebih fleksibel dan siap tumbuh tanpa coupling berlebihan.

Evolusi yang Terarah, Bukan Reaktif

Menumbuhkan model domain bukan berarti “sering ganti struktur kode”. Tujuannya bukan perubahan semata, tapi perubahan yang memperdalam pemahaman kita terhadap domain.

Langkah idealnya seperti ini:

1. Temukan masalah di dunia nyata. Misalnya pengguna bingung dengan istilah “shipment” vs “delivery”.

2. Diskusikan dengan ahli domain. Pahami maknanya dalam konteks bisnis.

3. Perbarui bahasa umum. Ubah nama kelas atau entitas agar konsisten dengan istilah baru.

4. Refactor model. Pisahkan, gabungkan, atau ubah struktur sesuai pemahaman baru.

5. Uji dan validasi. Pastikan perubahan tidak merusak perilaku bisnis yang sudah benar.

Jika perubahan dilakukan lewat percakapan yang intens antara engineer dan ahli domain, model domain akan terus “mendekati kenyataan” seiring waktu.

Kesalahan Umum Saat Model Berevolusi

1. Refactor teknis tanpa konteks bisnis. Mengubah struktur hanya karena “terlihat lebih bersih”, padahal maknanya makin kabur.

2. Terlalu cepat memecah aggregate. Split boleh dilakukan, tapi pastikan memang ada kebutuhan bisnis atau beban transaksi nyata.

3. Mengabaikan bahasa umum. Nama-nama di kode harus tetap sejalan dengan istilah di dunia nyata, bukan dengan preferensi pribadi.

4. Tidak mencatat keputusan. Setiap perubahan besar di domain model sebaiknya punya alasan bisnis yang terdokumentasi.

Menumbuhkan Model Secara Aman

Dalam praktik modern, kita bisa menggunakan pendekatan seperti:

• Feature toggles, untuk mengaktifkan model baru tanpa mengganggu produksi.

• Event sourcing, agar perubahan model tidak kehilangan jejak historis.

• Migration scripts, untuk memindahkan data lama ke struktur baru dengan aman.

DDD tidak menentang perubahan, ia justru mengajarkan cara mengelolanya dengan sadar.

Akhirnya: Model yang Hidup

Domain model yang baik bukan yang paling indah diagramnya, tapi yang tetap bernapas bersama bisnisnya.

Ketika bisnis berubah, model pun ikut beradaptasi. Ketika istilah baru muncul, kode pun ikut menyesuaikan. Dan ketika engineer dan ahli domain berbicara, mereka bicara dalam bahasa yang sama, bukan lagi sekadar query, tapi makna.

Itulah esensi menghadapi kompleksitas: Bukan melawannya dengan abstraksi berlebihan, tetapi menjinakkannya dengan pemahaman yang terus bertumbuh.

Referensi

Khononov, V. (2022). Learning Domain-Driven Design: Aligning Software Architecture and Business Strategy. O’Reilly Media.

Dari Strategi ke Taktik

Dalam DDD, ada dua lapisan pendekatan: Strategic DDD dan Tactical DDD.
Strategic DDD membantu kita memetakan peta besar, membagi sistem menjadi domain, subdomain, dan bounded context.
Sementara Tactical DDD berbicara tentang bagaimana kita membangun isi di dalam satu bounded context itu.

Kalau Strategic DDD seperti membuat denah kota, maka Tactical DDD adalah merancang bangunan di dalam tiap distrik: siapa penghuni, bagaimana alurnya, dan aturan apa yang berlaku di dalamnya.

Domain Model: Jantung dari DDD

Sebuah domain model bukan sekadar diagram UML atau tabel database.
Ia adalah representasi konseptual dari cara bisnis bekerja, diterjemahkan ke dalam kode, menggunakan bahasa yang sama dengan yang digunakan oleh para ahli domain.

Model ini bukan hanya soal data structure, tapi juga soal perilaku (behavior) dan aturan (rules) yang melekat di dalamnya.

Contoh sederhana:
Bayangkan kita membuat sistem untuk toko online. Ada entitas Order, tapi Order bukan cuma tabel dengan kolom id, total, dan status.
Ia harus tahu bagaimana:

• menambahkan item,

• menghitung total,

• memastikan tidak ada duplikasi produk,

• dan kapan pesanan bisa dikonfirmasi.

Model yang baik berarti kode kita bicara seperti bisnisnya.

Entity

Salah satu elemen paling penting dari domain model adalah Entity, sebuah objek yang punya identitas unik dan bisa berubah seiring waktu.

Misalnya, User dengan ID 123 tetap sama orangnya meski alamat atau emailnya berubah.
Yang menentukan dirinya adalah identitas, bukan nilainya.

struct User {
    id: u64,
    name: String,
    email: String,
}

impl User {
    fn change_email(&mut self, new_email: String) {
        self.email = new_email;
    }
}

Di sini User adalah Entity karena kita mengenalinya lewat id.
Ketika change_email() dipanggil, objek ini masih “orang yang sama”.

Value Object

Berbeda dengan Entity, Value Object tidak punya identitas.
Ia hanya penting karena nilainya. Dua objek yang nilainya sama dianggap sama.

Coba pikirkan Money, Address, atau DateRange.
Kalau kamu punya Money { amount: 100, currency: “USD” }, itu identik dengan objek lain yang punya nilai sama.

#[derive(Debug, Clone, PartialEq, Eq)]
struct Money {
    amount: f64,
    currency: String,
}

Value Object biasanya immutable, artinya nilainya tidak diubah, tapi dibuat baru saat ada perubahan.
Pendekatan ini membuat kode lebih aman dan mudah diprediksi.

Aggregate

Saat bisnis mulai kompleks, satu entitas tidak lagi cukup.
Kita butuh sekumpulan entitas dan value object yang bekerja bersama dalam satu batas konsistensi.
Inilah yang disebut Aggregate.

Aggregate adalah kumpulan objek yang dikelola sebagai satu kesatuan logis, dengan satu titik masuk utama yang disebut Aggregate Root.

struct OrderItem {
    product_id: u64,
    quantity: u32,
}

struct Order {
    id: u64,
    items: Vec<OrderItem>,
}

impl Order {
    fn add_item(&mut self, product_id: u64, quantity: u32) {
        self.items.push(OrderItem { product_id, quantity });
    }

    fn total_items(&self) -> usize {
        self.items.len()
    }
}

Order di atas adalah Aggregate Root — semua perubahan terhadap OrderItem harus melalui Order.
Aggregate membantu menjaga aturan bisnis tetap konsisten di dalam batasnya.

Repository

Domain Model tidak seharusnya tahu tentang database atau API.
Tapi tentu kita tetap perlu menyimpan data.
Untuk itu, DDD memperkenalkan Repository.

Repository berfungsi sebagai “pintu keluar masuk” Aggregate.
Dari sisi domain, Repository terlihat seperti koleksi di memori, meski di baliknya mungkin ada SQL, file, atau service eksternal.

trait OrderRepository {
    fn save(&self, order: &Order);
    fn find_by_id(&self, id: u64) -> Option<Order>;
}

Dengan pola ini, domain tetap bersih dari detail teknis.
Kita bisa mengganti penyimpanan dari SQLite ke PostgreSQL tanpa mengubah logika bisnis sedikit pun.

Domain Service

Kadang kita menemukan logika bisnis yang tidak cocok dimasukkan ke satu entitas mana pun.
Misalnya, proses transfer uang antar akun: melibatkan dua Account, tapi tidak ada satu pun yang benar-benar “memiliki” logika itu.

Inilah peran Domain Service, tempat untuk menaruh logika lintas entitas.

struct Account {
    id: u64,
    balance: f64,
}

struct TransferService;

impl TransferService {
    fn transfer(from: &mut Account, to: &mut Account, amount: f64) {
        if from.balance >= amount {
            from.balance -= amount;
            to.balance += amount;
        }
    }
}

Domain Service tetap bagian dari domain layer, bukan service teknis seperti API handler atau queue worker.
Ia merepresentasikan aksi bisnis, bukan infrastruktur.

Factory

Membuat entitas kadang tidak sesederhana memanggil new().
Ada validasi, aturan bisnis, atau dependensi lain.
Di sinilah Factory digunakan.

Factory bertugas membangun objek kompleks dengan aturan bisnis yang benar sejak awal.

struct OrderFactory;

impl OrderFactory {
    fn create_new(items: Vec<OrderItem>) -> Order {
        assert!(!items.is_empty(), “Order harus punya minimal satu item”);
        Order { id: 0, items }
    }
}

Factory mencegah kita membuat objek domain dalam keadaan “tidak valid”.
Ia seperti dapur yang memastikan masakan sudah matang sebelum dihidangkan.

Domain Event

Dalam kehidupan nyata, setiap sistem bisnis penuh dengan peristiwa: pesanan dibuat, pembayaran diterima, stok habis, dsb.
DDD merepresentasikan semua itu lewat Domain Event.

Event adalah sinyal bahwa sesuatu yang penting sudah terjadi di dalam domain.
Biasanya diberi nama dengan bentuk lampau: OrderCreated, PaymentReceived.

struct OrderCreated {
    order_id: u64,
    timestamp: u64,
}

Event bisa dikirim ke bagian lain dari sistem (misalnya ke modul pengiriman atau notifikasi) tanpa membuat coupling langsung antar komponen.
Hasilnya: sistem lebih fleksibel dan modular.

Menghadapi Kompleksitas

Setiap sistem yang tumbuh pasti akan menjadi kompleks.
Tactical DDD memberi kita alat untuk mengelola kompleksitas itu, bukan menyingkirkannya.

• Entity dan Value Object membantu kita berpikir dalam istilah bisnis, bukan tabel.

• Aggregate menjaga aturan tetap konsisten.

• Repository dan Factory memisahkan logika domain dari teknis.

• Domain Service dan Event membuat sistem bisa berkembang tanpa kekacauan.

Inilah inti filosofi DDD: “Kode bukan cuma alat, tapi cerminan dari cara kita memahami bisnis.”

Ketika model domain dibuat dengan benar, engineer tidak hanya menulis kode, mereka mengkodekan pengetahuan bisnis yang bisa bertahan bertahun-tahun, bahkan ketika framework atau teknologi berubah.

Referensi

Khononov, V. (2022). Learning Domain-Driven Design: Aligning Software Architecture and Business Strategy. O’Reilly Media.

Business Logic

Logika bisnis (business logic) adalah bagian dari sistem yang menentukan bagaimana data diproses sesuai aturan dan tujuan bisnis.

Secara definisi:

Business logic adalah sekumpulan keputusan, kalkulasi, kondisi, dan alur kerja yang menjelaskan bagaimana bisnis seharusnya beroperasi dalam konteks sistem perangkat lunak.

Contoh:

• Jika saldo rekening < 0 → tolak transaksi.

• Jika pelanggan sudah bayar → ubah status pesanan menjadi “confirmed.”

• Jika total belanja > 1 juta → berikan diskon 10%.

Semua ini bukan “aturan pemrograman umum,” tapi cara bisnis tertentu berjalan.
Karena itu, business logic berbeda dari technical logic (seperti validasi input, autentikasi pengguna, caching, dll.).

Intinya: logika bisnis = perilaku sistem yang mencerminkan keputusan bisnis.

Business Rules

Istilah Business Rules dan Business Logic ini sering tertukar, padahal secara konsep ada perbedaan:

• Business Rules

  • Ciri utama: Prinsip atau kebijakan yang didefinisikan oleh organisasi, misalnya menjelaskan apa yang boleh dan tidak boleh terjadi di dunia nyata.

  • Contoh: Setiap transaksi harus memiliki nomor faktur unik.

• Business Logic

  • Ciri utama: Implementasi teknis dari aturan-aturan tersebut di dalam sistem.

  • Contoh: fn generate_invoice_id() memastikan nomor faktur tidak duplikat.

Singkatnya:

• Business rules = “aturan permainan” (bersifat deklaratif).

• Business logic = “cara memainkan permainan itu di sistem” (bersifat prosedural).

Dalam DDD, keduanya sama-sama penting:

• Aturan bisnis berasal dari pengetahuan ahli domain (domain expert).

• Logika bisnis diimplementasikan di kode (biasanya di entitas atau service dalam domain model).

Transaction Script

Secara definisi, Transaction Script adalah pola arsitektur di mana setiap operasi bisnis diimplementasikan sebagai satu prosedur atau fungsi tunggal.
Istilah aslinya berasal dari Patterns of Enterprise Application Architecture oleh Martin Fowler (2003).

Definisi: “Transaction Script organizes business logic by procedures where each procedure handles a single request from the presentation.”
— Martin Fowler, P of EAA, 2003.

Dengan kata lain:

• Setiap use case bisnis (misal “proses pembayaran”, “buat laporan”, “import data”) ditulis sebagai satu skrip atau fungsi.

• Logika bisnis disusun secara imperatif (langkah demi langkah).

• Tidak ada objek domain yang rumit — biasanya hanya sekumpulan operasi database.

Analogi: seperti membuat resep dapur dalam satu lembar kertas, semua langkahnya berurutan: ambil bahan, masak, sajikan. Simpel, tapi sulit dipakai ulang kalau resep makin kompleks.

Khononov (2022) menjelaskan bahwa Transaction Script mengorganisir logika bisnis ke dalam prosedur terpisah. Setiap prosedur (atau fungsi) menangani satu permintaan atau operasi bisnis.

Misalnya, fungsi process_payment() yang hanya fokus menyelesaikan satu transaksi pembayaran. Pendekatan ini gampang dipahami dan minim abstraksi. Contohnya, bayangkan kita punya daftar pekerjaan (job) yang perlu diproses satu per satu:

fn process_jobs(db: &Database) {
    db.start_transaction();
    if let Some(job) = db.load_next_job() {
        let data = std::fs::read_to_string(&job.source).unwrap();
        let result = convert_to_xml(&data);
        std::fs::write(&job.destination, result).unwrap();
        db.mark_complete(job.id);
    }
    db.commit();
}

Kode di atas menunjukkan satu prosedur sederhana: mulai transaksi, baca job berikutnya, ubah data, simpan hasil, lalu commit. Jika ada kesalahan di tengah, sistem harus rollback agar data tetap konsisten.

Khononov menegaskan pentingnya perilaku transaksional di setiap skrip: operasi harus sukses seluruhnya atau gagal tanpa meninggalkan kondisi setengah jadi. Karena itu, pola Transaction Script cocok untuk subdomain pendukung atau tugas ETL (Extract-Transform-Load) sederhana. Sebagai contoh, sinkronisasi data dari satu sistem ke sistem lain bisa diimplementasikan dengan skrip seperti di atas.

Kapan pakai Transaction Script? Beberapa poin penting:

• Cocok untuk subdomain pendukung atau generik di mana logika bisnisnya prosedural (misal batch job, laporan, sinkronisasi).

• Sederhana dan cepat: minim abstraksi, performa tinggi karena langsung panggil database (atau penyimpanan).

• Hati-hati: Jika logika bisnis makin kompleks, skrip terpisah cenderung duplikasi kode dan kesulitan pemeliharaan. Khononov bahkan menyebut pattern ini sering dianggap antipola (antipattern) karena bisa jadi “big ball of mud” jika dipakai di domain inti yang rumit. Jadi, jangan pakai Transaction Script untuk core subdomain yang punya banyak aturan bisnis, karena pola ini tidak tahan dengan kompleksitas tinggi.

Antipattern Arsitektur Big Ball of Mud

Ini adalah antipattern arsitektur yang menggambarkan sistem tanpa struktur yang jelas.

Definisi: “A Big Ball of Mud is a haphazardly structured system, tangled, and difficult to maintain.”
— Foote & Yoder, 1997.

Sederhananya:

• Semua kode bercampur tanpa batas yang jelas.

• Tidak ada pemisahan logika bisnis, data, dan presentasi.

• Setiap perubahan kecil bisa merusak bagian lain.

Dalam konteks pembahasan di atas:

Jika kita memaksa memakai Transaction Script atau Active Record untuk domain yang kompleks (seperti core subdomain), cepat atau lambat sistem akan jadi Big Ball of Mud.

Kenapa? Karena fungsi-fungsi akan saling memanggil, logika duplikat di mana-mana, dan tidak ada satu model mental yang jelas tentang “bagaimana bisnis bekerja” di dalam kode.

Active Record

Active Record juga berasal dari buku Fowler yang sama, dan definisinya adalah:

Definisi: “An object that wraps a row in a database table or view, encapsulates the database access, and adds domain logic on that data.”
— Martin Fowler, P of EAA, 2003.

Artinya:

• Setiap baris di tabel database direpresentasikan oleh sebuah objek.

• Objek itu “aktif” karena bisa menyimpan (save()), memperbarui (update()), atau menghapus (delete()) dirinya sendiri.

• Kadang juga memuat logika bisnis sederhana, seperti validasi atau penghitungan kecil.

Analogi: seperti lembar Excel di mana tiap baris bisa langsung “menyimpan dirinya ke server” begitu kita ubah isinya.

Active Record biasanya lebih rapi dari Transaction Script karena sudah mulai ada objek dan data berelasi, tapi belum punya pemisahan yang jelas antara data dan aturan bisnis.

Pola ini diperkenalkan oleh Fowler dan disitir Khononov (2022) sebagai objek yang “membungkus satu baris di tabel database, mengenkapsulasi akses database, dan menambah logika bisnis di data tersebut”. Artinya, setiap entitas data (misalnya baris User di tabel) direpresentasikan oleh sebuah objek yang punya metode sendiri, termasuk operasi save() atau update() ke database.

Active Record cocok ketika logika bisnis masih sederhana, tapi struktur datanya relatif rumit (misal relasi banyak-ke-banyak). Contohnya, kalau kita punya struct Rust User:

struct User {
    id: u32,
    name: String,
    email: String,
}

impl User {
    fn save(&self, conn: &DbConnection) {
        // Contoh sederhana: INSERT atau UPDATE ke DB
        conn.execute(”INSERT INTO users ...”, &[&self.name, &self.email]);
    }
    fn increment_logins(&mut self, conn: &DbConnection) {
        self.logins += 1;
        self.save(conn);
    }
}

Di sini, User bertindak sebagai active record: ia menyimpan datanya (id, name, dll.) dan punya method save() untuk persist ke database. Jika kita perlu modifikasi data kompleks, kita manipulasi objek User dan panggil user.save(conn) untuk update.

Menurut Khononov, tujuan pola ini adalah mengenkapsulasi kompleksitas pemetaan antara object ke skema database. Dibanding Transaction Script, skema Active Record menyediakan objek-objek khusus yang memuat data dan operasi CRUD mereka sendiri.

Kapan pakai Active Record? Beberapa poin:

• Logika masih sederhana (CRUD, validasi input ringan) tapi datanya lebih struktur.

• Berguna di subdomain pendukung/generik yang butuh konversi data kompleks ke model aplikasi.

• Intinya: Active Record adalah Transaction Script yang “hidup” – yaitu setiap operasi bisnis masih dilakukan di luar objek, tapi objek data punya save() sendiri. Ini punya kekurangan: logika bisnis tetap tersebar di layanan/prosedur, jadi sering disebut anemic domain model. Maka jangan gunakan di core subdomain yang seharusnya punya domain model penuh (full domain model).

Ringkasnya, bagian ini memberikan pemahaman bahwa untuk kasus sederhana kita bisa pakai Transaction Script atau Active Record. Keduanya ringan dan cepat diimplementasi, tapi terbatas pada logika sederhana di subdomain pendukung. Untuk core subdomain dengan banyak aturan, kita akan membahas pada pola Domain Model berikutnya.

Anemic Domain Model

Istilah ini juga dari Martin Fowler, dan Khononov menyinggungnya saat membandingkan Active Record dengan Domain Model.

Definisi: “Anemic Domain Model is a domain model where the business logic is absent and resides in services instead of the entities themselves.”
— Martin Fowler, 2003.

Artinya:

• Objek domain hanya menyimpan data (getter & setter).

• Logika bisnis tersebar di service/fungsi lain.

• Secara teknis modelnya ada, tapi secara semantik “kosong”.

Contoh dalam Rust:

struct Order {
    id: u32,
    total: f64,
    status: String,
}

fn confirm(order: &mut Order) {
    if order.total > 0.0 {
        order.status = “Confirmed”.to_string();
    }
}

Objek Order di sini tidak tahu apa-apa tentang bisnisnya sendiri.
Segala logika berada di luar (confirm()). Akibatnya, aturan bisnis bisa dengan mudah tersebar dan bertentangan.

DDD menolak pola ini karena tujuan DDD adalah memusatkan logika bisnis di dalam domain model, agar kode benar-benar mencerminkan pemikiran bisnis.

Full Domain Model

Dalam DDD, domain model penuh, istilah aslinya adalah “Rich Domain Model” atau “Full-Fledged Domain Model”.

Definisi: “A rich domain model is one where domain objects encapsulate both data and behavior, enforcing business rules internally.”
— Evans, Domain-Driven Design, 2004.

Bedanya dengan anemic domain model berdasarkan karakteristik:

• Rich (Full) Domain Model

  • Data dan perilaku: Digabung di entitas.

  • Aturan Bisnis: Ditegakkan di dalam entitas.

  • Keterwakilan domain: Kuat, selaras dengan bahasa bisnis.

  • Cocok untuk: Core subdomain.

• Anemic Domain Model

  • Data dan perilaku: Terpisah.

  • Aturan Bisnis: Tersebar di service luar.

  • Keterwakilan domain: Lemah, cenderung CRUD.

  • Cocok untuk: Supporting/generic subdomain.

Jadi ketika Khononov menulis bahwa “core subdomain seharusnya memiliki domain model penuh”, maksudnya adalah:

Subdomain yang menjadi keunggulan utama bisnis harus diimplementasikan dengan rich domain model, agar aturan bisnis dan konsep bisnis benar-benar hidup di dalam kode, bukan di spreadsheet, dokumen, atau service-service longgar.

Domain Model Berdasarkan Pola yang Cocok

Ada spektrum kompleksitas yang mempengaruhi pemilihan domain model yang cocok:

• Kondisi domain sangat sederhana (ETL, batch job, CRUD data referensi)

  • Pola yang cocok: Transaction Script.

  • Karena tidak perlu model atau logika kompleks.

• Kondisi domain sederhana tapi punya struktur data berelasi

  • Pola yang cocok: Active Record.

  • Karena sedikit OO, tapi mudah dan cepat.

• Kompleks dengan aturan bisnis yang dinamis

  • Pola yang cocok: Rich Domain Model.

  • Karena logika terpusat di entitas & aggregate.

• Butuh audit / histori

  • Pola yang cocok: Event-Sourced Domain Model.

  • Karena Domain Model + Event Sourcing.

Melihat Kembali Subdomain Pendukung (supporting subdomain)

Di atas banyak dibahas bahwa keduanya terbatas pada logika sederhana di subdomain pendukung. Kita lihat kembali klasifikasi subdomain pada DDD (Khononov, 2022):

• Core Subdomain

  • Karakteristik: Menjadi sumber keunggulan kompetitif bisnis. Kompleks, sering berubah, butuh inovasi tinggi.

  • Fokus solusi: Perlu desain DDD mendalam, domain model penuh, investasi besar.

• Supporting Subdomain

  • Karakteristik: Mendukung operasional inti, tapi tidak membedakan bisnis dari kompetitor. Biasanya sederhana.

  • Fokus solusi: Gunakan solusi pragmatis (Transaction Script, Active Record, atau framework siap pakai)

• Generic Subdomain

  • Karakteristik: Umum dipakai semua bisnis (contoh: autentikasi, log aktivitas).

  • Fokus solusi: Lebih baik dibeli atau pakai library standar.

Sederhananya:

• Supporting subdomain masih penting untuk bisnis, tapi tidak menentukan keberhasilan utama.

• Karena kompleksitasnya rendah dan nilai strategisnya kecil, maka kita tidak perlu investasi arsitektur rumit seperti Domain Model penuh.

• Inilah kenapa Transaction Script dan Active Record cocok: cepat dibuat, mudah dipelihara, cukup stabil.

Sebaliknya, core subdomain biasanya punya banyak aturan bisnis, ketergantungan lintas fungsi, dan terus berubah.

Data & Logika Bisnis

Pernyataan “pemisahan antara data dan logika bisnis“ ini sering muncul dalam konteks arsitektur software, misalnya Separation of Concerns.

Artinya: Data (apa yang disimpan) dan logika bisnis (apa yang dilakukan terhadap data itu) tidak seharusnya bercampur dalam satu tempat.

Contoh salah:

fn save_order_to_db(order_id: u32, total: f64) {
    // ... query ke DB ...
    if total > 1000000.0 {
        // logika bisnis diselipkan di sini
        println!(”Diskon 10%”);
    }
}

Contoh benar:

struct Order {
    id: u32,
    total: f64,
}

impl Order {
    fn apply_discount(&mut self) {
        if self.total > 1000000.0 {
            self.total *= 0.9;
        }
    }
}

fn save_order_to_db(order: &Order) {
    // hanya urusan penyimpanan
}

Pada contoh benar, fungsi save_order_to_db() hanya fokus pada data persistence, sedangkan apply_discount() berisi logika bisnis.
Keduanya terpisah untuk memudahkan pengujian, refaktor, dan perubahan aturan bisnis tanpa merusak cara penyimpanan data.

Pemisahan antara data, logika bisnis, dan presentasi adalah prinsip dasar arsitektur aplikasi, sering disebut sebagai three-layer (or three-tier) architecture.

• Presentation layer

  • Tugas utama: Menampilkan data kepada pengguna dan menerima input.

  • Contoh dalam aplikasi: Antarmuka pengguna (UI), web page, REST API endpoint, CLI.

• Business Logic layer

  • Tugas utama: Menjalankan aturan dan keputusan bisnis.

  • Contoh dalam aplikasi: Fungsi domain, service, entitas, aggregate.

• Data Access layer atau Persistence Layer

  • Tugas utama: menyimpan dan mengambil data.

  • Contoh dalam aplikasi: Database, ORM, repository.

Dalam konteks arsitektur, “presentation layer” mencakup segala sesuatu yang berhubungan dengan interaksi pengguna atau sistem lain. Misalnya:

• UI web atau mobile,

• API endpoint (yang melayani HTTP request),

• atau bahkan CLI untuk admin.

Presentasi tidak boleh tahu detail logika bisnis, cukup memanggil fungsinya saja.
Contoh:

// presentation layer
fn handle_checkout_request(user_input: CheckoutData) {
    let mut order = Order::new(user_input.items);
    order.apply_discount(); // business logic
    repository::save(order); // data layer
}

Ketiganya punya tanggung jawab berbeda:

• Presentation layer: berbicara dengan pengguna atau sistem lain.

• Business logic layer: memutuskan apa yang boleh atau harus terjadi.

• Data layer: mengelola penyimpanan (database, cache, dsb).

Prinsip ini disebut Separation of Concerns: memisahkan tanggung jawab agar sistem lebih modular dan mudah berkembang.

Referensi

Khononov, V. (2022). Learning Domain-Driven Design: Aligning Software Architecture and Business Strategy. O’Reilly Media.

Tergantung pada hubungan tim pengembangnya, DDD mengenalkan beberapa pola integrasi bounded context:

• Partnership (Kerjasama Dua Arah): Dua tim berkolaborasi erat, saling bantu menyesuaikan antarmuka jika dibutuhkan. Tidak ada pihak yang memaksakan modelnya; setiap perubahan disepakati atau dinegosiasikan bersama. Pola ini memerlukan komunikasi intensif dan mungkin Continuous Integration agar tiap perubahan cepat diuji bersama.

• Shared Kernel: Dua atau lebih bounded context berbagi sebagian model yang sama (misalnya model otorisasi pengguna). Perubahan di bagian bersama (kernel) langsung memengaruhi semua konteks. Oleh karena itu, hanya fitur inti yang benar-benar perlu yang sebaiknya digabungkan di sini, biasanya berupa kontrak integrasi atau struktur data bersama. Untuk implementasi, kode bersama bisa diletakkan di satu modul yang di-link oleh setiap konteks. Setiap perubahan mesti diuji secara lintas-konteks agar tidak ada yang rusak.

Kelompok berikutnya adalah Customer–Supplier, hubungan satu arah dengan tim penyuplai (supplier) dan tim pelanggan (customer):

• Conformist: Tim supplier mendikte modelnya dan tim pelanggan mengikuti begitu saja. Misalnya, jika API yang disediakan rekanan sudah baku, tim kita mungkin cuma mengonsumsi mentah-mentah data itu tanpa negosiasi. Pola ini tidak memerlukan adaptasi besar; tim pelanggan menerima persyaratan supplier seperti adanya. Biasanya cocok untuk model standar industri yang cukup baik dan tidak ingin diubah.

• Anticorruption Layer (ACL), Jika tim supplier berkuasa penuh, tetapi modelnya tidak cocok atau sering berubah (misal sistem warisan dengan schema kacau), tim pelanggan bisa membuat lapisan perantara (translator) yang menerjemahkan model supplier ke model sendiri. Misalnya, jika subdomain kita termasuk inti yang rumit, kita tidak mau ikut-ikutan merusak modelnya. Atau jika kontrak sering berubah, ACL menjaga agar perubahan itu hanya mengganggu translator, bukan seluruh sistemnya. Intinya, ACL mengisolasi konteks kita dari istilah asing dan membuat model kita lebih bersih sesuai kebutuhan.

• Open-Host Service: Kebalikan dari ACL, di sini supplier melindungi pelanggannya. Supplier membuat model publik (published language) yang nyaman bagi konsumen, lalu menjembatani model internalnya ke model publik tersebut. Dengan begitu, supplier dapat mengubah model internalnya tanpa mengganggu konsumen, asalkan masih menerjemahkannya ke bahasa publik yang sudah ditetapkan. Pola ini sering digunakan jika supplier ingin memberi layanan yang stabil bagi banyak konsumen sekaligus.

Terakhir, ada pola Separate Ways, dua tim memutuskan tidak berkolaborasi sama sekali. Ini bukan ideal, tapi bisa terjadi karena berbagai alasan. Misalnya, jika komunikasi antar tim sangat sulit (pemisahan geografis atau politik internal), lebih murah menyalin fungsionalitas di kedua sisi daripada memaksakan integrasi. Atau jika yang ingin dibagikan adalah subdomain generik (seperti logging, notifikasi, dll), mungkin lebih simpel setiap tim melokalkan solusinya sendiri daripada bikin satu layanan terpusat. Juga, jika model di kedua sisi benar-benar berbeda sehingga ACL atau Conformist menjadi mahal atau tidak mungkin, tim bisa memilih Duplicate (Separate Ways).
Peringatan: pola ini tidak boleh dipakai untuk subdomain inti perusahaan, karena menyalin inti bisnis berarti merugi, kita kehilangan optimasi dan konsistensi yang seharusnya menjadi sumber keunggulan.

Setelah semua hubungan integrasi ini terdefinisi, kita dapat menggambarnya dalam context map, peta visual bounded context beserta tipe integrasi antaranya. Context map ini memberikan wawasan strategis tinggi: apa saja komponen besar sistem, siapa bermitra dengan siapa, siapa yang mandiri atau bahkan memisahkan diri, dan pola komunikasi seperti apa yang terjadi antar tim.
Misalnya, sebuah panah ‘anticorruption layer’ dari tim A ke B menunjukkan tim A memakai ACL terhadap tim B. Context map sebaiknya disusun sejak awal proyek dan terus diperbarui bersama tim – misalnya setiap tim bertanggung jawab menjaga gambaran integrasi kontekstualnya tetap up-to-date.

Diulang kembali secara singkat, berikut pola-pola utama integrasi bounded context dalam DDD (Khononov, 2022):

• Partnership: Integrasi ad hoc dengan komunikasi dua arah.

• Shared Kernel: Dua konteks berbagi potongan model yang konsisten.

• Conformist: Konsumen menyesuaikan diri dengan model penyedia layanan.

• Anticorruption Layer: Konsumen membuat lapisan penerjemah agar model penyedia tidak merusak model internalnya.

• Open-Host Service: Penyedia menyiapkan antarmuka publik agar konsumennya nyaman, sementara detail internal tetap fleksibel.

• Separate Ways: Dua tim bekerja terpisah, setiap konteks menduplikasi kebutuhan umum agar integrasi tidak diperlukan.

Peta konteks (context map) menggambarkan semua ini secara keseluruhan. Dengan memahami pola-pola integrasi ini, kita dapat menyelaraskan desain teknis dengan struktur organisasi dan strategi bisnis yang ada.

Referensi

Khononov, V. (2022). Learning Domain-Driven Design: Aligning Software Architecture and Business Strategy. O’Reilly Media.