Midi Coder Blog
Các bài viết gắn thẻ DSL.
Policy và RBAC chỉ nên xuất hiện trong contract dưới dạng quy tắc có thể thi công, kiểm tra và truy vết. Một contract tốt không ôm hết mọi thứ, cũng không mô tả lại code; nó khóa đúng phạm vi, đúng ngôn ngữ và làm cho đầu ra ít bất ngờ hơn.
Đọc bài viết →
Một HTTP contract tốt không phải là tài liệu dài cho đủ ý, mà là bản mô tả đủ rõ để đội thi công tạo ra code dùng được, ít bất ngờ và dễ kiểm soát thay đổi. Vấn đề cốt lõi là xác định đúng phạm vi của contract, tách các lớp mô tả và buộc những phần quan trọng phải có cấu trúc.
Đọc bài viết →
Scenarios trong contract giúp kỹ thuật và nghiệp vụ chốt cùng một cách hiểu về luồng xử lý, ràng buộc và đầu ra, để contract thật sự dùng được cho thi công thay vì chỉ là tài liệu tham khảo.
Đọc bài viết →
Khi mới tiếp cận contract-first và DSL, nhiều đội ngũ dễ biến contract thành tài liệu dài dòng, khó thi công hoặc bám sát code đến mức mất giá trị thiết kế. Bài viết này chỉ ra 10 lỗi thường gặp và cách viết contract ngắn, rõ, có cấu trúc để tăng traceability và giảm bất ngờ ở đầu ra.
Đọc bài viết →
Khi làm việc theo hướng contract-first, không phải lúc nào cũng nên mở DSL contract ra sửa tay. Bài viết này phân biệt rõ lúc nên chỉnh trực tiếp để khóa yêu cầu thi công, lúc nên comment để hệ thống cập nhật an toàn, có traceability và ít tạo bất ngờ cho đầu ra.
Đọc bài viết →
Một contract tốt không được đo bằng số trang mà bằng khả năng khóa đúng quyết định để đội ngũ thi công ít hiểu sai hơn. Bài viết phân tách các lớp contract cốt lõi, chỉ ra phần nào cần ngắn gọn, phần nào phải có cấu trúc rõ ràng, và cách tránh biến contract thành giấy tờ vô dụng hoặc bản sao của code.
Đọc bài viết →
Một bộ contract tối thiểu của Midi Coder nên đủ chặt để dùng cho thi công, nhưng đủ gọn để không biến thành giấy tờ. Cốt lõi thường gồm 6 lớp: domain, app, rule, workflow, policy và API, được viết bằng ngôn ngữ hẹp, có cấu trúc và truy vết rõ ràng.
Đọc bài viết →
Contract tốt không phải là tài liệu dài, mà là tài liệu khóa đúng phạm vi, dùng đúng ngôn ngữ và đủ cấu trúc để đội thi công có thể triển khai ít suy diễn. Bài viết này trình bày cách tách các lớp contract cốt lõi, viết ngắn phần nên ngắn, viết rõ phần bắt buộc phải rõ, và tránh biến contract thành giấy tờ vô dụng.
Đọc bài viết →
Một cây contract tốt không phải là bộ tài liệu dài dòng, mà là cấu trúc đủ rõ để đội ngũ đọc cùng một nghĩa và thi công ra hệ thống ít bất ngờ hơn. Bài viết này giải thích cách đọc và thiết kế các lớp glossary, domain, app, rules, workflows, policy và API để contract trở thành đầu vào vận hành được cho software factory.
Đọc bài viết →
Tách value object, events và queries đúng lúc giúp contract đủ chặt để thi công, nhưng không biến thành tài liệu rườm rà. Bài viết này chỉ ra cách khóa phạm vi, chọn ngôn ngữ mô tả và phân lớp contract để code đầu ra ít bất ngờ hơn.
Đọc bài viết →