Khi Phân Tán Hệ Thống Trở Thành Lối Thoát Cho Một Thiết Kế Yếu Kém

Rất nhiều kiến trúc phần mềm hiện đại—microservices, hệ thống điều khiển bởi sự kiện (event-driven), CQRS—không thực sự được sinh ra từ sự thấu hiểu sâu sắc về miền (domain). Chúng là những gì mà các đội ngũ hướng tới khi ứng dụng hiện tại đã trở nên một mớ hỗn độn: không ai thực sự biết điều gì đang diễn ra ở đâu, hành vi trở nên khó dự đoán và việc thay đổi code cảm thấy rủi ro cùng cực.

Thay vì tự hỏi "Khái niệm này thực sự có ý nghĩa gì và nó thuộc về đâu?", họ lại hỏi "Làm thế nào để chia nhỏ cái này ra?"

Đó chính là nơi khởi đầu của rất nhiều kiến trúc hiện đại.

Không phải vì sự cần thiết.

Không phải vì sự thấu hiểu.

Mà vì sự khó chịu ngày càng tăng khi cố gắng quản lý những phần mềm chưa bao giờ được mô hình hóa tốt ngay từ đầu.

Và bởi vì hệ thống kết quả vẫn chạy được trên môi trường sản xuất (production), chi phí của sự thay đổi này thường vẫn vô hình trong nhiều năm.

Đó là một trong những cái bẫy đắt đỏ nhất trong phát triển phần mềm.

Sự thành thạo Framework không phải là Thiết kế Phần mềm

Ngày nay, rất nhiều lập trình viên cực kỳ thành thạo các framework. Họ biết cách xây dựng controllers, services, repositories, DTOs, entities, các tích hợp và cấu hình.

Từ bên ngoài, điều đó thường trông giống như năng lực.

Nhưng sự thành thạo đó có thể gây hiểu lầm sâu sắc.

Bởi vì xây dựng phần mềm từ các bộ phận quen thuộc của framework không giống với việc thiết kế phần mềm tốt.

Những câu hỏi thực sự thì khác biệt:

• Khái niệm kinh doanh thực tế ở đây là gì?
• Cái gì thuộc về cùng nhau?
• Hành vi nào là vốn có của domain?
• Ranh giới nào là thật, và ranh giới nào chỉ là chi tiết triển khai?
• Quy tắc nào nên được làm rõ trong mô hình thay vì được ngụ ý bởi sự điều phối (orchestration)?

Lập mô hình domain thực sự không phải là áp dụng một danh mục các mẫu thiết kế (pattern). Đó là công việc kỷ luật, thường đầy khó chịu, để khám phá cái gì thuộc về nhau, hành vi nào là vốn có, và diễn đạt các khái niệm đó một cách rõ ràng và gắn kết nhất có thể—dù chúng nằm trong modules, functions, hay những đối tượng đơn giản. Mục tiêu là sự toàn vẹn về khái niệm, không phải là nghi lễ kiến trúc.

Nếu không có những câu hỏi đó, phần mềm có xu hướng lấy một hình dạng rất dễ dự đoán: các lớp service quá cồng kềnh, các thực thể thiếu máu (anemic entities), thiết kế lấy sự lưu trữ làm trọng tâm (persistence-first), các quy trình thủ tục, và logic kinh doanh bị lan man khắp các lớp.

Code vẫn chạy. Các endpoint trả về dữ liệu. Database lưu trữ trạng thái.

Nhưng hệ thống thực sự chưa được thiết kế.

Nó chỉ được lắp ráp.

Và sự khác biệt đó quan trọng hơn nhiều so với phần lớn các đội ngũ nhận ra.

Mô hình yếu tạo ra sự quá tải nhận thức (Cognitive Overload)

Chi phí của thiết kế kém thường không xuất hiện ngay lập tức. Lúc đầu, hệ thống vẫn cảm thấy dễ quản lý. Một vài controllers. Một vài services. Một vài repositories. Mọi thứ vẫn "sạch sẽ".

Nhưng theo thời gian, điều gì đó bắt đầu xảy ra. Các quy tắc kinh doanh tích lũy. Các ngoại lệ xếp chồng lên nhau. Các yêu cầu mới tương tác với các giả định cũ. Các khái niệm trông có vẻ đơn giản hóa ra lại liên quan đến nhau theo những cách mà phần mềm không bao giờ nắm bắt được.

Và vì không có một mô hình domain mạnh mẽ giữ các khái niệm đó lại với nhau, sự phức tạp không đi đến đâu một cách hợp lý. Vì vậy, nó "rò rỉ" — vào các phương thức service, các luồng điều phối, code kết nối (glue), logic lưu trữ, các điều kiện đặc biệt, các "trừu tượng" hỗ trợ, và code điều phối.

Đến lúc đó, đội ngũ bắt đầu cảm thấy một điều rất thật:

Không ai hiểu toàn bộ hệ thống nữa.

Và đó là thời điểm then chốt.

Bởi vì một khi hệ thống trở nên quá tải về mặt nhận thức, đội ngũ có hai lựa chọn:

Lựa chọn A

Giảm sự phức tạp bằng cách cải thiện mô hình.

Lựa chọn B

Giảm phạm vi của sự nhầm lẫn bằng cách chia nhỏ nó ra.

Rất nhiều đội ngũ chọn Lựa chọn B.

Phân tán trở thành sự bồi thường

Đây là nơi kiến trúc thường ngừng trở thành một lựa chọn thiết kế và bắt đầu trở thành một cơ chế đối phó.

Khi mô hình nội tại yếu, các đội ngũ vẫn cần một cách nào đó để tạo trật tự. Và sự phân tán (distribution) mang lại cho họ một cách.

Vì vậy, họ giới thiệu microservices, kiến trúc điều khiển bởi sự kiện, CQRS, các mô hình đọc riêng biệt (separate read models), ranh giới sở hữu, hàng đợi (queues), và sự điều phối không đồng bộ.

Phân tán, CQRS và kiến trúc điều khiển bởi sự kiện có thể có những công dụng hợp pháp trong các trường hợp hiếm hoi cần quy mô cực lớn hoặc các ranh giới tổ chức không thể tránh khỏi. Nhưng trong đại đa số các hệ thống, chúng không được giới thiệu vì domain yêu cầu chúng. Chúng được giới thiệu vì mô hình nội tại quá yếu để cung cấp sự rõ ràng. Những gì trông giống như kiến trúc tinh vi thường chỉ là sự nhầm lẫn ẩn mình sau các ranh giới dịch vụ sạch đẹp hơn.

Những gì họ thực sự làm là này:

Họ đang cố gắng tạo ra ở bên ngoài, thông qua sự phân tán, các ranh giới mà họ đã thất bại trong việc tạo ra ở bên trong, thông qua thiết kế.

Và điều đó có thể hoạt động. Ít nhất là trong một thời gian.

Một dịch vụ nhỏ hơn cảm thấy dễ hiểu hơn một monolith lớn. Một mô hình đọc riêng biệt có giảm ma sát. Một hàng đợi có tạo ra sự gỡ kết nối cục bộ.

Nhưng không có nghĩa là phần mềm đã trở nên tốt hơn về mặt khái niệm. Nó thường chỉ có nghĩa là sự nhầm lẫn đã được cắt thành các thùng chứa nhỏ hơn.

Sự rõ ràng cục bộ đi kèm với chi phí toàn cầu

Sự đánh đổi này là nơi gây ra thiệt hại thực sự.

Bởi vì sự phân tán hoàn toàn có thể tạo ra ngữ cảnh cục bộ. Một đội ngũ có thể nói: "Dịch vụ này quản lý thanh toán (billing)". Và điều đó có giúp ích.

Nhưng đó là một hình thức rõ ràng yếu hơn nhiều so với một mô hình domain thực sự. Một ranh giới dịch vụ có thể cho bạn biết code nằm ở đâu. Một mô hình tốt có thể cho bạn biết một thứ là gì, nó có ý nghĩa gì, quy tắc nào chi phối nó, vòng đời của nó ra sao, và các mối quan hệ nào là thiết yếu.

Đó là những cấp độ hiểu biết rất khác nhau.

Và khi các đội ngũ sử dụng sự phân tán để sản xuất ngữ cảnh, họ thường đạt được khả năng quản lý ngắn hạn nhưng đánh đổi sự linh hoạt dài hạn. Bởi vì bây giờ hệ thống bắt đầu trả "thuế phân tán": lỗi mạng, tính nhất quán cuối cùng (eventual consistency), sự trôi dạt của hợp đồng (contract drift), các khái niệm trùng lặp, logic trùng lặp, chi phí điều phối, sự phức tạp khi triển khai, gánh nặng vận hành và quan hệ nhân quả bị cắt vụn.

Và có lẽ quan trọng nhất: mất khả năng tái cấu trúc (refactorability).

Khi mô hình mạnh và gắn kết, việc thay đổi suy nghĩ thường chỉ có nghĩa là tái cấu trúc cục bộ—đôi khi là sự sụp đổ dễ chịu của các khái niệm. Khi các ranh giới đã được cứng hóa thành các dịch vụ, sự hiểu biết tương tự sẽ kích hoạt hợp đồng, quản lý phiên bản, script di chuyển và sự phối hợp giữa các đội ngũ. Chi phí của việc học hỏi không còn được trả bằng suy nghĩ, mà bằng cơ sở hạ tầng và chính trị.

Và trong phần mềm, thay đổi suy nghĩ không phải là thất bại. Đó là công việc của chúng ta.

Chi phí thực sự được trả khi Doanh nghiệp học được điều mới

Đây là nơi phần mềm cấu trúc kém bộc lộ bản thân. Không phải khi nó mới được triển khai. Không phải khi các endpoint đầu tiên hoạt động. Không phải khi các biểu đồ (dashboard) chuyển màu xanh. Mà là khi chính doanh nghiệp được hiểu rõ hơn.

Bởi vì đó là điều luôn luôn xảy ra. sớm hay muộn, doanh nghiệp sẽ học được: hai khái niệm này thực ra là một, quy trình làm việc này được mô hình hóa sai, quy tắc này có ngoại lệ quan trọng, sự phân biệt này quan trọng hơn chúng ta nghĩ, hoặc quy trình này không nên tồn tại.

Điều đó là bình thường. Đó là những gì phần mềm phải đáp ứng.

Một mô hình domain liền mạch làm cho loại thay đổi đó trở nên có thể sống sót. Một hệ thống phân mảnh, phân tán, và được mô hình hóa yếu làm cho nó trở nên đắt đỏ.

Lưu ý rằng "mô hình domain liền mạch" ở đây không có nghĩa là các mẫu chiến thuật (tactical patterns) thường gắn liền với DDD—entities, repositories, aggregates và phần còn lại. Những cái đó thường thêm vào sự phức tạp ngẫu nhiên của riêng chúng. Lập mô hình thực sự đơn giản và sâu sắc hơn: đó là công việc liên tục nhằm tinh chỉnh ngôn ngữ chung (ubiquitous language) và khám phá các ranh giới khái niệm tự nhiên để hiểu biết kinh doanh mới có thể được hấp thụ với sự xâm phạm tối thiểu đối với code hiện có.

Bởi vì bây giờ sự thấu hiểu phải đi qua các API, hàng đợi, mô hình đọc, hợp đồng sự kiện, ranh giới triển khai, dòng sở hữu, quy tắc trùng lặp và các đảm bảo nhất quán một phần. Những lẽ ra là một tái cấu trúc khái niệm bây giờ trở thành một cuộc đàm phán xuyên hệ thống.

Và đó là lúc hóa đơn đến. Không phải vì vốn có là bất khả thi. Mà vì kiến trúc đã đóng băng sự hiểu lầm của ngày hôm qua vào cấu trúc của ngày hôm nay.

Đó là một trong những điều tồi tệ nhất mà phần mềm có thể làm.

Tại sao điều này thường bị bỏ qua

Phần nguy hiểm nhất là loại kiến trúc này thường trông thành công. Hệ thống chạy. Người dùng sử dụng. Công ty kiếm tiền. Vì vậy, kiến trúc được coi là đã được kiểm chứng.

Nhưng "nó chạy" là một trong những tiêu chuẩn yếu nhất trong phần mềm. Một hệ thống chạy trên môi trường sản xuất chỉ chứng minh rằng nó khả thi đủ để tồn tại. Nó không chứng minh rằng nó rẻ để thay đổi, đúng về mặt khái niệm, gắn kết về mặt cấu trúc, hoặc tốt trong việc hấp thụ sự hiểu biết mới.

Hầu hết các đội ngũ không bao giờ trải nghiệm cảm giác phần mềm khác biệt như thế nào khi:

• Các khái niệm có một nơi ở duy nhất, rõ ràng thay vì bị lan man trên các dịch vụ
• Các quy tắc được làm rõ và có thể thực thi thay vì bị phân tán trong code điều phối và kết nối
• Sự thấu hiểu kinh doanh mới dẫn đến một tái cấu trúc sạch sẽ thay vì sự phối hợp phân tán
• Hệ thống mời gọi sự thấu hiểu thay vì chống lại sự thay đổi

Nếu không có sự tương phản đó, nỗi đau của việc lập mô hình yếu bị ẩn sau sự phân tán được chuẩn hóa là "phần mềm phức tạp vốn dĩ như vậy".

Thường thì không phải vậy. Thường thì, nó chỉ là chi phí của thiết kế yếu được ẩn sau kiến trúc.

Lời kết

Phần lớn kiến trúc phân tán ngày nay không phải là kết quả của sự thấu hiểu domain. Đó là sự bồi thường cho sự rõ ràng về khái niệm chưa bao giờ được xây dựng vào mô hình. Bằng cách vươn tới sự tách biệt thay vì sự thấu hiểu sâu sắc hơn, các đội ngũ đạt được khả năng quản lý cục bộ với cái giá là sự liền mạch dài hạn và sự tiến hóa rẻ tiền.

Vấn đề là sự thiếu rõ ràng ban đầu không biến mất — nó chỉ được phân tán đi. Cuối cùng, sự nhầm lẫn tương tự khiến monolith không thể bảo trì sẽ khiến hệ thống phân tán thất bại y như thế, chỉ có điều bây giờ việc sửa chữa còn đắt đỏ và đau đớn hơn nhiều.

Đó là lý do tại sao nhiều kiến trúc "tinh vi", thực chất chỉ là những cách đối phó tinh vi.