#domain-driven-design

The bottleneck isn't writing code anymore. It's understanding it.

Việc AI có thể sinh ra bao nhiêu code không quan trọng bằng khả năng bạn hiểu và chịu …

Persisting a Rich Domain Model With EF Core

Mô hình domain phong phú thường bị phản đối vì EF Core yêu cầu public setters và constructor, khiến nhiều người nghĩ phải dùng anemic model.

Lập trình viên nên đọc bài này vì EF Core thực sự hỗ trợ mô hình domain giàu (rich domain model) thông qua các tính năng như entity framework core design patterns và lazy loading, cho phép bạn giữ nguyên logic domain mà không cần chuyển đổi thành mô hình anemic.

Front-End Architecture with Domain-Driven Design

Một kỹ sư front-end kỳ cựu chia sẻ cách áp dụng Domain-Driven Design (DDD) vào ứng dụng SaaS React chuyên tính toán tải nổ, với các khối xây dựng như entities, value objects, services, aggregates định hình cấu trúc thư mục, quy ước đặt tên và thiết kế component. DDD giúp hình thành ngôn ngữ chung, thúc đẩy cộng tác giữa đội kỹ thuật và phi kỹ thuật, đồng thời kết nối chương "Supple Design" của DDD với các mẫu lập trình hàm hiện đại như pure functions và higher-order functions, vốn được thể hiện rõ qua React hooks.

Lập trình viên frontend cần đọc bài này để hiểu cách áp dụng DDD giúp tổ chức mã nguồn rõ ràng, giảm sự rối loạn giữa các thành viên và kết hợp tốt với React để tạo ra các giải pháp linh hoạt, dễ bảo trì và đồng bộ hóa với các nguyên tắc lập trình chức năng hiện đại.

Software Architecture with C# 14 and .NET 10 (Fifth Edition): Book Review

Cuốn sách "Software Architecture with C# 14 and .NET 10 (Fifth Edition)" cung cấp hướng dẫn thực hành về kiến trúc .NET hiện đại, bao gồm .NET Aspire, AI, bảo mật đám mây và các chủ đề liên quan.

Nếu bạn đang tìm hiểu cách xây dựng kiến trúc phần mềm mạnh mẽ, tối ưu hóa cho ứng dụng .NET hiện đại với các công nghệ mới như AI, cloud và bảo mật, thì cuốn sách này sẽ là nguồn tư liệu thiết thực, cập nhật và thực hành ngay từ trang đầu.

CQRS Without the Astronaut Architecture

Bài viết hướng dẫn triển khai CQRS trong Node.js/TypeScript theo cách đơn giản, không cần cơ sở hạ tầng phức tạp như event sourcing hay message queues. CQRS ở đây chỉ là cách tổ chức code tách biệt logic ghi (commands) và đọc (queries), với ví dụ TypeScript cụ thể về rich write side và lean read side. Tác giả khuyên nên bắt đầu từ phân tách code đơn giản rồi nâng cấp dần khi cần thiết.

Lập trình viên nên đọc bài này để hiểu cách áp dụng CQRS một cách đơn giản và hiệu quả trong Node.js/TypeScript mà không cần phụ thuộc vào kiến trúc phức tạp, từ đó tối ưu hóa quy trình phát triển và bảo trì ứng dụng của mình.

The Modular Monolith Boundary I Couldn't Take Back

Một lập trình viên chia sẻ kinh nghiệm khi ranh giới giữa hai module Catalog và Collaboration trong kiến trúc modular monolith dần trở nên không thể đảo ngược do yêu cầu kinh doanh buộc chuyển từ giao tiếp bất đồng bộ sang đồng bộ, khiến các module thực tế hoạt động như một khối thống nhất dù ranh giới vẫn tồn tại trên giấy. Bài viết khuyên nên coi ranh giới module là tạm thời, bắt đầu với ít module lớn hơn và chỉ tách nhỏ khi rõ ràng, đồng thời ưu tiên yêu cầu nhất quán hơn là trực giác về domain.

Lập trình viên nên đọc bài này để tránh rơi vào sai lầm khi cố gắng giữ các module độc lập trong một monolith mà thực tế đã bị "sáp nhập" nhờ yêu cầu tính nhất quán đồng bộ, khiến kiến trúc trở nên khó duy trì và mở rộng sau này.

A stray commit buried multiple levels deep cost me months

Một commit lạc lõng chôn sâu nhiều tầng khiến tác giả mất hàng tháng khắc phục. Bài viết nhấn mạnh DB layer phải quản lý mọi commit và transaction, đồng thời hướng dẫn cách áp dụng AST và linters để enforce các quy tắc này.

Lập trình viên nên đọc bài này để tránh rắc rối về quản lý commit và transaction, đặc biệt khi dự án có nhiều tầng lớp (layer) phức tạp, vì cách giải quyết bằng AST và linter giúp tự động hóa kiểm soát và tránh những commit "lẻ loi" gây mất thời gian khôi phục.

How Domain Boundary Violations Slowly Destroy Your Codebase

Một file "service" thường xuyên truy cập sâu vào nhiều domain khác, dẫn đến tình trạng vi phạm ranh giới domain, dần dần làm suy yếu cấu trúc codebase.

Lập trình viên nên đọc bài này để tránh tình trạng codebase trở nên rối loạn và khó duy trì khi các chức năng liên quan đến nhiều lĩnh vực (domain) bị xâm nhập không kiểm soát, dẫn đến sự phức tạp và bảo trì khó khăn.

Throw, Result, or neither?

Tôi thường nhận được câu hỏi tại sao không sử dụng Result trong code event-sourced, thay vì throw hay neither.

Lập trình viên nên đọc bài này để hiểu cách chọn giữa Throw và Result trong xử lý lỗi trong kiến trúc sự kiện, giúp tối ưu hóa code cho sự rõ ràng và bảo mật trong hệ thống sự kiện nguồn.

Tips for Developers New to ABP Framework

Bài viết hướng dẫn lập trình viên ASP.NET Core mới làm quen với ABP Framework, tập trung vào các rào cản phổ biến, sự khác biệt giữa CRUD và module thực tế, đánh đổi trong DDD và phương pháp tối ưu hơn.

Những lập trình viên mới chuyển sang ASP.NET Core nên đọc bài này để hiểu cách vượt qua những rào cản thực tế khi áp dụng ABP Framework, từ việc quản lý các thao tác CRUD đơn giản đến thiết kế mô hình thực sự phức tạp theo DDD mà không bị mắc kẹt trong những lựa chọn sai lầm.

Designing a Credit-Management Microservice for Partner Invoice Payment

Tôi là imamu, kỹ sư backend tại Merpay, chia sẻ về thiết kế microservice quản lý tín dụng nhằm xử lý thanh toán hóa đơn đối tác, trong chuỗi bài viết về Payment & Customer Platform.

Nếu bạn đang xây dựng hệ thống thanh toán với các microservice như credit management, bài này sẽ giúp bạn hiểu rõ cách thiết kế giải pháp phân tán an toàn, hiệu quả và phù hợp với quy trình thanh toán thực tế.

Creating a Production-Ready CRUD Application in ASP.NET Core

Bài viết hướng dẫn xây dựng ứng dụng CRUD sản xuất trong ASP.NET Core theo các best practices, ngay cả khi dự án đơn giản, nhằm tạo ra sản phẩm phù hợp để đưa vào portfolio.

Một lập trình viên nên đọc bài này để hiểu cách xây dựng ứng dụng CRUD chuyên nghiệp từ cơ bản, giúp họ có thể áp dụng kiến thức thực tế, tối ưu hóa mã và tạo ra dự án portfolio chất lượng cao.

When Rails gives you a schema instead of a boundary

In a Rails app the word 'user' means four different things and they all share one table. How subdomains and bounded contexts fix it - without leaving Rails.

Implementing Domain-Driven Design with KurrentDB: An Actor-Based Event Sourcing Approach

Bài viết hướng dẫn triển khai Domain-Driven Design (DDD) và Event Sourcing bằng TypeScript với KurrentDB và kiến trúc serverless, dựa trên phương pháp tiếp cận actor-based do Vaughn Vernon đề xuất.

Lập trình viên muốn xây dựng hệ thống phức tạp, ổn định và dễ bảo trì với kiến trúc Domain-Driven Design kết hợp Event Sourcing bằng KurrentDB và TypeScript để tối ưu hóa sự linh hoạt và khả năng mở rộng trong môi trường serverless.

Enabling Evolutionary Architecture Through the Preservation of Change Locality

Việc dịch chuyển ranh giới (boundary drift) phá vỡ tính cục bộ của thay đổi (change locality), tăng tải nhận thức (cognitive load) và làm chậm tiến độ nhóm. Bài viết đề xuất các chiến lược bảo tồn ranh giới miền (domain boundaries) để xây dựng kiến trúc tiến hóa (evolutionary architecture) bền vững.

Một lập trình viên nên đọc bài này để hiểu cách biểu hiện của sự thay đổi không tập trung (boundary drift) làm tăng gánh nặng nhận thức và làm chậm tiến trình phát triển phần mềm, đồng thời tìm hiểu cách duy trì các ranh giới logic rõ ràng để xây dựng kiến trúc linh hoạt và bền vững hơn.

Build a Dependency Injection Container in Vanilla JavaScript

Tìm hiểu cách xây dựng một dependency injection container trong JavaScript thuần bằng các chế độ vòng đời singleton, scoped và transient, mà không cần TypeScript.

Một lập trình viên cần đọc bài này để khám phá cách tự xây dựng một container DI đơn giản bằng JavaScript nguyên sinh, giúp hiểu rõ cơ chế quản lý sự sống (lifetime) của đối tượng—singleton, scoped và transient—trong ngữ cảnh thực hành mà không phụ thuộc vào TypeScript, giúp mở rộng kiến thức về thiết kế phần mềm và tối ưu hóa quản lý phụ thuộc trong ứng dụng.

When to Use Microservices (And When Not To) in .NET

Kiến trúc sư .NET nên cân nhắc khi nào nên áp dụng microservices—giải quyết vấn đề gì, trường hợp phù hợp, trường hợp không, và lý do modular monolith thường là lựa chọn tốt hơn.

Lập trình viên .NET nên đọc bài này để tránh rơi vào sai lầm về thiết kế microservices—hiểu rõ khi nên chia nhỏ hệ thống thành các dịch vụ nhỏ độc lập và khi một monolith modular vẫn là giải pháp hiệu quả hơn về chi phí, độ ổn định và sự đơn giản hóa phát triển.

Fixing bugs in Event Sourcing is hard, for real?

Sửa lỗi trong Event Sourcing rất khó do tính phức tạp của hệ thống dựa trên sự kiện, đòi hỏi xử lý cẩn thận các sự kiện đã xảy ra và trạng thái của chúng.

Là người phát triển cần hiểu về Event Sourcing để tránh rắc rối khi xử lý lỗi trong hệ thống theo mô hình lưu trữ sự kiện, giúp tối ưu hóa khả năng tái tạo trạng thái và debug hiệu quả hơn.

adam bien's blog

Phương pháp ba bước đơn giản để đặt tên component (package) trong hệ thống phần mềm: mô tả chức năng hệ thống bằng một câu, gạch chân động từ và danh từ quan trọng (chuyển động từ thành danh từ), sau đó loại bỏ những tên quá chung có thể dùng cho dự án khác. Ví dụ minh họa từ công cụ build Java (zb) và cửa hàng trực tuyến, cho thấy cách tên component như 'discovery', 'compiler', 'packer' hay 'hook' được hình thành từ mô tả hệ thống bằng ngôn ngữ tự nhiên.

Lập trình viên nên đọc bài này để học cách đặt tên các package trong hệ thống một cách rõ ràng và chuyên nghiệp, từ đó tránh sự nhầm lẫn, cải thiện tính bảo trì và dễ dàng mở rộng mã nguồn.

Fixing bugs in Event Sourcing is hard, for real?

Every system ends up with bad data.

Introduction to Apache Causeway

Tìm hiểu Apache Causeway thông qua việc xây dựng ứng dụng quản lý tài sản theo hướng miền (domain-driven), bao gồm giao diện người dùng tự động sinh, REST API, lưu trữ dữ liệu và quy tắc nghiệp vụ.

Một lập trình viên cần đọc bài này để khám phá cách xây dựng ứng dụng quản lý tài sản theo mô hình domain-driven design với Apache Causeway, giúp tối ưu hóa quy trình phát triển từ giao diện sinh động đến API REST, cơ sở dữ liệu và quy tắc kinh doanh một cách hiệu quả.

Mise en Place for Ecto: Organizing Domain Complexity w/Business Rules-Nicholas Henry

Mise en Place for Ecto: Organizing Domain Complexity w/Business Rules-Nicholas Henry|ElixirConf 2025 Comments welcome! View the elixirconf tag for more ElixirConf talks!

adam bien's blog

Business components (BCs) are top-level packages named after a single responsibility or feature rather than a technology layer. This approach, known as Screaming Architecture, makes a system's purpose immediately readable from its package names. BCs are not designed upfront but emerge organically as new requirements arise. The zero-dependency Java builder 'zb' illustrates this: requirements for finding source code, compiling, packaging, and running post-build hooks each became their own component — discovery, compiler, packer, and hook — making the system's structure self-documenting.

adam bien's blog

A podcast episode featuring Johan Haleby discussing the Occurrent library, event sourcing, CloudEvents, the distinction between domain and integration events, CQRS versus CQS, and how to model domain logic using sealed interfaces and records in Java.

Throw, Result, or neither?

Bài viết thảo luận về ba khái niệm trong lập trình hướng sự kiện: Throw (ném lỗi), Result (kết quả xử lý lỗi) và neither (không thuộc hai trường hợp trên), nhằm so sánh cách quản lý lỗi trong các ngôn ngữ lập trình khác nhau.

Lập trình viên nên đọc bài này để hiểu cách thiết kế và sử dụng các hàm Result (đối với trường hợp thất bại) và Event (đối với phản ứng động) trong lập trình hướng sự kiện, giúp tránh rủi ro của Throw (lập trình nhảy ngoại lệ) và tối ưu hóa logic ứng dụng.

Clean Architecture Explained: Building Software That Stands the Test of Time

Kiến trúc phần mềm sạch (Clean Architecture) giúp xây dựng hệ thống bền vững theo thời gian bằng cách tách biệt rõ ràng các lớp logic nghiệp vụ, giao diện người dùng và cơ sở dữ liệu, từ đó giảm thiểu sự phụ thuộc chặt chẽ giữa các thành phần.

Lập trình viên nên đọc bài này để hiểu cách thiết kế kiến trúc mềm bền vững, tránh rắc rối về quy mô lớn và thay đổi công nghệ trong tương lai.

Boundwork: A Team Structure For When Specialization Fails

Boundwork: A Team Structure For When Specialization Fails What to do when an organization just… loses the message Want to come back later? Save this to readplace.com. Boundwork: A Team Structure …

adam bien's blog

Robert C. Martin's Screaming Architecture principle — where a system's structure reveals its purpose through package names — is demonstrated using three real Java projects. The zb zero-dependency builder exposes compiler/hook/packer packages, lightmetal (an LLM runner on Apple Metal via llama.cpp) uses prompting/sampling/tokenization/tools, and zsmith (an agent harness) uses agent/memory/skills/tools/tui. All three follow BCE (Business Component Engineering) organization by domain responsibility, making code location predictable for both humans and LLM agents navigating the codebase.

Q&A about my Explore DDD designing microservices workshop

Buổi workshop thiết kế microservices tại Explore DDD 2026 nhấn mạnh tầm quan trọng của kiến trúc microservice trong kỷ nguyên GenAI, đồng thời cảnh báo những sai lầm thường gặp như chia nhỏ dịch vụ quá mức hay coupling chặt chẽ. Kết hợp lý thuyết và bài tập nhóm, sự kiện cung cấp kỹ thuật thực tế để xác định ranh giới service, quản lý coupling và áp dụng các mẫu cộng tác service.

Nếu bạn đang xây dựng hệ thống phức tạp trong thời đại AI, bài này giúp bạn tránh những sai lầm thiết kế microservices dễ gây ra rắc rối khi ứng dụng công nghệ mới như coding agents.

Basic concepts of Software architecture in OutSystems ODC with comparisons to OutSystems O11

Basic concepts of Software architecture in OutSystems ODC with comparisons to OutSystems O11 The basic concepts and artifacts of the OutSystems ODC architecture are simplified compared to version …

The Observer Design Pattern Handbook: Event-Driven Architecture & Domain-Driven Design in Dart

Mẫu quan sát (Observer) giải quyết vấn đề khi một sự kiện xảy ra, nhiều thành phần khác cần phản ứng tương ứng. Bài viết giới thiệu cách triển khai kiến trúc hướng sự kiện (Event-Driven) và Domain-Driven Design (DDD) trong Dart bằng mẫu quan sát.

Lập trình viên Dart nên đọc bài này để hiểu cách áp dụng mô hình Observer và tích hợp kiến trúc sự kiện để xây dựng ứng dụng phản ứng linh hoạt, giảm bớt sự phụ thuộc giữa các lớp và tối ưu hóa việc xử lý các sự kiện trong thiết kế domain-driven.

Quarkus Insights #254: Domain-Driven Design and Hexagonal Architecture - Part 2

Quarkus: Supersonic Subatomic Java

Event Sourcing: undo set-remove-based bi-temporal events – because we must

Part thirteen of an event sourcing series tackles the problem of undoing events in a bi-temporal, set-remove-based model. The naive approach of overriding a wrong event with the same timestamp corrupts the timeline when subsequent events are added. Two solutions are compared: a simpler approach using 'undone' and 'undoneAt' columns to mark events as undone without losing historical meaning, and a more complex 'Undo event' approach that references events by effective and application timestamps. The author explains why the column-based approach is preferred for its simplicity and maintainability, and includes an F# code deep dive showing the implementation for a task-tracking feature.

Domain-Driven Design in Laravel: Stop the “God Model” Mess

Laravel's default folder structure (Models, Controllers, Services) leads to bloated 'God Classes' as apps scale. Domain-Driven Design (DDD) solves this by organizing code around business domains instead of technical layers. The approach involves creating domain-specific directories (e.g., app/Domains/Members/), using single-action classes to replace fat controllers, keeping models lean with traits, and centralizing shared UI components. Benefits include easier testing, predictable structure, and linear scalability. Key pitfalls to avoid include over-engineering small features into domains, circular dependencies between domains (use events instead), and manual file moves that break namespaces.

adam bien's blog

Advocates for organizing Java code by business responsibility rather than technical layer. Using the lightmetal project (a zero-dependency Java 25 CLI for GPU LLM inference on Apple Silicon) as a concrete example, the post demonstrates the Business Component (BC) pattern where packages are named after responsibilities like 'catalog', 'generation', and 'tokenization' instead of generic terms like 'services' or 'utils'. Each BC follows the BCE (Boundary-Control-Entity) pattern from Ivar Jacobson's 1992 OOSE methodology, providing stable layer names that have outlasted many architectural trends.

Event Sourcing: set-and-remove-based bi-temporal events

Part twelve of a series on event sourcing explores set-and-remove-based bi-temporal events, contrasting them with the previously covered lifetime (create-update-delete) variant. These events model timelines where data is assigned and removed over time rather than tracking a thing's full lifecycle. A key challenge introduced is the insert vs. override projection problem: when a new event is added with an earlier effective date than an existing event, the system must decide whether the new event overrides all later events or is inserted between them, preserving the later event's effect. Both behaviors are valid depending on context, so the projection must be configurable. A concrete example using organisational unit calendars in F# illustrates how to configure set-and-remove projection with override behavior.

Software Design in the Agentic Age: Place Your Bets

Observations from Thoughtworks' Future of Software Engineering retreat on how agentic AI development changes software design priorities. Key debates covered whether low-level code quality still matters (conclusion: yes, because LLMs reinforce bad code, context windows are limited, and humans must debug what agents can't), whether specifications should replace code as the source of truth, and the role of domain models and bounded contexts in agentic workflows. The author argues for maintaining high test coverage, sound domain models, and code quality as a hedge against AI's risks and potential reversibility to human engineering. Rigour doesn't disappear with agents — it migrates upstream into specifications and test suites.

Event Sourcing: Aggregates, Dynamic Consistency Boundaries, or what?

Part eleven of an event sourcing series explores how to handle consistency boundaries without relying on DDD aggregates or Dynamic Consistency Boundaries (DCBs). The author argues that the best approach depends on the actual problems at hand. Two alternatives are discussed: replacing concurrent designs with non-concurrent ones (e.g., a draft-registration phase processed by a single-threaded algorithm), and using Azure Service Bus sessions to serialize workday validation, eliminating race conditions within a consistency boundary. The post emphasizes solving real problems holistically rather than applying patterns preemptively, and shows how task-based UIs and small data models reduce the likelihood of concurrency conflicts in the first place.