Domain là gì và chia thế nào

Bài Xây codebase dùng chung cho team nói cách dựng module: service provider, Contracts, DTO, architecture test. Bài này nói phần khó hơn và đứng trước nó: cắt ở đâu.

Lý do phải tách riêng: tooling không cứu được ranh giới đặt sai chỗ. Chia sai thì càng nhiều interface, DTO và architecture test, hệ thống càng khó sửa — vì bạn vừa dựng hàng rào ngay giữa một nghiệp vụ liền mạch. Ngược lại, chia đúng thì kể cả không có module gì cả, chỉ cần thư mục thôi, code vẫn dễ sống.

Ví dụ xuyên suốt: hệ quản trị (admin/staff) cho một LMS (Learning Management System — hệ thống quản lý đào tạo). Cách làm áp dụng được cho mọi nghiệp vụ khác.

Thuật ngữ dùng trong bài

1. Nó là gì / chạy thế nào

1.1. Định nghĩa dùng được, không phải định nghĩa học thuộc

Sách DDD định nghĩa domain khá trừu tượng. Định nghĩa dùng được khi ngồi chia code:

Domain là một nhóm quy tắc nghiệp vụ (1) thay đổi cùng nhau, vì (2) cùng một người quyết định chúng đúng hay sai.

Hai vế đó làm ra hai câu hỏi kiểm tra nhanh, dùng được ngay trong buổi họp:

• Câu hỏi thay đổi: "Khi quy tắc X đổi, còn quy tắc nào buộc phải đổi theo?" Những cái đổi theo nhau thuộc cùng một domain.
• Câu hỏi thẩm quyền: "Ai là người duy nhất có quyền nói quy tắc này sai?" Cùng một người/phòng ban → cùng một domain.

Chú ý cả hai câu đều hỏi về quy tắc và con người — không hỏi về bảng, model, màn hình hay API. Đó là chỗ đa số team chia sai.

1.2. Ba cách chia sai hay gặp

Kiểm chứng cách chia bằng một phép thử rẻ: lấy 5 yêu cầu thay đổi gần nhất trong Jira, xem mỗi yêu cầu chạm vào bao nhiêu domain.

1.3. Chỉ dấu mạnh nhất: cùng một từ, nhiều nghĩa

Nếu chỉ được giữ một công cụ để tìm ranh giới, giữ cái này: đi hỏi từng phòng ban định nghĩa của cùng một từ. Chỗ nào định nghĩa lệch nhau, chỗ đó là biên.

Trong LMS, từ "học viên" có ít nhất ba nghĩa:

Ba nghĩa, ba bộ dữ liệu, ba phòng ban, ba nhịp thay đổi. Ép cả ba vào một model Student thì được một class 60 cột mà ai sửa cũng sợ.

1.4. Domain, bounded context, aggregate — xếp theo cỡ

Ba từ này hay bị dùng lẫn. Xếp từ to xuống nhỏ:

flowchart TB
  A["Domain: Đào tạo
(cả mảng nghiệp vụ của phòng Đào tạo)"]
  A --> B1["Bounded context: Scheduling
từ vựng: lớp, buổi, phòng, phân công"]
  A --> B2["Bounded context: Learning
từ vựng: điểm danh, bài nộp, hạn nộp"]
  B2 --> C1["Aggregate: Enrollment
enrollments + attendances
ghi cùng lúc, cùng transaction"]
  B2 --> C2["Aggregate: Submission
submissions + files"]

Trong code Laravel, thực tế gọn lại còn hai mức:

• Bounded context → một thư mục trong app/Domain/. Đây là thứ bài này gọi tắt là "domain", vì đó là đơn vị mà code thật sự chia theo.
• Aggregate → một nhóm model + một service/action ghi chúng trong cùng một DB::transaction(). Không cần thư mục riêng.

Đừng dựng thư mục cho aggregate. Một số team đẻ Domain/Learning/Aggregates/Enrollment/ có đủ Repository, Factory, Event Store. Trừ khi đang làm event sourcing thật, đó là chi phí thuần: Eloquent + một transaction đã đủ giữ bất biến của aggregate.

2. Tiêu chí: khi nào một nghiệp vụ thành domain riêng

2.1. Bảy câu hỏi, chấm điểm trên 10

Hai câu đầu tính hệ số 2 vì chúng là chỉ dấu bền nhất — năm câu còn lại có thể đổi khi codebase lớn lên, hai câu đầu thì không.

Cách đọc điểm:

flowchart TB
  S["Chấm 7 câu → tổng /10"] --> G{"Câu 1 hoặc câu 2
có ít nhất 1 cái?"}
  G -->|"không"| R1["KHÔNG tách.
Đây là một chức năng, không phải một miền.
Để nó là service trong domain gần nhất."]
  G -->|"có"| P{"Tổng điểm?"}
  P -->|"≥ 7"| D1["Domain riêng:
thư mục app/Domain/X/ + Contracts khi có người gọi"]
  P -->|"4 - 6"| D2["Sub-domain:
thư mục con trong domain lớn hơn,
chưa cần Contracts riêng"]
  P -->|"≤ 3"| D3["Không tách:
một class service là đủ"]

Điều kiện chặn quan trọng nhất: nếu cả câu 1 và câu 2 đều "không" thì dừng — dù năm câu sau đúng hết. Không có từ vựng riêng và không có người chủ riêng nghĩa là thứ bạn đang nhìn là một chức năng (feature), không phải một miền (domain). Tách nó ra chỉ tạo thêm một hàng rào mà không ai bảo vệ.

2.2. Phản-tiêu chí: dấu hiệu KHÔNG nên tách

Năm lý do nghe hợp lý nhưng đều sai:

2.3. Hướng phụ thuộc: chảy về phía ổn định hơn

Chia đúng chưa đủ — còn phải quyết ai được gọi ai. Một luật duy nhất:

Phụ thuộc chỉ được chảy về phía đổi ít hơn. Domain đổi nhiều được biết domain đổi ít. Ngược lại thì cấm.

Trong LMS: Catalog (chương trình, khoá học, tín chỉ) là thứ ổn định nhất — đổi mỗi năm học một lần. Finance đổi nhiều nhất — khuyến mãi, chính sách trả góp, luật thuế. Vậy Finance → Catalog được; Catalog → Finance thì cấm. Nếu Catalog cần phản ứng khi hoá đơn thanh toán xong, nó nghe event, không gọi thẳng.

3. Ví dụ đầy đủ: chia domain cho hệ admin LMS

3.1. Bước 1 — liệt kê nghiệp vụ thô, chưa gom

Không bắt đầu từ bảng, không bắt đầu từ menu. Bắt đầu từ câu trả lời cho câu hỏi: nhân viên nào ngồi làm việc gì cả ngày.

tuyển sinh / chăm lead        ký hợp đồng             xếp lớp đầu vào
khoá học & chương trình        điều kiện tiên quyết     lớp học phần
lịch học & phòng               phân công giảng viên     điểm danh
bài tập & bài nộp              ngân hàng câu hỏi        đề thi & ca thi
chấm điểm & bảng điểm          phúc khảo               cấp chứng chỉ
học phí & hoá đơn              công nợ & nhắc nợ        hoàn tiền
thông báo email/SMS            người dùng & phân quyền  báo cáo & dashboard
nhật ký thao tác (audit)       import/export Excel

3.2. Bước 2 — chấm điểm từng cái

Bảng dưới là kết quả chấm theo bảy câu ở mục 2.1. Cột tiêu đề viết tắt: Từ = từ vựng riêng (×2), Chủ = người chủ riêng (×2), Nhịp = nhịp đổi riêng, Ghi = sở hữu bảng riêng, Đời = vòng đời riêng, Tắt = tắt đi vẫn chạy, To = đủ lớn.

Chú ý chỗ "Thông báo" bị loại. Nó có từ vựng riêng thật (kênh, template, bounce, retry) nhưng đó là từ vựng kỹ thuật, không phải từ vựng nghiệp vụ. Câu hỏi quyết định: "quy tắc ai được nhận thông báo gì do ai quyết?" — do chính domain gửi quyết (Finance quyết ai bị nhắc nợ, Learning quyết ai bị cảnh báo vắng). Notification chỉ chuyển tin, nên nó là capability. Chi tiết ở bài Gửi thông báo đa kênh.

3.3. Bước 3 — xử lý các ca khó

Sáu domain ở trên là phần dễ. Giá trị thật nằm ở những nghiệp vụ nằm giữa hai domain. Với mỗi ca, câu hỏi quyết định luôn là câu số 2: ai đổi quy tắc này?

3.4. Bước 4 — cấu trúc thư mục

app/
  Domain/
    Admission/     Catalog/       Scheduling/
    Learning/      Assessment/    Finance/
      Models/          ← Eloquent của riêng domain này
      Services/        ← quy tắc nghiệp vụ
      Actions/         ← 1 việc = 1 class, khi service phình to
      Events/          ← thứ domain khác được phép nghe
      Policies/
      Data/            ← DTO công bố ra ngoài (tạo khi có người gọi)
      Contracts/       ← "cửa trước" (tạo khi có người gọi)

  Support/             ← shared kernel: User, Role, Tenant, Money, DateRange
  Reporting/           ← chỉ đọc, được phép đọc mọi Domain
  Notification/        ← capability: kênh gửi, template

  Http/Controllers/Admin/
    Admission/  Catalog/  Scheduling/  Learning/  Assessment/  Finance/

Vì sao controller KHÔNG nằm trong app/Domain/. Controller thuộc về giao diện, không thuộc về miền. Ngày mai thêm API cho app mobile, thêm một lệnh artisan, thêm một webhook — cả ba cùng gọi một service. Nếu controller nằm trong domain thì domain phải biết mình đang được gọi từ HTTP. Để controller ở chỗ Laravel đặt sẵn, chỉ nhóm thư mục con theo domain cho dễ tìm.

Điểm quan trọng về chi phí: Contracts/ và Data/ chưa cần tạo ngay. Ngày đầu chỉ có 6 thư mục domain + một architecture test. Cửa trước chỉ dựng khi có domain thứ hai thật sự gọi tới — chi tiết cách dựng ở bài codebase dùng chung, mục 1.5.

3.5. Bước 5 — ma trận ai được gọi ai

Đọc bảng: ✓ cửa = gọi được nhưng chỉ qua Contracts\. ✗ event = không gọi ngược được, muốn phản ứng thì nghe event. ✓ đọc = Reporting được join thẳng vào bảng, nhưng cấm ghi.

Ma trận này không phải tài liệu — nó là một file test. Với pestphp/pest-plugin-arch (đã có sẵn trong Laravel 11+):

<?php
// tests/Arch/DomainBoundaryTest.php

$domains = ['Admission', 'Catalog', 'Scheduling', 'Learning', 'Assessment', 'Finance'];

foreach ($domains as $self) {
    $others = array_values(array_diff($domains, [$self]));

    // Ruột domain khác: cấm. Cửa trước (Contracts\, Data\) thì được.
    arch("domain {$self} khong cham ruot domain khac")
        ->expect("App\\Domain\\{$self}")
        ->not->toUse(array_map(fn ($o) => "App\\Domain\\{$o}", $others))
        ->ignoring(array_merge(
            array_map(fn ($o) => "App\\Domain\\{$o}\\Contracts", $others),
            array_map(fn ($o) => "App\\Domain\\{$o}\\Data", $others),
            array_map(fn ($o) => "App\\Domain\\{$o}\\Events", $others),
        ));
}

// Hướng phụ thuộc: Catalog là nền, không được biết ai cả.
arch('catalog khong phu thuoc domain nao')
    ->expect('App\Domain\Catalog')
    ->not->toUse(array_map(fn ($o) => "App\\Domain\\{$o}", array_diff($domains, ['Catalog'])));

// Reporting chi doc: khong duoc goi Services (noi co lenh ghi).
arch('reporting khong ghi gi')
    ->expect('App\Reporting')
    ->not->toUse(array_map(fn ($o) => "App\\Domain\\{$o}\\Services", $domains));

// Tang HTTP khong duoc cham thang Models.
arch('controller khong cham model')
    ->expect('App\Http\Controllers')
    ->not->toUse(array_map(fn ($o) => "App\\Domain\\{$o}\\Models", $domains));

Chưa verify trên máy thật. Đoạn trên viết theo tài liệu Pest arch testing (toUse, ignoring). Repo này chưa có dự án Laravel để chạy thử, nên coi nó là bản mẫu cần chạy lại khi áp dụng. Bản PHPUnit thuần 27 dòng đã chạy thật và có output nằm ở bài codebase dùng chung mục 1.6 — nếu chỉ cần đúng một luật thì dùng bản đó, không phải thêm package.

4. Lợi ích

5. Tác hại / hạn chế

• Chia sai đắt hơn không chia. Ranh giới sai = hàng rào giữa hai thứ đáng lẽ đi chung. Mỗi feature phải đi vòng qua cửa, qua DTO, qua event — cho một việc lẽ ra là một câu UPDATE. Và càng lâu càng khó sửa vì đã có code dựa vào cái cửa sai đó.
• Ranh giới trong code không phải ranh giới trong DB. Sáu domain vẫn join chung một schema. Ngày muốn tách service thật, chỗ đau là dữ liệu, không phải namespace. Đừng nói với sếp là "chia domain xong thì tách microservice dễ" — nó chỉ dễ hơn một phần nhỏ.
• Báo cáo là kẻ thù tự nhiên. Màn hình "học viên nợ học phí và sắp rớt môn" đụng Finance + Learning + Assessment. Tuân luật thì 3 lần gọi cửa rồi gộp trong PHP — không phân trang được, không sắp xếp chéo cột được. Đó là lý do phải có Reporting được miễn luật.
• Có vài nghiệp vụ thật sự nằm giữa. Không phải cái gì cũng có câu trả lời sạch. Khi bí, chọn đại một bên, ghi lại lý do trong một file docs/domain-map.md, và đặt lịch xem lại sau 3 tháng. Tranh luận quá 30 phút là dấu hiệu hai lựa chọn tương đương nhau.
• Tên domain có thể sai theo thời gian. Tổ chức tái cơ cấu, phòng Khảo thí sáp nhập vào Đào tạo → ranh giới theo Conway's law cũng nên đổi theo. Đây là chi phí thật, khoảng vài ngày mỗi lần.
• Không giải quyết được gì về hiệu năng. Chia domain không làm app nhanh hơn một mili-giây nào. Đo thật ở bài codebase dùng chung: 31 module không làm app chậm hơn — và cũng không nhanh hơn.

6. Trade-off

6.1. Chia mịn hay chia thô

Khi phân vân, chia thô hơn. Tách một domain to thành hai là việc cơ học (di chuyển file, IDE làm được). Gộp hai domain đã có cửa, DTO và event giữa chúng thì phải gỡ cả đống code trung gian. Sai theo hướng thô rẻ hơn sai theo hướng mịn.

6.2. Chia theo nghiệp vụ hay chia theo team

Hai cái này thường trùng nhau (Conway's law), nhưng khi lệch:

• Team ổn định, nghiệp vụ còn đổi (startup, sản phẩm mới) → chia theo team. Ranh giới trùng với người thì conflict ít nhất, và nghiệp vụ đổi thì đổi bên trong một domain.
• Nghiệp vụ ổn định, team hay đổi (outsourcing, dự án chạy lâu) → chia theo nghiệp vụ. Người đến người đi, ranh giới nghiệp vụ vẫn đúng.

6.3. Các cặp chọn lựa hay bị hỏi

7. Khó khăn khi vận hành thực tế

8. Case thực tế và cách xử lý

Case 1 — Chia theo bảng, một yêu cầu phải sửa 4 chỗ

Tình huống: Team chia Student, Course, Class, Grade theo bảng. Giáo vụ yêu cầu "vắng quá 20% buổi thì cấm thi". Hoá ra phải sửa: Student (thêm cột absent_rate), Class (đếm buổi), Grade (chặn nhập điểm thi), Course (cấu hình ngưỡng 20% theo môn). Sửa xong quên chỗ thứ tư, bảng điểm sai 2 tuần.

Xử lý từng bước:

1. Tìm người chủ thật của quy tắc: giáo vụ đào tạo → domain Learning.
2. Gom quy tắc vào một chỗ: Learning\Services\AttendanceRule::canSit($enrollmentId): bool. Ngưỡng 20% là một hằng số, tồn tại đúng một lần.
3. Các chỗ khác hỏi thay vì tự tính: Assessment gọi LearningReader::canSit() trước khi cho nhập điểm.
4. Thêm architecture test cấm domain khác use model Attendance.
5. Xoá cột students.absent_rate — dữ liệu dẫn xuất lưu trùng là nguồn gốc của lệch số.

Case 2 — Hai domain cần ghi trong cùng một transaction

Tình huống: "Ghi nhận thanh toán xong thì mở khoá học ngay." Finance ghi payments, Learning ghi enrollments.status = active. Dev viết một DB::transaction() ôm cả hai, import thẳng model của nhau, architecture test đỏ.

Xử lý — ba mức, chọn theo yêu cầu nghiệp vụ:

1. Mức rẻ nhất (nên thử trước): Finance gọi cửa LearningWriter::activate($enrollmentId) bên trong transaction của nó. Vẫn một transaction, vẫn đúng ranh giới, chỉ là đi qua interface. Đây là lối thoát cho 90% trường hợp.
2. Nếu chấp nhận trễ vài giây: Finance commit rồi phát PaymentReceived; Learning nghe và mở khoá. Nhớ dùng Event::dispatch() trong DB::afterCommit(), và listener phải idempotent (chạy 2 lần vẫn đúng) — chi tiết ở bài at-least-once.
3. Nếu hai thứ luôn phải đúng cùng lúc, không chấp nhận trễ một giây nào: ranh giới đang sai. "Thanh toán" và "mở khoá" có thể là một nghiệp vụ — cân nhắc gộp phần đó thành một domain Enrollment sở hữu cả hai.

Case 3 — Màn hình báo cáo đụng 3 domain, đi đúng luật thì chậm

Tình huống: Dashboard "học viên nợ học phí và có nguy cơ rớt". Đi đúng luật: gọi FinanceReader::debtors() ra 800 ID, gọi AssessmentReader::atRisk($ids), gộp trong PHP. Không phân trang được, không sắp xếp theo cột của domain kia được, 2,4 giây.

Xử lý:

1. Chấp nhận app/Reporting/ được miễn luật đọc: join thẳng invoices + grades trong một query. Kèm architecture test cấm nó use bất kỳ Services\ nào — đọc thì được, ghi thì không.
2. Nếu báo cáo nhiều và nặng: dựng read model riêng — một bảng tổng hợp cập nhật theo event, hoặc materialized view (bảng kết quả query được lưu sẵn, làm mới định kỳ) trong PostgreSQL.
3. Đừng mở cửa domain rộng ra chỉ để báo cáo dùng được. Cửa mở cho báo cáo thì tuần sau có người khác dùng cửa đó để ghi.

Case 4 — Sáu tháng sau, phòng Khảo thí sáp nhập vào Đào tạo

Tình huống: Ranh giới Assessment / Learning chia theo hai phòng ban. Giờ một trưởng phòng quản cả hai, và mọi yêu cầu đều đụng cả hai domain.

Xử lý:

1. Đo trước khi quyết: đếm PR 3 tháng gần nhất chạm cả hai domain. Dưới 30% thì để yên — tổ chức đổi không có nghĩa code phải đổi ngay.
2. Trên 60% thì gộp: Assessment thành thư mục con của Learning, xoá Contracts giữa hai bên, giữ lại Contracts ra bên ngoài.
3. Gộp là refactor cơ học: đổi namespace, chạy test, một buổi chiều. Đây chính là lý do mục 6.1 khuyên chia thô.

Case 5 — Đang ở codebase phẳng, muốn chia mà không dám dừng feature

Xử lý — chia dần, không big bang:

1. Tuần 1: tạo app/Domain/ rỗng + architecture test chưa bật luật nào. Chỉ có khung.
2. Tuần 2: chuyển một domain rõ ràng nhất (thường là Finance — kế toán luôn là ranh giới sắc nhất) vào app/Domain/Finance/. Không sửa logic, chỉ move + đổi namespace.
3. Bật một luật: "không ai ngoài Finance được use Finance\Models\". Sửa hết chỗ đỏ — đây là lúc phát hiện coupling thật sự nằm ở đâu.
4. Lặp lại mỗi 2–3 tuần với domain tiếp theo. Code chưa chuyển cứ để nguyên ở app/Models/, app/Services/ — hai kiểu sống chung được.
5. Domain cuối cùng còn lại trong app/Services/ thường là phần mơ hồ nhất. Lúc đó đã đủ hiểu để quyết.

9. Câu hỏi phụ interviewer hay hỏi tiếp

"Domain khác module ở chỗ nào?" — Domain là khái niệm nghiệp vụ (nhóm quy tắc + người chủ). Module là cách hiện thực nó trong code (thư mục + service provider + cửa). Một domain có thể chưa được module hoá — vẫn là domain.

"Chia domain trước hay chia bảng trước?" — Domain trước. Bảng là hệ quả. Chia bảng trước thì gần như chắc chắn ra cấu trúc theo danh từ, và mỗi quy tắc nghiệp vụ nằm rải ở 3–4 chỗ.

"Làm sao biết đã chia sai?" — Ba tín hiệu đo được: (1) trung bình một PR chạm > 3 domain; (2) số ngoại lệ trong architecture test tăng đều mỗi tháng; (3) có bảng bị 2+ domain cùng UPDATE. Tín hiệu (3) nặng nhất.

"Một domain nên to bao nhiêu?" — Không có con số đúng, nhưng có mốc kiểm tra: một người mới phải đọc hiểu được cả domain trong một ngày. Quá to thì tách; quá nhỏ (dưới ~5 file) thì gộp.

"Domain có được có bảng riêng, database riêng không?" — Bảng riêng: có, và nên. Database riêng: chưa, trong monolith. Tách DB là bước của microservice, và khi đó mất luôn transaction chung — phải đổi sang saga (chuỗi bước có bước bù trừ khi hỏng). Đừng trả giá đó khi chưa cần.

"Event giữa các domain có làm hệ thống khó debug không?" — Có, thật. Đó là lý do chỉ dùng event cho phản ứng (thứ chậm vài giây cũng được), còn thứ cần ngay thì gọi cửa đồng bộ. Mỗi event thêm vào là thêm một đường đi vô hình trong stacktrace.

"Nếu nghiệp vụ chưa rõ thì chia thế nào?" — Chưa chia. Viết phẳng, gom theo thư mục, đợi 3–6 tháng cho ranh giới tự lộ ra qua các yêu cầu thay đổi. Chia domain dựa trên phỏng đoán là cách đắt nhất để sai.

"DDD có bắt buộc phải dùng Repository, Value Object, Aggregate Root không?" — Không. Phần giá trị nhất của DDD là strategic design (chia bounded context, thống nhất ngôn ngữ) — đó là phần bài này nói. Phần tactical (Repository, VO, Aggregate Root) là tuỳ chọn, và trên Eloquent thì Repository thường là lớp thừa.

Trả lời trong 60 giây (bản dùng khi phỏng vấn)

"Domain với tôi là một nhóm quy tắc nghiệp vụ đổi cùng nhau vì cùng một người quyết. Nên tôi không chia theo bảng hay theo màn hình — chia theo bảng thì một yêu cầu đổi phải sửa 4 chỗ.

Để quyết một nghiệp vụ có thành domain riêng không, tôi hỏi bảy câu, nhưng hai câu đầu nặng nhất: nó có từ vựng riêng không — tức là có từ nào ra khỏi vùng đó thì đổi nghĩa; và nó có đúng một người chủ không. Nếu cả hai đều không thì dù các tiêu chí khác đúng hết tôi vẫn không tách, vì đó là một chức năng chứ không phải một miền. Năm câu còn lại là nhịp đổi riêng, có bảng chỉ nó được ghi, có vòng đời riêng, tắt đi hệ thống vẫn chạy, và đủ to.

Ví dụ LMS tôi chia sáu domain: Admission, Catalog, Scheduling, Learning, Assessment, Finance. Ba thứ bị loại là phân quyền — đó là shared kernel vì tắt đi thì chết; báo cáo — đó là read model được miễn luật để join thẳng; và thông báo — đó là capability, vì quy tắc ai nhận gì do domain gửi quyết chứ không phải nó.

Điểm tôi cẩn thận nhất là không đẻ domain cho danh từ. Không có domain Student. Có users ở shared kernel giữ danh tính, còn mỗi domain giữ vai riêng — Applicant, Enrollment, Payer — khoá theo cùng user_id. Và một luật về hướng phụ thuộc: chỉ chảy về phía đổi ít hơn, Finance biết Catalog chứ Catalog không biết Finance. Luật đó nằm trong architecture test, không nằm trong tài liệu."