Tác giả: Nghê Tâm Minh.

ADR là một phương pháp ghi lại các quyết định kiến ​​trúc rất tiết kiệm chi phí để giới thiệu và thực hành nó cho nhóm nhưng nó có thể mang lại lợi ích to lớn cho nhóm! .

1 Vấn đề mà nhóm R&D gặp phải

Dù trong ngành CNTT truyền thống hay ngành Internet, các nhóm R&D ít nhiều sẽ phải đối mặt với những vấn đề hoặc thách thức sau ở cấp độ ra quyết định về kiến ​​trúc:

•Khi các thành viên mới gia nhập nhóm, họ có thể mù quáng tuân theo các quyết định kiến ​​trúc hiện có của hệ thống, chỉ biết đó là gì mà không biết tại sao; hoặc họ có thể thách thức hoặc vi phạm các ràng buộc, tiếp tục thách thức các quyết định hiện tại, “đặt câu hỏi” về tính hợp lý, đúng đắn của các quyết định và có tinh thần trách nhiệm. Người dân cần được giải thích, đồng bộ và thúc đẩy liên tục để đạt được sự đồng thuận.

•Các vấn đề tiềm ẩn với các quyết định về kiến ​​trúc trở nên rõ ràng theo thời gian, nhưng nếu phân tích đầy đủ được thực hiện vào thời điểm đưa ra quyết định thì những vấn đề này có thể được phát hiện và tránh được trước.

•Các quyết định về kiến ​​trúc hệ thống hiện tại đang phát triển như thế nào? Động lực đằng sau quyết định hiện tại là gì? Có thể không ai trong nhóm có thể trả lời chính xác.

•Các kịch bản ra quyết định kiến ​​trúc tương tự tái diễn trong hệ thống do các yếu tố như quên lý do đưa ra quyết định hoặc thay đổi thành viên trong nhóm nên vẫn cần thời gian để phân tích, thiết kế và thúc đẩy các bên liên quan đạt được sự đồng thuận.

•Chỉ một số ít người trong nhóm chịu trách nhiệm thiết kế kiến ​​trúc, các thành viên khác trong nhóm không có cơ hội tham gia. Tuy nhiên, trên thực tế, các thành viên trong nhóm có nhu cầu tương ứng và ít nhất có thể hiểu được quy trình ra quyết định của một phím nhất định. thiết kế kiến ​​trúc.

•Ngay cả khi dự án được tiếp quản trong nhóm, bạn có thể nhanh chóng có được các quyết định kiến ​​trúc quan trọng của hệ thống và lý do của chúng không? Bạn có thể tìm kiếm manh mối về các quyết định kiến ​​trúc trong cơ sở mã, nhưng rất khó để hiểu được động cơ đằng sau các quyết định kiến ​​trúc và sự phát triển của các quyết định đó.

Dựa trên những câu hỏi trên, chúng tôi mong muốn:

•Ghi lại các quyết định về kiến ​​trúc của hệ thống theo cách tối thiểu nhưng vẫn hiệu quả.

•Khả năng xác định sự phát triển của các quyết định hệ thống quan trọng.

•Các quyết định về kiến ​​trúc và phương pháp thiết kế tốt nhất có thể được đồng bộ hóa một cách hiệu quả giữa các nhóm.

•Các thành viên trong nhóm có cơ hội tham gia vào quá trình ra quyết định thiết kế kiến ​​trúc.

Vấn đề đầu tiên khi ghi lại các quyết định kiến ​​trúc là: Tài liệu lỗi thời! ! .

Thật vậy, vấn đề hết hạn là một vấn đề không thể tránh khỏi mà tài liệu phải đối mặt. Cho dù sử dụng cơ chế nào, chẳng hạn như quy trình mạnh, cập nhật tự động, v.v., luôn có nguy cơ hết hạn. Vậy tại sao lại chọn ghi lại các quyết định kiến ​​trúc?

• Hiệu quả về mặt chi phí: Lợi ích của việc ghi lại các quyết định kiến ​​trúc vượt xa chi phí bảo trì lỗi thời.

• Nhẹ: Giữ cho ADR ngắn gọn và nhẹ nhàng. Kích thước của tài liệu càng nhỏ thì càng dễ đồng bộ với thực tế.

2 Phân tích ADR

Bản ghi Quyết định Kiến trúc, viết tắt là ADR, là viết tắt của Bản ghi Quyết định Kiến trúc. Cách thực hành này lần đầu tiên được khởi xướng bởi Michael Nygard và là một trong những cách hiệu quả nhất để ghi lại các quyết định kiến ​​trúc. Nói một cách đơn giản, ADR là một bản ghi tài liệu về các quyết định kiến ​​trúc. Mục đích của nó là ghi lại các quyết định kiến ​​trúc, lý do và quy trình ra quyết định của hệ thống dưới dạng tài liệu.

Bằng cách ghi lại các quyết định về kiến ​​trúc hệ thống một cách hiệu quả, các nhóm có thể hưởng lợi từ các cấp độ sau:

• Hướng dẫn các thành viên mới nhanh chóng làm quen với hệ thống. Các thành viên mới trong nhóm có thể nhanh chóng nắm bắt được các quyết định về kiến ​​trúc lịch sử của hệ thống và hiểu được bối cảnh, quy trình ra quyết định cũng như các tác động liên quan đằng sau các quyết định đó.

•Bàn giao dự án, ghi chép và tích lũy các quyết định hiện có. Môi trường linh hoạt nhấn mạnh khả năng học hỏi kiến ​​thức nhanh chóng của nhóm. Dựa trên ADR, nhóm có thể nhanh chóng làm quen với quá trình phát triển kiến ​​trúc của hệ thống hiện có.

•Nhận thức thống nhất Bằng cách thúc đẩy triển khai ADR, các thành viên trong nhóm có thể dễ dàng đạt được sự đồng thuận hơn về các phương pháp thiết kế tốt nhất, hơn nữa tránh được việc "phát minh lại bánh xe" trong quá trình xây dựng tiếp theo và cải thiện việc tái sử dụng kiến ​​thức thiết kế giữa các nhóm.

Cấu trúc cơ bản của ADR được đề xuất bao gồm năm phần: tiêu đề, trạng thái, bối cảnh, quyết định và tác động. Nói chung, nên bổ sung thêm hai chương có giá trị, tính nhất quán và nhận xét, làm phần bổ sung.

Cần lưu ý rằng nhóm có thể thêm các chương khác nếu cần để nâng cao khả năng hoạt động của ADR, chẳng hạn như thêm các chương giải pháp tùy chọn để mô tả chi tiết các giải pháp tùy chọn.

Tiêu đề [bắt buộc].

Phần "tiêu đề" của ADR chủ yếu bao gồm hai phần, một phần là số thứ tự và phần còn lại là mô tả ngắn gọn về quyết định kiến ​​trúc. Phần mô tả của tiêu đề cần đảm bảo rằng nó mô tả chính xác quyết định về mặt kiến ​​trúc, rõ ràng và rõ ràng, đồng thời giữ cho nó ngắn gọn và súc tích.

Ví dụ: ADR 01. Cơ chế nhắn tin không đồng bộ được sử dụng giữa dịch vụ đặt hàng và dịch vụ thực hiện.

Trạng thái [bắt buộc].

"Trạng thái" của ADR được giới hạn ở một trong ba trạng thái: đang chờ xem xét, phê duyệt hoặc thay thế.

•Đang chờ xem xét: Quyết định phải được người ra quyết định cấp cao hoặc ARB xem xét.

• Đã xem xét: Quyết định về kiến ​​trúc đã được xem xét và sẵn sàng để thực hiện.

•Đã thay thế: Quyết định kiến ​​trúc đã thay đổi và được thay thế bằng một ADR khác. Trạng thái này cho biết rằng ADR trước đó phải được phê duyệt. Các ADR ở trạng thái đề xuất chưa được phê duyệt sẽ không được phép chuyển sang trạng thái này. ADR ở trạng thái được đề xuất chỉ có thể được sửa đổi cho đến khi được phê duyệt. Trạng thái thay thế cung cấp cơ chế theo dõi hiệu quả cho các quyết định kiến ​​trúc, có thể giúp nhóm xác định quá trình phát triển của các quyết định kiến ​​trúc.

Bối cảnh [bắt buộc].

Thúc đẩy kiến ​​trúc sư mô tả bối cảnh hoặc vấn đề cụ thể cho quyết định kiến ​​trúc này và phát biểu chính xác các phương án thay thế có thể. Nền tảng ra quyết định cũng là sự mô tả kiến ​​trúc hệ thống ở một mức độ nhất định.

Lưu ý: Không nên tiến hành phân tích chi tiết và giải thích các lựa chọn thay thế trong chương này. Nếu thực sự cần thiết phải xây dựng chi tiết, nên bổ sung thêm các chương để giải thích.

Gói tùy chọn [tùy chọn].

Cung cấp mô tả chi tiết về các lựa chọn thay thế có sẵn và so sánh ưu điểm và nhược điểm của các lựa chọn khác nhau.

Quyết định [bắt buộc].

Phần này bao gồm các quyết định kiến ​​trúc cụ thể và cơ sở ra quyết định tương ứng. Về nguyên tắc, các quyết định kiến ​​trúc cụ thể phải được thể hiện dưới dạng mô tả khẳng định và mệnh lệnh, không được có cách diễn đạt chủ quan, tiêu cực, mơ hồ hoặc có khả năng mơ hồ. Lưu ý: Tập trung vào Tại sao hơn là Thế nào. Hiểu lý do cho các quyết định về kiến ​​trúc quan trọng hơn việc hiểu cách thực hiện chúng.

Tác động [bắt buộc].

Phần này mô tả tác động tổng thể của quyết định kiến ​​trúc này. Mọi quyết định sẽ có ít nhiều tác động lên hệ thống hiện có, bao gồm cả tác động tốt và xấu. Chương này khuyến khích kiến ​​trúc sư nghĩ về liệu những tác động này có lớn hơn lợi ích của các quyết định kiến ​​trúc hay không.

Tính nhất quán [tùy chọn].

Phần này không phải là phần tử ADR tiêu chuẩn, nhưng nó có giá trị ngang nhau là khuyến khích kiến ​​trúc sư suy nghĩ về cách đo lường và chi phối các quyết định kiến ​​trúc mà họ đưa ra từ góc độ nhất quán kiến ​​trúc. Kiến trúc sư phải xác định liệu đảm bảo tính nhất quán cho quyết định kiến ​​trúc này sẽ đạt được bằng tay hay thông qua các phương tiện tự động. Nếu có thể thực hiện được thông qua tự động hóa thì kế hoạch thực hiện tự động hóa cần được nêu rõ trong phần này.

Lưu ý[Bắt buộc]

Phần nhận xét không phải là cấu trúc ADR tiêu chuẩn, nhưng rất nên thêm phần này. Phần nhận xét chủ yếu chứa nhiều siêu dữ liệu khác nhau của ADR, chẳng hạn như:

Tác giả gốc, ngày đánh giá, người đánh giá, ngày thay thế, ngày sửa đổi lần cuối, người sửa đổi và nội dung sửa đổi lần cuối.

Lưu ý: Một số nhóm cho rằng thông tin siêu dữ liệu trong phần ghi chú không có nhiều giá trị, đặc biệt khi nhóm lưu trữ ADR cùng với mã trong thư viện cấu hình (phương pháp lưu trữ này không được khuyến khích). Nhưng trên thực tế, việc sử dụng siêu thông tin như một phần của ADR có giá trị và thuận lợi hơn việc dựa vào các thư viện cấu hình.

3 Tổ chức và lưu trữ ADR

Các nhóm khác nhau có thể linh hoạt lựa chọn nơi lưu trữ tài liệu ADR, chẳng hạn như máy chủ FTP, WIKI hoặc thư viện cấu hình mã của cùng một dự án, tùy theo tình huống. Nguyên tắc: Các bên liên quan có thể dễ dàng thu được ADR.

Phương pháp 1: Dựa trên kho lưu trữ cấu hình giống như Git.

lợi thế:

•Các quyết định kiến ​​trúc gần với mã, giúp các nhà phát triển dễ dàng tiếp cận chúng.

•Dễ dàng triển khai quản lý thay đổi ADR thông qua khả năng quản lý phiên bản của thư viện cấu hình.

thiếu sót:

Các bên liên quan của ADR không chỉ là nhân viên R&D mà còn là các bên liên quan của dự án với các vai trò khác như quản lý kỹ thuật, quản lý sản phẩm và nhân viên kinh doanh. Việc lưu trữ dựa trên thư viện cấu hình quá kỹ thuật rõ ràng là không thân thiện với các vai trò khác ngoài R&D. Đồng thời, quyền lưu trữ cần được cấp cho những người không thuộc bộ phận R&D và bảo mật mã cũng là một yếu tố cần được xem xét. Ngoài ra, việc lưu trữ dựa trên thư viện cấu hình không thuận tiện cho việc lưu trữ các quyết định kiến ​​trúc chung trong các ứng dụng khác nhau của cùng một hệ thống và các quyết định kiến ​​trúc tích hợp giữa các ứng dụng.

Cách 2: Trong hệ thống cộng tác chỉnh sửa và chia sẻ trực tuyến tương tự như WIKI.

Ưu điểm: Cộng tác trực tuyến thân thiện với các bên liên quan tạo điều kiện thuận lợi cho các quyết định kiến ​​trúc ứng dụng chéo.

Nhược điểm: Không thân thiện với nhà phát triển, xa thư viện phát triển.

Dựa trên việc lưu trữ các quyết định về kiến ​​trúc ứng dụng chéo, nhóm đã chọn lưu trữ ADR trong nền tảng tài liệu cộng tác trực tuyến và sắp xếp nó thông qua cấu trúc thư mục hợp lý, tham khảo hình thức tổ chức sau:

4 ADR được tích hợp vào quy trình R&D

Nếu ADR được triển khai, nó cần được tích hợp vào quá trình nghiên cứu và phát triển hiện có. Các hoạt động quy trình được ADR bao trùm chủ yếu là:

Phát triển ADR

•Tên hoạt động: Phát triển Hồ sơ Quyết định Kiến trúc (ADR).

•Điều kiện tiên quyết: Không.

•Trách nhiệm của các bên liên quan: Người lãnh đạo hệ thống con chịu trách nhiệm xây dựng các ADR trong phạm vi của hệ thống con và kiến ​​trúc sư hệ thống chịu trách nhiệm ra quyết định về kiến ​​trúc xuyên hệ thống.

•Đầu vào hoạt động: Đầu ra hoạt động PRD: "Bản ghi quyết định kiến ​​trúc".

•Hình thức thực hiện: offline, hoặc động não không chính thức.

•Thời gian thực hiện: Là hoạt động phụ của thiết kế hệ thống và được thực hiện trong giai đoạn thiết kế hệ thống.

Xem lại ADR.

•Tên hoạt động: Xem xét ADR.

•Mục đích của hoạt động: Xem xét tính đầy đủ và chính xác của ADR để đảm bảo tính hợp lý của các quyết định kiến ​​trúc.

•Điều kiện tiên quyết: Việc xây dựng ADR đã được hoàn thành.

•Trách nhiệm của các bên liên quan: Người được chỉ định ADR bắt đầu đánh giá, kiến ​​trúc sư hệ thống và bộ phận R&D cốt lõi tham gia vào các hoạt động đánh giá.

•Đầu vào hoạt động: ADR.

•Đầu ra hoạt động: Hồ sơ rà soát ADR (cập nhật thông tin rà soát trên tài liệu ADR).

•Hình thức thực hiện: họp tổng kết chính thức hoặc không chính thức.

•Thời gian thực hiện: Trong quá trình rà soát nội bộ phương án kỹ thuật, các ADR liên quan đến phương án sẽ được xem xét.

5 câu hỏi thường gặp trong thực hành ADR

Câu hỏi 1: “Tốn thời gian” cho việc viết ADR cao và có kéo dài chu trình thiết kế giải pháp kỹ thuật không?

Trả lời: Không! .

Câu hỏi này chủ yếu có thể xuất phát từ những lý do sau:

•Viết tài liệu = tốn thời gian? Hầu hết các nhà phát triển không thích tài liệu và không có thói quen viết tài liệu.

•Sự hiểu biết về mẫu ADR chưa đủ sâu và chưa đủ chính xác, và tôi không biết phải bắt đầu như thế nào trong quá trình viết.

•Thiếu thói quen phân tích cần thiết cho việc ra quyết định, thiếu sự so sánh và phân tích cần thiết cho các quyết định kiến ​​trúc, thiếu cơ sở cần thiết để viết ADR, buộc phải tìm kiếm thêm thông tin nên viết “rất chậm”.

Nhưng trên thực tế, nếu bạn có thói quen phân tích ra quyết định với tư cách là người ra quyết định về kiến ​​trúc, đặc biệt là khi thiết kế các giải pháp kỹ thuật và đã tiến hành phân tích ra quyết định đầy đủ thì việc viết một tài liệu ADR dài 1-2 trang sẽ không mất nhiều hơn một giờ, thậm chí nửa giờ. Ngay cả khi việc phát triển và xem xét các ADR chỉ ảnh hưởng đến một phần nhỏ thời gian thiết kế thì giá trị của việc phân tích và xem xét đầy đủ các quyết định quan trọng vẫn vượt xa chi phí làm lại bổ sung.

Câu hỏi 2: Có cần thiết phải ghi ADR cho hệ thống cũ không?

Trả lời: Không! .

Giá trị là một trong những yếu tố quyết định có nên ghi ADR hay không. Điều quan trọng là tránh việc ADR chỉ ghi lại các quyết định kiến ​​trúc hiện tại. Đối với các hệ thống cũ, việc ghi lại các quyết định kiến ​​trúc quan trọng vẫn có giá trị lớn trước khi nhóm quên chúng.

Câu hỏi 3: Cơ chế tài liệu của ADR có xung đột với Agile không?

Trả lời: Không! .

Tuyên ngôn Agile tuyên bố: Phần mềm hoạt động tốt hơn tài liệu toàn diện. Nó nhấn mạnh rằng mặt bên trái có giá trị hơn nhưng không phủ nhận giá trị của mặt bên phải.

Do đó, tài liệu không nhất thiết xung đột với các khái niệm linh hoạt. Bằng cách sử dụng cơ chế tài liệu nhẹ để ghi lại những thứ có giá trị cốt lõi, chúng tôi đảm bảo rằng cơ chế tài liệu không trở thành gánh nặng cho nhóm và phù hợp với văn hóa linh hoạt.

Câu hỏi 4: Quá trình xem xét ADR có nặng nề quá không?

Trả lời: Có thể, nhưng cần thiết! .

Rà soát ADR là một trong những hoạt động quan trọng nhằm giới thiệu cơ chế ADR và ​​không thể bỏ qua! Thông qua hoạt động rà soát với sự tham gia của nhiều bên liên quan, có thể tạo ra nhiều giá trị quan trọng của ADR. Thông qua hoạt động đánh giá chính thức hoặc không chính thức này:

•Nâng cao tính hợp lý và đúng đắn của các quyết định kiến ​​trúc.

•Cải thiện bầu không khí kỹ thuật của đội.

•Nâng cao khả năng tư duy kỹ thuật, trình độ kỹ thuật và ý thức tham gia vào việc ra quyết định kiến ​​trúc của các thành viên trong nhóm, đồng thời đạt được sự đồng bộ hóa hiệu quả các quyết định kiến ​​trúc giữa các thành viên trong nhóm...

Vì vậy, hoạt động xem xét ADR là cần thiết. Từ góc độ hiệu quả, nhóm có thể tối ưu hóa quá trình xem xét.

Câu 5: Có nhiều mẫu ADR, nhóm nên chọn như thế nào?

Trả lời: Không có tiêu chuẩn, chỉ có tiêu chuẩn phù hợp nhất! .

Không có mẫu thống nhất cho ADR. Hãy chọn mẫu phù hợp với nhóm của bạn.

Giữ các mẫu nhẹ và không cố gắng bao gồm tất cả các tình huống, nếu không ADR sẽ trở thành gánh nặng cho các thành viên trong nhóm.

Quan trọng hơn, ý nghĩa của mẫu ADR và ​​​​các thành phần mẫu phải được các thành viên trong nhóm thống nhất.

Câu 6: Khi nào cần viết ADR? Không có điều kiện định lượng nên khó thực hiện?

Trả lời: Không! .

Về nguyên tắc: các quyết định kiến ​​trúc có tác động đáng kể đến hệ thống cần có ADR.

Cách xác định “tác động đáng kể” Không có chỉ số định lượng, nhưng nếu tồn tại các tình huống sau thì đó có thể là tín hiệu cho thấy cần phải viết ADR:

•Ảnh hưởng trực tiếp đến các thuộc tính kiến ​​trúc có mức độ ưu tiên cao.

•Sửa đổi các giao diện bên ngoài: Việc sửa đổi các giao diện được cung cấp bên ngoài thường yêu cầu phân tích tác động đầy đủ.

•Thêm hoặc loại bỏ các phần phụ thuộc: Việc thêm và loại bỏ các phần phụ thuộc thường đánh dấu việc đưa vào và loại bỏ các khả năng của thành phần.

•Thay đổi cấu trúc chung của hệ thống: Cấu trúc kỹ thuật là một trong những chiều quan trọng của kiến ​​trúc ứng dụng.

•Bắt buộc nhân viên R&D thay đổi phương pháp phát triển và chấp nhận nợ kỹ thuật chiến lược: Nợ kỹ thuật có tác động lớn hơn đến việc tái cấu trúc thường có tác động lớn hơn đến hệ thống hiện tại.

Các tình huống trên chỉ là một số tín hiệu cho thấy bạn có thể cần phải viết ADR nhưng chúng không phải là các thỏa thuận bắt buộc.

Hướng dẫn thực tế cơ bản về việc bạn có cần viết ADR hay không là: tình huống cụ thể, phân tích cụ thể.

6 hiểu lầm thường gặp khi viết ADR

Mặc dù cấu trúc của ADR rất đơn giản nhưng nhóm rất dễ đi chệch khỏi nội dung của từng chương khi bắt đầu quá trình thực hành. Các vấn đề thường gặp khi viết tài liệu ADR như sau:

phần [Bối cảnh].

Phản ví dụ điển hình:

Các lý do đưa ra quyết định không được nêu trực tiếp: cách chính xác là giải thích rõ ràng bối cảnh hoặc động cơ đưa ra quyết định về kiến ​​trúc này và giải thích rõ ràng các phương án TẠI SAO một cách chi tiết: Trong giai đoạn đầu thực hành ADR, nhóm thường đưa ra những lỗi sai ở dạng " Phần "Nền" cung cấp phần thảo luận chi tiết và dài dòng về chương trình.

[Quyết định] phần.

Phản ví dụ điển hình:

Thiếu giải thích về cơ sở ra quyết định: Cơ sở ra quyết định quá đơn giản và không đầy đủ, không thể dùng làm căn cứ để lựa chọn quyết định hiện tại. Cách diễn đạt kết quả ra quyết định không đủ rõ ràng và mơ hồ.

phần [Tùy chọn tùy chọn].

Phản ví dụ điển hình: Góc phân tích rõ ràng là thiên vị và chưa đủ khách quan.

[Tính nhất quán] một phần.

Mục đích của chương này là nhắc nhở kiến ​​trúc sư nghĩ sâu về cách đảm bảo rằng các quyết định được tổ tuân thủ, đặc biệt xem xét liệu điều này có thể được thực hiện thông qua tự động hóa hay không. Các từ phản ví dụ điển hình là: triển khai hệ thống, phát triển và triển khai...

Nếu việc kiểm tra không thể được thực hiện theo cách tự động thì việc đánh giá thiết kế, đánh giá mã ngang hàng hoặc đánh giá mã chuyên gia có thể là những cách khả thi. Nếu có thể thực hiện theo cách tự động, hãy giải thích cách tự động xác minh ràng buộc. Ví dụ: nếu cơ sở kỹ thuật thực hiện kiểm tra đơn vị thông qua Archunit, thì nó có thể biểu thị mã quy tắc dựa trên Archunit.

7 Kết luận

ADR không chỉ là một tài liệu, các nhóm sẽ đạt được những lợi ích sau:

•Việc lưu giữ kiến ​​thức quan trọng về việc ra quyết định của hệ thống giúp các thành viên mới trong nhóm hòa nhập nhanh chóng và hiểu được điều gì đang xảy ra và tại sao.

•Cải thiện bầu không khí kỹ thuật của nhóm, nâng cao tư duy và năng lực kỹ thuật của nhóm, đồng thời đồng bộ hóa các phương pháp hay nhất.

•Nâng cao tính hợp lý và đúng đắn của các quyết định kiến ​​trúc.

•Khả năng quản lý nợ kỹ thuật.

•Cơ chế giao tiếp hiệu quả hơn cho các quyết định về kiến ​​trúc.

•Giảm các cuộc thảo luận và phân tích ra quyết định lặp đi lặp lại.

• Tính nhất quán của quyết định kiến ​​trúc thúc đẩy việc kiểm tra tự động các ràng buộc về kiến ​​trúc hệ thống.

Hãy bắt đầu hành trình ADR của nhóm! .

Cuối cùng, bài viết về cơ chế ghi quyết định kiến ​​trúc hạng nhẹ kết thúc tại đây. Nếu bạn muốn biết thêm về cơ chế ghi quyết định kiến ​​trúc hạng nhẹ, vui lòng tìm kiếm bài viết CFSDN hoặc tiếp tục duyệt các bài viết liên quan. Tôi hy vọng tất cả các bạn sẽ ủng hộ blog của tôi trong tương lai! .