Data Mesh 2 — Sở hữu theo domain

Trong bài tổng quan chúng ta đã liệt kê bốn nguyên tắc của Data Mesh. Bài này mổ xẻ nguyên tắc đầu tiên và cũng là nền móng cho ba nguyên tắc còn lại: domain-oriented decentralized data ownership — phi tập trung quyền sở hữu dữ liệu theo domain nghiệp vụ.

Đây không phải là chuyện chia lại sơ đồ tổ chức cho vui. Nó là câu trả lời cho một nút thắt rất cụ thể: khi một đội data trung tâm phải hiểu, làm sạch và mô hình hoá dữ liệu của mọi nghiệp vụ trong ngân hàng — Thẻ, Tín dụng, Thanh toán, Huy động — họ trở thành nút cổ chai (bottleneck). Họ không đủ hiểu nghiệp vụ Thẻ để biết mã trạng thái thẻ TS nghĩa là gì, không đủ hiểu Tín dụng để biết khi nào một khoản vay chuyển nhóm nợ, mà lại phải chịu trách nhiệm chất lượng dữ liệu của cả hai. Kết quả: pipeline vỡ, không ai biết ai sửa, và mọi yêu cầu thay đổi xếp hàng sau một backlog dài vô tận.

Nguyên tắc sở hữu theo domain nói: hãy để đội hiểu dữ liệu nhất sở hữu dữ liệu đó. Nghe hiển nhiên, nhưng thực hiện nó đòi hỏi mượn nguyên một bộ khái niệm từ thiết kế phần mềm hiện đại.

Bounded context & DDD áp cho dữ liệu

Domain-Driven Design (DDD) — thiết kế hướng miền — là phương pháp do Eric Evans đề xướng cho phần mềm nghiệp vụ phức tạp. Hai khái niệm cốt lõi mà Data Mesh mượn lại là domain và bounded context.

• Domain là một lĩnh vực nghiệp vụ có ranh giới rõ, có ngôn ngữ và quy tắc riêng. Ở ngân hàng: Thẻ, Tín dụng, Thanh toán, Huy động, Chống rửa tiền là các domain.
• Bounded context (ngữ cảnh giới hạn) là ranh giới trong đó một mô hình và một ngôn ngữ chung (ubiquitous language) có nghĩa nhất quán. Cùng một từ "khách hàng" nhưng trong domain Tín dụng nó mang thuộc tính điểm tín dụng, nhóm nợ, hạn mức; trong domain Huy động nó mang số dư tiết kiệm, kỳ hạn; trong domain Thẻ nó mang hạng thẻ, hạn mức chi tiêu. Cùng một thực thể, ba mô hình khác nhau — và đó là điều bình thường, không phải lỗi cần hợp nhất.

Sai lầm kinh điển của mô hình data warehouse tập trung là cố nhồi mọi domain vào một mô hình "khách hàng" duy nhất, dẫn tới một bảng dim_customer có 400 cột mà không ai hiểu hết, và mỗi thay đổi phải thương lượng giữa tất cả các bên. DDD nói ngược lại: chấp nhận nhiều mô hình cùng tồn tại, mỗi mô hình đúng trong bounded context của nó, và định nghĩa rõ ranh giới cùng cách dịch (translation) khi dữ liệu đi qua ranh giới.

Áp vào dữ liệu, mỗi bounded context trở thành một data domain — đơn vị sở hữu dữ liệu. Ranh giới bounded context chính là ranh giới sở hữu.

Ba loại data domain

Zhamak Dehghani (tác giả Data Mesh) phân data domain thành ba loại theo vị trí trong luồng dữ liệu. Phân loại này cực kỳ hữu ích khi vẽ kiến trúc vì nó cho biết dữ liệu chảy từ đâu tới đâu.

1. Source-aligned domain (gần hệ nguồn). Dữ liệu phản ánh trực tiếp sự thật vận hành (operational fact) của một hệ thống nguồn. Nó là dữ liệu "thô có ý nghĩa" ngay sau khi rời khỏi hệ thống giao dịch, chưa qua tổng hợp phức tạp. Ví dụ: domain Thẻ publish luồng giao dịch thẻ từ core thẻ (Way4/CardPro), domain Thanh toán publish luồng lệnh chuyển tiền từ hệ thống thanh toán. Đặc điểm: gắn chặt với vòng đời hệ nguồn, ít biến đổi ngữ nghĩa, thường ổn định lâu dài (miễn hệ nguồn không đổi).

2. Aggregate domain (tổng hợp nhiều nguồn). Dữ liệu được tạo bằng cách hợp nhất, đối chiếu, tổng hợp từ nhiều source-aligned domain. Đây là nơi logic nghiệp vụ liên miền sống. Ví dụ: domain "Khách hàng 360" gộp dữ liệu từ Thẻ + Tín dụng + Huy động + Thanh toán để tạo hồ sơ khách hàng toàn diện; domain "Phòng chống rửa tiền" (AML) gộp giao dịch từ mọi kênh để chấm điểm rủi ro. Đặc điểm: phức tạp về ngữ nghĩa, cần định nghĩa lại (reconcile) khái niệm giữa các nguồn, dễ vỡ hơn khi upstream đổi.

3. Consumer-aligned domain (phục vụ nhu cầu dùng cụ thể). Dữ liệu được định hình đúng theo nhu cầu của một nhóm người tiêu dùng cụ thể — một mô hình chiều (dimensional model) cho báo cáo, một feature store cho ML, một view cho một dashboard NHNN. Nó "fit for purpose". Ví dụ: domain "Báo cáo giám sát NHNN" tạo các mart đúng biểu mẫu quy định; domain "Feature Store rủi ro tín dụng" tạo đặc trưng cho mô hình scorecard. Đặc điểm: gắn với người dùng cuối, đổi theo nhu cầu tiêu dùng, thường có vòng đời ngắn hơn.

Loại domain	Nguồn dữ liệu	Ngữ nghĩa	Ví dụ ngân hàng	Độ ổn định
Source-aligned	1 hệ nguồn	Sự thật vận hành, ít biến đổi	Giao dịch thẻ, lệnh thanh toán	Cao (theo hệ nguồn)
Aggregate	Nhiều source-aligned	Logic liên miền, reconcile	KH 360, AML risk	Trung bình
Consumer-aligned	Source/aggregate	Định hình theo người dùng	Mart báo cáo NHNN, feature store	Thấp (theo nhu cầu)

Một nguyên tắc thiết kế quan trọng: luồng phụ thuộc nên chảy một chiều từ source-aligned → aggregate → consumer-aligned. Consumer-aligned được phép phụ thuộc nhiều nguồn; source-aligned không nên phụ thuộc consumer-aligned (tránh vòng lặp). Điều này giữ cho kiến trúc không rối như mì spaghetti.

Ai sở hữu: domain team sở hữu trọn vòng đời

Điểm cách mạng của Data Mesh nằm ở đây. Trong mô hình cũ, một pipeline điển hình bị cắt ngang theo công đoạn kỹ thuật:

• Đội hệ nguồn (Thẻ) chỉ lo hệ giao dịch, "ném" dữ liệu qua tường.
• Đội data trung tâm bắt lấy, ingest, làm sạch, transform, mô hình hoá.
• Đội BI dựng dashboard từ output.

Vấn đề: kiến thức nghiệp vụ nằm ở đội Thẻ, nhưng trách nhiệm dữ liệu nằm ở đội trung tâm. Khi mã trạng thái thẻ thêm giá trị mới, đội Thẻ không báo, pipeline trung tâm âm thầm phân loại sai, và không ai phát hiện cho tới khi báo cáo lệch.

Data Mesh cắt dọc theo domain: domain team sở hữu trọn vòng đời dữ liệu của mình — ingest → transform → serve.

• Ingest: lấy dữ liệu từ hệ nguồn của chính domain (qua CDC, API, event stream).
• Transform: làm sạch, mô hình hoá, áp dụng logic nghiệp vụ mà chính họ hiểu rõ nhất.
• Serve: phơi dữ liệu ra như một data product có contract rõ ràng cho domain khác dùng.

Để làm được điều này, domain team cần năng lực kỹ thuật dữ liệu ngay bên trong. Đây là ý tưởng data engineer nhúng (embedded): thay vì tập trung tất cả data engineer vào một phòng, ta nhúng một hoặc vài data engineer vào domain team. Họ ngồi cùng người nghiệp vụ, hiểu bối cảnh, và chịu trách nhiệm data product của domain đó.

Điều này không có nghĩa mỗi domain tự dựng hạ tầng riêng — đó sẽ là thảm hoạ trùng lặp. Data Mesh giải bài toán này bằng cách tách trách nhiệm thành hai lớp:

Domain team tự chủ về dữ liệu và logic nghiệp vụ; nền tảng chung (platform) lo hạ tầng và công cụ.

Domain không tự viết engine Spark, không tự vận hành Kafka cluster, không tự dựng catalog. Họ dùng một self-serve data platform do platform team cung cấp. Họ chỉ tập trung vào thứ chỉ họ mới làm được: hiểu và mô hình hoá dữ liệu nghiệp vụ của mình.

Từ "đội data trung tâm làm hết" sang "domain tự chủ + nền tảng chung"

So sánh trực diện hai mô hình:

Khía cạnh	Đội data trung tâm làm hết	Domain tự chủ + nền tảng chung
Ai hiểu nghiệp vụ	Đội trung tâm (thường thiếu)	Domain team (đủ sâu)
Ai chịu trách nhiệm chất lượng	Trung tâm (nhưng không hiểu)	Domain (hiểu và sở hữu)
Điểm nghẽn khi mở rộng	Backlog đội trung tâm	Không tập trung một chỗ
Trùng lặp hạ tầng	Không (nhưng cứng nhắc)	Không (dùng platform chung)
Tốc độ thay đổi	Chậm, qua hàng chờ	Nhanh, domain tự quyết
Rủi ro	Kiến thức tập trung mỏng	Cần chuẩn chung để không loạn

Đây không phải "bỏ đội data trung tâm". Đội trung tâm biến hình thành hai vai trò mới: platform team (xây nền tảng self-serve) và enabling team (huấn luyện, đặt chuẩn). Ta sẽ thấy rõ trong Team Topologies dưới đây.

Team Topologies: khuôn mẫu tổ chức

Cuốn Team Topologies (Matthew Skelton & Manuel Pais) cung cấp bốn kiểu team và ba kiểu tương tác, ánh xạ gần như hoàn hảo với Data Mesh:

1. Stream-aligned team — team gắn với một luồng giá trị nghiệp vụ. Chính là domain team trong Data Mesh. Ví dụ: team Thẻ, team Tín dụng. Họ sở hữu data product của luồng đó end-to-end.

2. Platform team — cung cấp nền tảng nội bộ như một dịch vụ, giảm gánh nặng nhận thức (cognitive load) cho stream-aligned team. Chính là data platform team: cung cấp compute, storage, orchestration, catalog, công cụ tạo data product bằng cách self-serve.

3. Enabling team — nhóm chuyên gia giúp stream-aligned team học kỹ năng và thực hành mới, rồi rút đi. Ví dụ: một enabling team dạy domain Thẻ cách viết data contract, cách đo data quality, cách publish product đúng chuẩn. Họ không làm thay, họ nâng năng lực.

4. Complicated-subsystem team — sở hữu phần con phức tạp cần chuyên môn sâu. Ví dụ: một team lo engine tính rủi ro AML real-time, hay một team lo hệ thống matching entity resolution phức tạp.

Ba kiểu tương tác: X-as-a-Service (domain dùng platform như dịch vụ — tương tác chính, ít ma sát), collaboration (hai team làm chung tạm thời khi khám phá cái mới), facilitating (enabling team dìu dắt). Mục tiêu tối thượng: giảm cognitive load cho domain team để họ chỉ phải nghĩ về nghiệp vụ, không phải nghĩ về hạ tầng.

Ranh giới domain & sở hữu chồng lấn

Đây là chỗ lý thuyết gặp thực tế phũ phàng. Ranh giới domain hiếm khi sạch sẽ, và câu hỏi kinh điển là: ai sở hữu dữ liệu khách hàng dùng chung?

Trong ngân hàng, "khách hàng" xuất hiện ở mọi domain. Nếu để mỗi domain tự định nghĩa khách hàng riêng, ta có bốn phiên bản không khớp CIF (Customer Information File), bốn định nghĩa "khách hàng đang hoạt động" khác nhau, và không ai đối chiếu được. Nhưng nếu ép tất cả dùng một mô hình khách hàng khổng lồ, ta quay về data warehouse tập trung.

Cách Data Mesh giải quyết, dựa trên DDD:

• Tách một source-aligned domain "Định danh khách hàng" (CIF/Customer Master) sở hữu dữ liệu định danh cốt lõi: CIF number, họ tên, ngày sinh, giấy tờ, KYC. Đây là "source of truth" cho định danh.
• Các domain khác (Thẻ, Tín dụng...) không sở hữu định danh — họ tham chiếu CIF number như khoá ngoại và bổ sung góc nhìn của riêng mình (thuộc tính khách hàng theo bounded context của họ).
• Domain aggregate "Khách hàng 360" hợp nhất các góc nhìn lại, dùng CIF number làm khoá join, và định nghĩa rõ quy tắc reconcile khi mâu thuẫn.

Đây là mẫu shared kernel kết hợp customer/supplier trong DDD: một nhân chung nhỏ (định danh) được sở hữu tập trung, còn các thuộc tính mở rộng thì phi tập trung theo domain. Ranh giới đặt ở "định danh vs. thuộc tính nghiệp vụ".

Nguyên tắc thực hành khi vẽ ranh giới: theo ranh giới nghiệp vụ và quyền sở hữu quyết định, không theo cấu trúc bảng kỹ thuật. Hỏi: "Ai là người có quyền và trách nhiệm cao nhất về ý nghĩa của dữ liệu này?" Người đó (đội đó) nên sở hữu.

Đánh đổi cần cân nhắc

Sở hữu theo domain không miễn phí. Các đánh đổi chính:

• Tự chủ vs. trùng lặp. Cho domain tự chủ nghĩa là chấp nhận một mức trùng lặp có kiểm soát: hai domain có thể cùng làm sạch dữ liệu tương tự, cùng viết logic tính "khách hàng active" hơi khác nhau. Data Mesh coi đây là cái giá chấp nhận được của tốc độ, miễn là mỗi định nghĩa được ghi rõ trong contract để người dùng biết mình đang lấy phiên bản nào.
• Tự chủ vs. cần chuẩn chung. Nếu mỗi domain tự do tuyệt đối, ta có 4 định dạng, 4 cách đặt tên, 4 chuẩn chất lượng — không interoperate được. Vì vậy phi tập trung phải đi kèm federated governance: một tập chuẩn tối thiểu bắt buộc toàn cục (định dạng khoá, chuẩn định danh, chính sách bảo mật, access control), phần còn lại để domain tự quyết. "Tự do trong khuôn khổ".
• Cognitive load cho domain team. Bắt domain team vừa lo nghiệp vụ vừa lo dữ liệu có thể quá tải nếu platform chưa đủ trưởng thành. Đây là lý do platform team và enabling team phải đi trước — không thể decentralize khi chưa có nền tảng self-serve đỡ lưng.
• Rủi ro silo hoá lại. Nếu domain quá khép kín, dữ liệu lại thành ốc đảo. Data product với khả năng discoverable và data contract là cơ chế chống silo — dữ liệu phải dễ tìm, dễ dùng liên miền, không phải giấu trong domain.

Nguyên tắc phán đoán: nếu chi phí điều phối liên miền cao hơn chi phí trùng lặp, hãy ưu tiên tự chủ. Nếu ngược lại (như dữ liệu định danh khách hàng — sai một chút là sai toàn hệ thống), hãy tập trung phần cốt lõi đó.

Use case thực tế

Bối cảnh. NCB có đội data trung tâm 12 người phục vụ 4 khối nghiệp vụ: Thẻ, Tín dụng, Thanh toán, Huy động. Backlog trung bình một yêu cầu dữ liệu mới mất 6 tuần mới xong. Nguyên nhân điều tra được: 70% thời gian đội trung tâm dành để hiểu lại nghiệp vụ và hỏi đội nghiệp vụ, chỉ 30% là làm kỹ thuật thật.

Chuyển đổi theo sở hữu domain (thí điểm 6 tháng, chọn domain Thẻ và Tín dụng trước):

1. Tách platform team (3 người) từ đội trung tâm: dựng self-serve platform trên nền lakehouse sẵn có, cung cấp template tạo data product, catalog, orchestration.
2. Nhúng data engineer vào domain: 2 data engineer chuyển sang ngồi cùng team Thẻ, 2 sang team Tín dụng. Họ sở hữu ingest → transform → serve cho domain của mình.
3. Lập enabling team (2 người): dạy hai domain cách viết data contract, đo data quality, publish product; cam kết rút sau 3 tháng.
4. Xác định ranh giới: tách domain CIF làm source of truth định danh. Thẻ và Tín dụng tham chiếu cif_no, chỉ sở hữu thuộc tính riêng.
5. Chuẩn chung tối thiểu do federated governance đặt: khoá định danh là cif_no, mọi product publish kèm contract + phân loại nhạy cảm.

Kết quả sau 6 tháng (số minh hoạ theo mô hình dự kiến):

Chỉ số	Trước	Sau
Thời gian ra 1 data product mới (domain Thẻ)	6 tuần	~1.5 tuần
Sự cố phân loại sai do đổi mã nguồn không báo	~3/quý	~0 (domain tự biết)
Tỷ lệ thời gian đội KT làm việc kỹ thuật thật	30%	~65%
Định nghĩa "khách hàng active" xung đột	4 phiên bản	1 (chuẩn CIF) + ghi chú domain

Bài học rút ra: phần khó nhất không phải kỹ thuật, mà là (a) vẽ ranh giới domain đủ sạch, (b) đảm bảo platform đủ trưởng thành trước khi decentralize, và (c) đặt chuẩn chung tối thiểu cho dữ liệu định danh dùng chung.

Ghi nhớ

• Nguyên tắc số 1 của Data Mesh: phi tập trung quyền sở hữu dữ liệu theo domain nghiệp vụ — để đội hiểu dữ liệu nhất sở hữu dữ liệu đó, phá điểm nghẽn của đội data trung tâm.
• Mượn DDD: domain = lĩnh vực nghiệp vụ; bounded context = ranh giới trong đó một mô hình có nghĩa nhất quán. Chấp nhận nhiều mô hình "khách hàng" cùng tồn tại, mỗi cái đúng trong ngữ cảnh của nó.
• Ba loại data domain: source-aligned (gần hệ nguồn, sự thật vận hành), aggregate (tổng hợp nhiều nguồn), consumer-aligned (định hình theo nhu cầu dùng). Luồng phụ thuộc chảy một chiều source → aggregate → consumer.
• Domain team sở hữu trọn vòng đời: ingest → transform → serve, với data engineer nhúng trong domain. Nhưng domain lo dữ liệu & logic, platform lo hạ tầng.
• Chuyển từ "đội trung tâm làm hết" sang "domain tự chủ + nền tảng chung": đội trung tâm biến thành platform team + enabling team.
• Team Topologies ánh xạ trực tiếp: stream-aligned = domain team, platform team = data platform, enabling team = dạy chuẩn rồi rút, complicated-subsystem = phần chuyên môn sâu. Tương tác chính là X-as-a-Service.
• Dữ liệu dùng chung (khách hàng): tách domain CIF làm source of truth định danh; các domain khác tham chiếu cif_no và bổ sung góc nhìn riêng — mẫu shared kernel.
• Đánh đổi: tự chủ vs. trùng lặp (chấp nhận trùng lặp có kiểm soát, ghi rõ trong contract) và tự chủ vs. chuẩn chung (phi tập trung phải đi kèm federated governance đặt chuẩn tối thiểu).
• Vẽ ranh giới theo nghiệp vụ và quyền quyết định, không theo cấu trúc bảng. Decentralize chỉ thành công khi platform đã đủ trưởng thành đỡ lưng.