LỜI NÓI ĐẦU  
Khi chúng ta nói về kiến trúc, ta thực sự đang nói về điều gì?  
Như bất cứ phép ẩn dụ nào, dùng kiến trúc để mô tả phần mềm vừa có thể làm rõ, vừa có thể che giấu nhiều điều. Nó có thể hứa hẹn nhiều hơn khả năng thực tế, cũng có thể mang lại vượt quá mong đợi.  
Điểm thu hút dễ thấy nhất của kiến trúc là cấu trúc – thứ chi phối mọi mô hình và cuộc thảo luận trong phát triển phần mềm: thành phần, lớp, hàm, mô-đun, lớp, dịch vụ, ở bất kỳ quy mô micro hay macro nào. Nhưng cấu trúc tổng thể của rất nhiều hệ thống phần mềm thường khiến ta khó tin hoặc khó hiểu – từ những kế hoạch doanh nghiệp kiểu Liên Xô sục sạo di sản, các “tháp Jenga” khó tin mọc lên chạm đến đám mây, đến những lớp khảo cổ chôn vùi trong đống “bùn” legacy khổng lồ. Cấu trúc phần mềm không tuân theo trực giác của ta như cấu trúc công trình xây dựng.  
Công trình xây dựng có cấu trúc vật lý rõ ràng, dù làm từ đá, bê tông hay vật liệu gì đi nữa; dù cong vòm cao hay trải rộng; dù lớn hay nhỏ; dù tráng lệ hay bình thường. Cấu trúc ấy buộc phải tôn trọng quy luật vật lý, trọng lực và tính chất vật liệu. Ngược lại — trừ khi xét theo ý nghĩa nghiêm trọng — phần mềm gần như không quan tâm đến trọng lực. Thế phần mềm được cấu thành từ gì? Không như công trình xây dựng làm từ gạch, bê tông, gỗ, thép, kính, phần mềm chỉ làm từ phần mềm. Những cấu trúc phần mềm lớn tạo nên từ các thành phần nhỏ hơn, và thành phần ấy lại chia nhỏ thêm, cứ thế kéo dài vô tận. Mã nhắc mã — còn gọi là “coding turtles all the way down.”  
Nói đến kiến trúc phần mềm, bản chất đệ quy và fractal được khắc hoạ trong mã nguồn. Mọi thứ đều là chi tiết. Mức độ chi tiết lồng ghép cũng làm nên kiến trúc công trình, nhưng khái niệm “quy mô vật lý” không áp dụng được cho phần mềm. Phần mềm có cấu trúc — nhiều kiểu cấu trúc khác nhau — với sự đa dạng vượt xa mọi cấu trúc vật lý trong xây dựng. Bạn thậm chí có thể lập luận rằng phần mềm đòi hỏi nhiều hoạt động thiết kế và sự tập trung hơn cả kiến trúc xây dựng; theo nghĩa đó, kiến trúc phần mềm thậm chí còn “kiến trúc” hơn cả kiến trúc xây dựng!  
Nhưng con người luôn quen nhận biết quy mô vật lý trong thế giới. Những hộp trong sơ đồ PowerPoint hấp dẫn và rõ ràng, nhưng chúng không thể thay thế kiến trúc thực sự của hệ thống phần mềm. Chúng chỉ thể hiện một góc nhìn về kiến trúc, và nếu nhầm lẫn các hộp ấy là bản tổng thể thì ta sẽ bỏ lỡ kiến trúc đích thật. Kiến trúc phần mềm không có hình tướng cố định. Một cách biểu diễn cụ thể là một lựa chọn, không phải điều hiển nhiên. Lựa chọn đó dựa trên loạt quyết định khác nữa: chọn gì vào, bỏ gì ra, nhấn mạnh điều gì bằng hình dạng hay màu sắc, và giảm bớt hay lược bỏ sao cho đồng nhất hay bỏ qua. Không có góc nhìn nào tự nhiên, bẩm sinh hơn góc nhìn khác.  
Dù nói vật lý và quy mô vật lý không hợp lý trong kiến trúc phần mềm, ta vẫn cần quan tâm các giới hạn vật lý rõ ràng. Tốc độ xử lý và băng thông mạng có thể tỏ ra khắt khe về hiệu năng hệ thống. Bộ nhớ và lưu trữ cũng giới hạn tham vọng của bất cứ cơ sở mã nào. Phần mềm có thể là sản phẩm của những giấc mơ, nhưng nó hoạt động trong thế giới vật chất.  
“Đây là nỗi kinh hoàng trong tình yêu, thưa quý bà, rằng ý chí là vô hạn, nhưng việc thực hiện bị hạn chế; rằng ham muốn thì vô bờ bến, nhưng hành động lại phải làm nô lệ cho giới hạn.”  
—William Shakespeare  
Thế giới vật lý là nơi ta, công ty và nền kinh tế tồn tại. Nó đưa ra chuẩn đo kích thước để hiểu kiến trúc phần mềm, nơi ta có thể luận bàn về các lực và đại lượng ít vật lý hơn.  
“Kiến trúc chính là những quyết định thiết kế quan trọng định hình hệ thống, trong đó sự quan trọng được đo bằng chi phí thay đổi.”  
—Grady Booch  
Thời gian, tiền bạc và công sức giúp ta phân biệt cái lớn, cái nhỏ; phân biệt kiến trúc với phần còn lại. Tiêu chuẩn này cũng giúp xác định thế nào là kiến trúc tốt: không chỉ đáp ứng nhu cầu người dùng, nhà phát triển và chủ sở hữu ở một thời điểm, mà còn tiếp tục đáp ứng qua thời gian.  
“Nếu bạn nghĩ kiến trúc tốt thì đắt, hãy thử trải qua kiến trúc tồi.”  
—Brian Foote và Joseph Yoder  
Những thay đổi điển hình trong phát triển hệ thống không nên là thay đổi đắt đỏ, khó khăn, không nên đòi hỏi dự án quản lý riêng biệt mà phải dễ dàng tích hợp vào công việc hàng ngày và hàng tuần.  
Điều đó dẫn ta đến vấn đề lớn liên quan vật lý: du hành thời gian. Làm sao ta biết được những thay đổi phổ biến đó để xây dựng các quyết định quan trọng ngay từ đầu? Làm sao hạn chế nỗ lực và chi phí phát triển tương lai mà không có quả cầu pha lê hay máy thời gian?  
“Kiến trúc là các quyết định bạn mong ước làm đúng từ đầu dự án, dù sự thật không chắc bạn sẽ đúng hơn các quyết định khác.”  
—Ralph Johnson  
Hiểu quá khứ đã khó; nắm hiện tại còn trơn trượt hơn; dự đoán tương lai càng không hề đơn giản.  
Đây là lúc ta đứng trước nhiều ngã rẽ.  
Ngã rẽ đen tối nhất là cho rằng kiến trúc mạnh mẽ, bền vững chỉ đến từ quyền uy và sự cứng nhắc. Nếu thay đổi quá đắt đỏ, ta loại bỏ thay đổi — kiềm chế nguyên nhân hoặc đẩy nó xuống con đường quan liêu. Quyền lực kiến trúc sư trở nên toàn quyền, áp đặt, biến kiến trúc thành địa ngục cho các nhà phát triển và nguồn cơn thất vọng kéo dài.  
Ngã rẽ khác ngập tràn mùi dự đoán mơ hồ, đầy sự phỏng đoán cứng nhắc, nhiều tham số, đống mã chết, và độ phức tạp vô tình vượt quá sức chi trả bảo trì.  
Con đường ta quan tâm nhất là con đường sạch sẽ nhất. Nó thừa nhận phần mềm mềm dẻo là thuộc tính hạng nhất cần được bảo tồn. Nó thừa nhận ta vận hành trong điều kiện thiếu thông tin đầy đủ, đồng thời hiểu rằng con người ta làm việc hiệu quả dưới trạng thái ấy — đó là lợi thế, không phải điểm yếu. Ta tạo ra và khám phá, đặt câu hỏi và thử nghiệm. Kiến trúc tốt là hành trình khám phá thường trực, không phải điểm dừng cố định; là quá trình điều tra liên tục, không phải di sản bất biến.  
“Kiến trúc là giả thuyết cần được chứng minh bằng việc triển khai và đo lường.”  
—Tom Gilb  
Đi trên con đường này đòi hỏi cẩn trọng, quan sát, suy nghĩ, thực hành và tuân thủ nguyên tắc. Ban đầu có thể chậm, nhưng quan trọng là cách bạn bước đi.  
“Cách duy nhất để đi nhanh là đi cho đúng.”  
—Robert C. Martin  
Hãy tận hưởng hành trình.  
—Kevlin Henney  
Tháng 5 năm 2017