#domain-driven-design

On EventStorming, collaboration, LLMs and how to glue that

Can we make collaboration great again?

Domain-Driven Design matters more when AI writes your code

Mô hình miền (domain model) và Ngôn ngữ phổ quát (Ubiquitous Language) càng trở nên quan trọng khi AI tự động sinh code.

Lập trình viên nên đọc bài này để hiểu cách Domain-Driven Design (DDD) và ngôn ngữ chung (Ubiquitous Language) trở nên quyết định hơn bao giờ hết khi AI tự động hóa viết code, giúp bảo vệ chất lượng logic và tính tương thích với yêu cầu thực tế của dự án.

How to Apply Secure By Design Practices To Money Software

Bối cảnh của bài viết chia sẻ hai bài học quan trọng từ một cuốn sách bảo mật chuyên ngành. Nguyên nhân kỹ thuật là các nguyên tắc Secure By Design áp dụng cho phần mềm tài chính không chỉ liên quan đến bảo mật mà còn về kiến trúc hệ thống và quản lý rủi ro. Hệ quả là việc áp dụng những nguyên tắc này giúp giảm thiểu lỗ hổng và tăng độ tin cậy của hệ thống. Điều đáng học là các phương pháp như Zero Trust, Defense in Depth và Threat Modeling có thể ứng dụng hiệu quả ngay cả khi bạn không phải chuyên gia bảo mật.

Hai bài học từ sách bảo mật giúp bạn viết phần mềm tài chính an toàn hơn mà không cần chuyên sâu về bảo mật.

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 trách nhiệm cho nó. Những thực hành coding tốt vốn dĩ không dành cho máy móc.

Những kỹ thuật và nguyên tắc lập trình tốt không chỉ giúp code hiệu quả mà còn giúp bạn kiểm soát và chịu trách nhiệm về phần mềm của mình, tránh rơi vào tình trạng phụ thuộc vào công cụ AI mà không biết nguồn gốc, chất lượng hay tác động thực sự của nó.

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.

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.

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.

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.

Frontend Dependency Injection: From Context API to Composition Root

Bài viết bắt đầu bằng việc mô tả cách nhiều dự án React hiện nay sử dụng Context API để thực hiện dependency injection, nhưng nhanh chóng chỉ ra hạn chế của cách này như việc lồng.provider sâu dẫn tới re‑render không mong muốn và khó kiểm tra đơn vị. Sau đó, tác giả giới thiệu mô hình Composition Root – nơi tất cả các phụ thuộc được tạo và kết nối ở một điểm duy nhất, thường là tệp index.js hoặc App.tsx, giúp làm rõ đồ thị phụ thuộc và giảm bớt việc truyền props qua nhiều lớp component. Khi áp dụng Composition Root, các dịch vụ có thể được thay thế bằng mocks hoặc triển khai khác mà không cần thay đổi mã component, từ đó cải thiện độ bao phủ test đơn vị lên khoảng 20‑30% trong các trường hợp thử nghiệm thực tế. Bài cũng nhấn mạnh việc kết hợp với TypeScript và các container DI nhẹ như tsyringe hoặc inversifyJS để quản lý vòng đời (singleton, transient) một cách tự động. Kết luận là, cho dự án lớn hoặc dự kiến mở rộng, chuyển từ Context API sang Composition Root không chỉ giảm lỗi thời gian chạy mà còn làm cho kiến trúc frontend dễ duy trì và mở rộng hơn.

Bài viết này giúp lập trình viên hiểu rõ cách triển khai Dependency Injection trong frontend từ Context API đến Composition Root để xây dựng ứng dụng dễ bảo trì và mở rộng.

Fragments: October 28

This roundup gathers takes on AI's uneven impact across developers and enterprises. Andrej Karpathy describes a widening perception gap: most people see only a 'derpy chatbot' while a small sliver of professionals feel the curve going vertical. Martin Fowler recaps Foocamp, where coaches of immersion courses said the biggest impact was emotional, not technical, since the tools challenge developer identity. Laurie Voss says today is 1997, comparing the AI boom to the early internet. Annie Vella frames the shift as moving from direct to supervisory control over coding agents. Thoughtworks forecasts its token-sourcing strategy will cut its 2028 token costs from $16-40M down to $6.8-1M.

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.

Why are we talking about architecture again?

UI developers thường tin rằng framework đã chọn tự động giải quyết vấn đề cấu trúc và tổ chức code, nhưng kiến thực tế phức tạp hơn nhiều và cần thảo luận lại về architecture.

Bài viết này giúp lập trình viên nhận ra tầm quan trọng của kiến trúc phần mềm dù đã sử dụng framework.

How to Model Money in ASP.NET Core

Xử lý giá trị tiền tệ trong ASP.NET Core trông đơn giản nhưng ẩn chứa nhiều lỗi khó phát hiện. Các vấn đề kỹ thuật thường đến từ việc sử dụng kiểu dữ liệu thập phân (decimal) không chính xác và tính toán chính xác số học định điểm cố định. Điều này dẫn đến sai lệch giá trị trong các giao dịch tài chính và mất dữ liệu. Bài viết đề xuất sử dụng các thư viện như NodaTime và MoneyExtension để đảm bảo độ chính xác cao. Bạn sẽ học cách thiết kế models tài chính an toàn và tránh các lỗi phức tạp trong hệ thống thanh toán.

Bài viết này giúp lập trình viên tránh được những lỗi khó phát hiện khi xử lý giá trị tài chính trong ASP.NET Core.

CRUD vs Task Driven: Are You Losing User Intent?

CRUD (Create, Read, Update, Delete) và Task-Driven design không phải là lựa chọn loại trừ lẫn nhau. Thiết kế CRUD phù hợp khi ứng dụng cần quản lý dữ liệu đơn giản như trong các ứng dụng quản lý danh bạ hoặc blog. Trong khi đó, Task-Driven design tối ưu cho quy trình nghiệp vụ phức tạp như hệ thống đặt hàng hoặc quy trình phê duyệt, nơi người dùng cần thực hiện các hành động cụ thể với intent rõ ràng. Sự lựa chọn sai phương pháp có thể dẫn đến trải nghiệm người dùng phức tạp và giảm hiệu quả. Các lập trình viên nên phân tích yêu cầu nghiệp vụ cụ thể để quyết định giữa hai phương pháp tiếp cận này.

Bài viết này giúp lập trình viên hiểu khi nào nên dùng CRUD và khi nào cần thiết kế task driven để đáp ứng đúng nhu cầu người dùng.

On EventStorming, collaboration, LLMs and how to glue that

It’s interesting how things change; for many years, Alberto Brandolini said the best way to do remote EventStorming is to buy a plane ticket. But then COVID happened; now…

Strongly typed IDs in .NET with Vogen

Vogen is a .NET source generator that creates strongly typed IDs to fix primitive obsession from using raw Guids everywhere. Wrapping IDs like OrderId and CustomerId in value objects turns argument mix-ups, such as swapping customerId and orderId, into compile errors instead of silent bugs. Vogen blocks uninitialized IDs by forcing creation through From(). With the AddFactoryMethodForGuids setting it can generate FromNewGuid() and FromNewVersion7Guid() factory methods. It also generates JSON and TypeConverter support out of the box, with an opt-in EF Core value converter you register once in ConfigureConventions so entities use the typed ID while the database still stores a plain uniqueidentifier.

Agentic Development and Engineering Strategy

A first exploration, a draft with thoughts

Cross-Context Change Propagation in Elixir

How to coordinate changes across Elixir bounded contexts using workflows, domain events, Oban, and PubSub.

"DDD and Your ORM" at the Full-Stack NL meetup

My previous encounter with Full-Stack NL was in 2019, when I was invited by Peter Paul Keuler to talk about what I consider Advanced Web Application Architecture. It’s nice to be back at the PAQT office in 2026 (they moved across the street in the meantime) with a new talk. The talk uses an experimental “Choose Your Own Adventure” format. Abstract Over time, you’ve created lots of data models that are mapped to tables in your relational database. Now you want to untangle the “mess” using Domain-Driven Design practices and patterns. This is very exciting; you’re planning to separate your business domain into smaller subdomains, implemented by so-called Bounded Contexts, with explicit boundaries. But you are using an ORM, and the ORM knows about Entities, but it doesn’t care about Bounded Contexts. It allows you (and often requires you) to link remote concepts in the code, ruining those boundaries you imagined…

adam bien's blog

Mô hình BCE (Boundary Control Entity) được Ivar Jacobson giới thiệu năm 1992 hiệu quả đặc biệt cho agent coding. Kiến trúc này với các vertical slice, mỗi layer đảm nhiệm một trách nhiệm duy nhất và cấu trúc nhất quán giúp agent tìm code mà không cần duyệt cây, tiết kiệm tokens. Vị trí xác định đảm bảo mã mới có đúng một vị trí hợp lệ, ngăn agent tạo các gói 'util', 'service' hay 'helper' rời rạc. Các quy tắc layer cơ khí cho phép ArchUnit test hay script kiểm tra tuân thủ chỉ trong vài giây. Mô hình cũng hỗ trợ công việc song song, với mỗi agent xử lý một business component và hợp nhất kết quả mà ít xung đột.

Kiến trúc BCE giúp lập trình viên viết mã agent hiệu quả hơn với cấu trúc rõ ràng, vị trí code xác định và kiểm tra dễ dàng.

adam bien's blog

Boundary-Control-Entity (BCE) do Ivar Jacobson giới thiệu năm 1992 có mối liên hệ với Hexagonal (2005), Onion (2008) và Clean Architecture (2012). BCE tổ chức code theo business component trước, áp dụng boundary, control và entity trong mỗi component, trong khi các kiến trúc khác thường dùng chúng như các ring kỹ thuật ở cấp độ trên. BCE ưu tiên concrete class hơn interface trừ khi có nhiều implementation, với boundaries gọi controls, controls gọi entities, và reverse calls chỉ được phép qua events. /sbce áp dụng BCE vào development dựa trên spec, sử dụng một capability spec per business component như boundary contract.

Bài viết cung cấp cái nhìn tổng quan về lịch sử phát triển và ứng dụng thực tế của kiến trúc Boundary-Control-Entity giúp lập trình viên hiểu cách tổ chức code hiệu quả theo thành phần nghiệp vụ.

Composable Commerce: Inside Shipt’s Kit Platform

Shipt đã ra mắt Kits nền tảng để đơn giản hóa việc mua sắm tạp hóa theo sự kiện cụ thể. Công ty giảm các quy trình phức tạp xuống thành giao diện đơn giản, tích hợp kiểm tra kho hàng và tuân thủ thời gian thực. Giải pháp này giúp đội ngũ hỗ trợ khách hàng hoạt động hiệu quả hơn, giảm 30% thời gian xử lý đơn hàng. Các lập trình viên nên tham khảo bài gốc để hiểu cách Shipt triển khai microservices và GraphQL trong kiến trúc composable commerce.

Lập trình viên nên đọc bài này để hiểu cách xây dựng các hệ thống thương mại linh hoạt, kết hợp các thành phần độc lập (composable) để tối ưu hóa quy trình mua sắm đặc biệt, từ đó áp dụng kiến thức vào phát triển các giải pháp thương mại hiệu quả hơn.

Event Sourcing: A close look at the projector for values

Bối cảnh của bài viết là việc triển khai ValueProjector trong event sourcing bằng ngôn ngữ F#. Nguyên nhân kỹ thuật tập trung vào xử lý các kiểu projection, cấu hình, sắp xếp sự kiện và logic folding cho các thao tác create/update/delete, set/remove, ordered-update, và streamlined events. Hệ quả là qua việc kết nối các sự kiện thành một giá trị current-state duy nhất, bài viết cung cấp toàn bộ code snippet minh họa. Điều đáng học là cách bài viết xây dựng dựa trên các khái niệm từ các bài viết trước trong series, giải thích chi tiết cách biến đổi các sự kiện thành giá trị trạng thái hiện tại.

Bài viết này cung cấp kiến thức thực tế về triển khai ValueProjector trong F# giúp lập trình viên nắm vững cách biến đổi sự kiện thành trạng thái hiện tại.

Continuous Delivery Office Hours Ep.10: Modernizing legacy software

Phát triển phần mềm kiểu big-bang rewrite thường dẫn đến thất bại do rủi ro cao và tỷ lệ thất bại lên đến 70-90% theo khảo sát của ThoughtWorks. Thay vào đó, nên áp dụng Continuous Delivery để hiện đại hóa legacy system bằng cách chia nhỏ việc cập nhật thành các incremental change an toàn. Các chiến lược như Strangler Fig Pattern hoặc Feature Flags cho phép từng bước thay thế dần các component cũ mà không làm gián đoạn hệ thống tổng thể. Việc chuyển đổi cần được thực hiện với tốc độ phù hợp, kết hợp test automation và feature monitoring để đảm bảo chất lượng và giảm thiểu rủi ro trong quá trình hiện đại hóa.

Bài này giúp lập trình viên hiểu được cách tiếp cận hiệu quả để hiện đại hóa phần mềm legacy mà không rơi vào cạmẫy big-bang rewrite.

Fragments: October 4

Martin Fowler phản ánh về triết lý khác biệt giữa việc xây dựng phần mềm xác định và nuôi dưỡng hệ thống LLM suy luận. Ola Bini, chuyên gia bảo mật phần mềm, đã bị Ecuador trục xuất sau 13 năm nhưng an toàn đến Thụy Điển. Eric Evans thảo luận về AI tác động đến mô hình hóa khái niệm và thực hành agile trong video phỏng vấn. Cuộc tranh luận nảy sinh về tính quan trọng của mã nguồn dễ đọc khi LLM có thể biên dịch ký hiệu cấp cao xuống cấp thấp hơn, với Rails app tăng từ 60,000 lên 4,000,000 token khi biên dịch sang C. Mô hình Gemini 4 Argon của Google có tỷ rate ảo giác 15%, thấp hơn nhiều so với các model khác như Grok 4.7 (29%), GPT-6 Astra (45%), nhưng trả lời đúng ít câu hỏi hơn Opus 5.5 (50% so với 66%).

Bài viết cung cấp cái nhìn sâu sắc về sự khác biệt triết học giữa xây dựng phần mềm xác định và nuôi dưỡng hệ thống LLM suy luận, cùng với những tranh luận nóng hổi về tác động của AI đến lập trình.

Fractal Architecture, Cognitive Load, Vertical Slices and other terms that do(n't) fit your head

Ngữ cảnh Vertical Slices luôn cần nhiều giải thích hơn vì khái niệm này liên tục đòi hỏi các bài viết bổ sung. Nguyên nhân kỹ thuật nằm ở cách fractal architecture và cognitive load tương tác trong thiết kế hệ thống phần mềm, khiến Vertical Slices trở thành giải pháp tối ưu để giảm độ phức tạp. Hệ quả là các đội ngũ áp dụng Vertical Slices thành công đạt được tốc độ delivery nhanh hơn 30% so với các phương pháp truyền thống. Điều đáng học là việc triển khai Vertical Slices đòi hỏi sự hiểu biết sâu về domain-driven design và microservices architecture để đạt hiệu quả tối đa.

Bài viết này giúp lập trình viên hiểu rõ kiến trúc phân fractal, tải nhận thức và vertical slices qua ví dụ thực tế mà không lan man.

Start Small, Grow Big: how to pick the first feature for Event Sourcing

Khi triển khai Event Sourcing, nhiều đội ngũ gặp khó khăn trong việc chọn feature đầu tiên. Bài viết đề xuất nên bắt đầu với những đơn vị công việc đơn giản như "Order" hoặc "Payment" thay vì các domain phức tạp. Lý do kỹ thuật là vì các aggregate event đơn giản giúp giảm thiểu rủi ro khi implement event store và snapshot mechanism. Hệ quả là team sẽ có cơ hội học hỏi các nguyên tắc cơ bản như event versioning và projection building mà không bị quá tải bởi business logic phức tạp. Đáng học hỏi nhất là bài viết nhấn mạnh việc bắt đầu với scope hẹp, cho phép tích lũy kinh nghiệm trước khi mở rộng sang các domain phức tạp hơn như Inventory hay Customer Management.

Bài viết này giúp lập trình viên chọn tính năng đầu tiên phù hợp khi triển khai Event Sourcing một cách hiệu quả.

adam bien's blog

Dựa trên dự án eBank, so sánh thực tế giữa BCE và Hexagonal Architecture cho thấy Hexagonal thêm nhiều lớp classes (domain, persistence, transport models và mappers) mà không mang lại lợi ích đáng kể khi chỉ dùng một công nghệ persistence và một team. BCE duy trì một entity cho mỗi concept, test với real protocols thay vì mocked ports, và tạo structure package theo trách nhiệm nghiệp vụ thay vì pattern kiến trúc. Hexagonal chỉ thực sự cần thiết khi có thêm persistence backend thứ hai, nhu cầu unit testing rộng rãi không cần database, hoặc các team riêng biệt quản lý core và adapters.

So sánh BCE và Hexagonal Architecture giúp bạn chọn giải pháp thiết kế phù hợp nhất dựa trên quy mô dự án và nhu cầu thực tế của team.

Event Sourcing: two ways to enable accept/reject workflows

Bối cảnh: Event Sourcing được áp dụng cho các workflow accept/reject như sửa timestamp trong hệ thống time-tracking. Nguyên nhân kỹ thuật: Hai cách tiếp cận gồm đa stream ba bước và single stream với accept/reject functionality tích hợp vào projector. Hệ quả: Phương pháp tối ưu chạy dưới 1 microsecond cho stream ngắn và dưới 100 microseconds cho stream 500 events, với overhead projection không đáng kể so với chi phí I/O. Điều đáng học: Code minh họa discriminated union actions (SelfAccept, NoAction, Skip) và cấu hình StreamlinedCreateUpdateDelete projector trong F#.

Bài viết này giúp lập trình viên tối ưu hóa pattern Event Sourcing cho workflow chấp nhận/từ chỉ với hiệu suất chạy dưới microsecond.

Fragments: September 24

Rob Bowley cảnh báo mối nguy thực tế của AI không phải kịch bản hủy diệt mà là sự tích hợp thiếu an toàn vào mọi hệ thống mà không có kiểm soát, đặc biệt là lỗ hổng 'Lethal Trifecta' trong agentic systems. Nikita Prokopov đề xuất giảm bớt syntax highlighting, chỉ tô màu cho string, constants, comments và top-level definitions với màu nhạt cho yếu tố ít quan trọng, điều này trở nên cần thiết khi lập trình viên đọc nhiều code hơn họ viết do agentic coding. Khái niệm Forward Deployed Engineers ở các công ty như Palantir, Snowflake, Anthropic và startup thực chất bao gồm các công việc rất khác nhau, có liên hệ với Domain-Driven Design và Agile. Điều đáng học hỏi là cần cân nhắc kỹ trước khi áp dụng công nghệ mới, chú trọng chất lượng hơn số lượng code, và hiểu rõ sự đa dạng trong các vai trò kỹ thuật để áp dụng phù hợp.

Bài viết cung cấp phân tích sâu ba xu hướng công nghệ quan trọng về AI an toàn, tối ưu lập trình và mô hình kỹ sư hiện đại.