𝗪𝗵𝘆 𝗜 𝗦𝘁𝗼𝗽𝗽𝗲𝗱 𝗪𝗿𝗶𝘁𝗶𝗻𝗴 𝗖𝗼𝗱𝗲 𝗮𝗻𝗱 𝗕𝗲𝗴𝗮𝗻 𝗗𝗲𝘀𝗶𝗴𝗻𝗶𝗻𝗴
Tôi từng nghĩ phát triển phần mềm nghĩa là viết các tính năng. Tôi nghĩ công việc của mình là tạo ra các thực thể (entities), xây dựng các bộ điều khiển (controllers) và kết nối cơ sở dữ liệu.
Một dự án gần đây đã thay đổi quan điểm của tôi. Tôi nhận ra rằng lập trình chỉ là một phần của giải pháp. Công việc thực sự diễn ra trước khi bạn viết dòng code đầu tiên.
Bạn phải quyết định về kiến trúc. Bạn phải tự hỏi tại sao nó phù hợp, chi phí là bao nhiêu và nó giải quyết được những rủi ro nào.
Dưới đây là những bài học chính của tôi:
• Kiến trúc phải phù hợp với giai đoạn của sản phẩm. Thật hấp dẫn khi muốn sử dụng ngay microservices, Kubernetes và các hàng đợi sự kiện (event queues) phức tạp. Đối với dự án của chúng tôi, chúng tôi đã chọn kiến trúc phân lớp (layered architecture) trong một tiến trình duy nhất. Điều này cho phép chúng tôi tách biệt các trách nhiệm mà không gặp phải sự đau đầu của một hệ thống phân tán. Khi mới bắt đầu, sự đơn giản thường tốt hơn.
• Một số quyết định có thể rẻ ở hiện tại nhưng lại đắt đỏ về sau. Chúng tôi đã thêm TenantId vào mô hình dữ liệu ngay từ ngày đầu tiên. Mặc dù lúc đó chỉ có một khách hàng, nhưng điều này giúp việc chuyển sang mô hình SaaS trong tương lai trở nên dễ dàng. Nếu bạn đợi quá lâu mới thêm tính năng multi-tenancy, việc di chuyển dữ liệu sẽ trở thành một cơn ác mộng.
• Thiết kế giúp ngăn chặn những ngõ cụt trong tương lai. Lập trình giải quyết một vấn đề tức thời. Thiết kế giải quyết một vấn đề mà không đóng lại các cánh cửa cho tương lai. Chúng tôi đã sử dụng container từ sớm để việc chuyển đổi sang các hạ tầng khác nhau trở nên dễ dàng. Chúng tôi sử dụng các interface để việc thay đổi nhà cung cấp trở nên đơn giản.
• Những thay đổi về kinh doanh thúc đẩy những thay đổi về kỹ thuật. Một hệ thống chuyển sang microservices vì doanh nghiệp phát triển. Một ứng dụng phòng khám đơn lẻ trở thành một nền tảng SaaS cho hàng trăm phòng khám. Sự chuyển dịch này thay đổi cách bạn xử lý thanh toán, đăng ký thuê bao và mở rộng quy mô (scaling).
• Sự tin cậy đòi hỏi các pattern thông minh. Chúng tôi đã chuyển từ các lời gọi đồng bộ (synchronous calls) sang kiến trúc hướng sự kiện (event-driven architecture). Trong một hệ thống y tế, một dịch vụ thông báo chậm không nên làm sập việc đặt lịch hẹn. Chúng tôi đã sử dụng Outbox pattern để đảm bảo dữ liệu luôn an toàn ngay cả khi message broker gặp lỗi.
• Các pattern phải phù hợp với domain. Đừng sử dụng các pattern một cách mù quáng. Việc chẩn đoán y tế cần sự nhất quán mạnh (strong consistency). Bạn không thể dựa vào sự nhất quán sau cùng (eventual consistency) để đảm bảo an toàn cho bệnh nhân. Đừng sử dụng cache cho các dữ liệu lâm sàng nhạy cảm nếu nó làm gián đoạn audit trail của bạn.
• DevOps không phải là một thứ được tính đến sau cùng. Triển khai (deployment), kiểm tra sức khỏe hệ thống (health checks) và các pipelines là một phần của thiết kế ban đầu. Bạn phải ước tính chi phí và chọn các thành phần thực sự phục vụ nhu cầu của mình.
Sự khác biệt giữa một lập trình viên và một nhà thiết kế nằm ở câu hỏi "tại sao".
Một lập trình viên hỏi: "Làm thế nào để cái này hoạt động?" Một nhà thiết kế hỏi: "Tại sao đây lại là giải pháp phù hợp cho vấn đề cụ thể này?"