Bỏ qua đến nội dung chính

D2 Automation Knowledge

Thiết kế Automation từ Source of Truth, không từ Workflow Node

Phương pháp systems thinking để map event, state, deterministic decision, failure mode và evidence trước khi vẽ workflow n8n.

Biên soạn bởi: D2 Automation SystemsRà soát bởi: D2 Systems EngineeringXuất bản: 2026-08-21Cập nhật: 2026-08-21

Câu trả lời ngắn

Câu trả lời thực tế

Trước khi vẽ node, hãy định nghĩa 5 thứ: business event khởi động process, hệ thống sở hữu từng state, deterministic decision phải explicit, side effect cần idempotency và failure/recovery evidence operator cần. Sau đó workflow mới implement các trách nhiệm đó. Bắt đầu từ node thường tạo automation chạy được happy path nhưng không trả lời được 'bây giờ state thật là gì?' khi lỗi.

Engineering model

Event → source of truth → deterministic rule → side effect → evidence/recovery → workflow implementation

01 / Design rule

Đặt tên event chính xác

'New lead' hữu ích hơn 'webhook trigger'; 'order refund confirmed' hữu ích hơn 'HTTP request'. Business-event language giúp reasoning về ownership và outcome xuyên tool rõ hơn.

02 / Design rule

Một state cần một authoritative owner

Workflow có thể copy/sync data, nhưng phải biết hệ thống nào authoritative cho customer identity, order status, ticket ownership hay delivery state. Conflict không reconcile an toàn nếu mọi copy đều được coi là đúng ngang nhau.

03 / Design rule

Giữ decision boundary deterministic khi có thể

AI có thể classify ngôn ngữ mơ hồ, extract field hoặc draft content, nhưng application routing, SLA clock, financial threshold và permission check thường nên deterministic trừ khi có lý do rõ.

04 / Design rule

Thiết kế operator experience khi failure

Hỏi operator cần gì khi processing dừng: event ID, current state, last successful transition, error category, retry status và replay action. Nếu workflow không trả lời được, observability chưa hoàn chỉnh dù có log.

Checklist triển khai

Các câu hỏi cần chốt trước khi gọi workflow là production-ready.

  • Viết business event trong một câu
  • Chỉ rõ source of truth cho state quan trọng
  • Tách deterministic rule khỏi AI decision
  • Xác định side effect nhạy duplicate/irreversible
  • Định nghĩa failure evidence và operator recovery trước implementation

FAQ

Tại sao không thiết kế trực tiếp trong n8n?

Có thể prototype, nhưng node-first dễ trộn business state, routing và integration mechanics vào một canvas. System map ngắn trước giúp workflow choice có chủ đích và review được.

Source of truth trong automation là gì?

Là hệ thống/record authoritative sở hữu một state khi các copy conflict. Workflow có thể giữ projection/cache, nhưng conflict resolution nên theo declared owner trừ khi có reconciliation rule explicit.

Tiêu chuẩn evidence

Architecture knowledge, implementation evidence và production outcome là các mức claim khác nhau.

D2 công khai các boundary này. Methodology page giải thích evidence cần có trước khi một hệ thống được mô tả là implemented, validated hoặc production-backed.

Xem methodology về evidence

Áp dụng framework

Có workflow cần làm rõ architecture hoặc reliability boundary?

Trao đổi bài toán Automation →