Tìm hiểu về Kiến Trúc Phần Mềm (Software Architecture)

Lời mở đầu#

“Thế giới quả là rộng lớn và có rất nhiều việc phải làm” - Kim Woo Choong. Thế giới phát triển phần mềm cũng vậy, rất rộng lớn và không ngừng mở rộng. Nếu các bạn xác định theo ngành một cách lâu dài, chuyên nghiệp thì việc tìm hiểu về kiến trúc phần mềm là vô cùng quan trọng. Đặc biệt 2025, và những năm tới đây AI phát triển cực kỳ mạnh mẽ, những công việc thủ công lặp đi, lặp lại có thể được giải quyết nhanh chóng theo một cách nào đó.Cá nhân mình tin rằng tthời gian còn lại của những nhà phát triển(Software Engineer), kiến trúc sư(Software Architect) sẽ cần sử dụng để học hỏi, tìm cách giải quyết vấn đề về kiến trúc để giúp hệ thống chúng ta phát triển ra đáp ứng được đúng, đủ và tăng trải nghiệm người dùng về cả business lẫn performance. Đây sẽ là bài viết đầu tiên trong series Software-Architecture. Bài viết đầu tiên này mình sẽ giới thiệu, tổng hợp lại một số khái niệm, yếu tố mà mình nghĩ là hữu ích và quan trọng để có nền tảng đào sâu thêm về kiến trúc phần mềm. Không lan man nữa, Let’s jump into the content !!!

Kiến trúc phần mềm là gì?#

Có nhiều định nghĩa khác nhau về kiến trúc phần mềm, nhưng mình thích định nghĩa nó theo một cách trực quan dễ hiều nhất. Kiến trúc phần mềm là một quy trình tổng hợp bao gồm các patterns(mẫu thiết kế), principles(nguyên tắc), processes(quy trình), và quan hệ giữa các thành phần trong hệ thống để tạo nên một thiết kế tổng thể(Chưa trực quan lắm nhể @@, không sao cứ đọc tiếp đê - mưa dầm thấm lâu). PS: Cũng như codebase vậy, kiến trúc phần mềm sẽ cần được maintain, gắn với sự thay đổi về business ở một khía cạnh nào đó(tất nhiên phải có công cụ đánh giá, chứ k phải user nói gì làm đó đâu nhé). Mục tiêu tối thượng “giải quyết bài toán của người dùng”.

Sự quan trọng của kiến trúc phần mềm#

Có một sự thật là đa số những lập trình viên trong những năm đầu của sự nghiệp rất ghét phải làm việc với kiến trúc phần mềm, mà chỉ muốn nhảy vào viết code luôn cho nóng. Nhưng thông thường nếu chúng ta làm theo cách này, thường thì dự án đó sẽ có khả năng cao gặp nhiều issues về sau cần giải quyết. Thậm chí là rất khó để bảo trì và mở rộng. Thay vì chúng ta giành khoảng một đến hai tháng làm rõ yêu cầu người dùng, và cho ra một kiến trúc phù hợp, thì chúng ta sẽ phải giành rất nhiều thời gian để fix lỗi, tái cấu trúc lại kiến trúc phần mềm, hỗ trợ khách hàng ngoài giờ (điều này rất dễ làm các members trong team bị nản, mình đã từng trải qua nên rất rõ cảm giác này), và tệ hơn nữa là khách hàng mất niềm tin, doanh nghiệp mất đi sức mạnh, nếu là sản phẩm của bạn thì bạn sẽ phải là người chịu thiệt hại. Tất nhiên không ai muốn những điều trên xảy ra, vậy câu hỏi đặt ra là đâu là những yếu tố để giúp chúng ta có được một kiến trúc phần mềm phù hợp với phần mềm mà chúng ta cần xây dựng. Cùng đọc tiếp nhé !!!

Các yếu tố chính(Key areas) trong kiến trúc phần mềm#

Sự đa dạng của các chủ đề xay quanh Kiến trúc phần mềm có thể làm chúng ta bị choáng ngợp(overwheming) và cực kì khó tiếp cận, dễ nản. Vì vậy, mình sẽ chia các yếu tố ảnh hưởng đến kiến trúc phần mềm như sau:

Business analysis (Phân tích nghiệp vụ): Nghiệp vụ, bài toán chúng ta cần giải quyết là gì? Đâu là những core feature, và boundaries(giới hạn mà chúng ta sẽ đáp ứng)
Infrastructure (Cơ sở hạ tầng): Chúng ta có cần triển khai theo cloud-agnostic(sẵn sàng chuyển đổi trên tất cả các Cloud Computing Platform) không? Nếu có thì chiến lược scale là gì, và buget tối đa có thể chi trả là bao nhiêu(Đặc biệt quan trọng, mình sẽ nói chi tiết về cách mà cá nhân mình áp dụng khi đi vào từng phần nhé).
Deployment strategy: Chúng ta sẽ triển khai ứng dụng dưới dạng một đơn vị duy nhất hay dưới dạng nhiều đơn vị nhỏ(single or multiple deployment unit)?
Solution architecture: Những Patterns nào chúng ta sẽ áp dụng, sử dụng ở đâu? Cách giao tiếp giữa các thành phần trong hệ thống là gì, qua những phương thức nào?
Test strategy: Chúng ta sẽ áp dụng những chiến lược test nào cho dự án?
Release strategy: Bao lâu chúng ta sẽ phát hành một phiên bản cho khách hàng?
Teams: Chúng ta cần tổ chức, phân chia giữa các thành viên trong team như nào cho hợp lý? Các thành viên trong team có kinh nghiệm, năng lực ra sao?

Các yếu tố định hướng kiến trúc(Architecture Drivers)#

Mỗi dự án sẽ có những đặc thù khác nhau, về nghiệp vụ, mục tiêu kinh doanh, budget, và rất nhiều yếu tố khác. Vì vậy, việc tìm kiếm một kiến trúc phù hợp cho mọi dự án là điều khó có thể đạt được nếu không muốn nói là không thể. Vì vậy chúng ta không thể đưa ra quyết định kiến trúc dựa trên cảm tính. Theo kinh nghiệm của mình, có một vài yếu tố tác động đến việc ra quyết định cho một kiến trúc. Những yếu tố này được chia làm các nhóm chính:

Yêu cầu chức năng(Functional Requirements) Đây là những gì hệ thống phải làm để đáp ứng mục tiêu kinh doanh và nhu cầu của người dùng. Tuy nghe có vẻ đơn giản, nhưng trong thực tế, việc hiểu rõ và xác định đúng các yêu cầu chức năng luôn là một thách thức. Notes:
- Đừng bị sa đà vào cách làm (“how”), hãy tập trung vào cái hệ thống phải làm (“what”).
- Hãy hỏi rõ các bên liên quan: “Người dùng cuối thực sự muốn gì?”
- Hãy sử dụng Domain Storytelling & User Stories để thực hiện ở giải đoạn này, rất hiệu quả. Mình sẽ có bài viết riêng giới thiệu với các bạn về hai technique này. Dưới đây là hình ảnh minh họa một story sử dụng Domain Storytelling. Các bạn có thể tự tìm hiểu thêm nhé.

Ràng buộc kinh doanh (Business Constraints) Ràng buộc kinh doanh là những yếu tố như thời gian, ngân sách, nguồn lực hay quy định pháp luật mà bạn buộc phải tuân thủ. Những yếu tố này sẽ giới hạn phạm vi và cách bạn triển khai kiến trúc. Notes:
- Nếu có giới hạn về nguồn lực, hãy nghĩ đến việc giảm phạm vi tính năng thay vì cố gắng làm tất cả mọi thứ.
- Đừng chỉ tập trung vào kỹ thuật, vì các ràng buộc kinh doanh thường là thứ quyết định thành bại của dự án.
Ràng buộc kỹ thuật (Technical Constraints) Đây là những hạn chế về công nghệ hoặc cơ sở hạ tầng mà bạn phải tính đến khi thiết kế hệ thống. Nó thường xuất phát từ những yếu tố như nền tảng hiện có, công nghệ mà công ty đang sử dụng hoặc yêu cầu đặc thù của hệ thống. Ví dụ:
- Phải triển khai trên nền tảng nội bộ đã có sẵn.
- Codebase phải được viết bằng C# vì tất cả các hệ thống khác trong công ty đang dùng ngôn ngữ này.
Các thuộc tính chất lượng (Quality Attributes) Thuộc tính chất lượng xác định các đặc điểm phi chức năng của hệ thống như hiệu suất, khả năng mở rộng, tính bảo trì… Đây là những yếu tố ảnh hưởng trực tiếp đến trải nghiệm người dùng và tính bền vững của hệ thống. Notes:
- Đừng cố tối ưu mọi thứ – hãy tập trung vào những thuộc tính chất lượng mà dự án của bạn thực sự cần. Ví dụ:
- Hệ thống phải đảm bảo uptime 99% (tính sẵn sàng).
- Báo cáo phải được tạo trong vòng không quá 7 giây vào giờ cao điểm (hiệu suất).

Làm sao để ứng dụng trong thực tế#

Lý thuyết thì là như vậy, nhưng làm sao để ứng dụng trong thực tế. Sau đây mình xin nêu lên năm ý chính mà mình nghĩ các bạn có thể đọc và lưu ý khi thực hiện thiết kế kiến trúc. Những bài tiếp theo trong series này, chúng ta cũng sẽ cùng thực hành build một hệ thống từ đầu, và mình sẽ đi qua chi tiết qua từng bài. Cùng xem chúng ta sẽ build hệ thống gì ở bài tiếp theo nhé. Nhưng trước hết hãy nắm được năm gạch đầu dòng này đã !!!

Bắt đầu đơn giản: Đừng thiết kế kiến trúc phức tạp hơn những gì bạn cần.
Phản ứng với vấn đề hiện tại: Tập trung vào những vấn đề bạn có ngay bây giờ (hoặc sẽ gặp sớm), thay vì lo xa về tương lai.
Giữ mọi thứ linh hoạt: Dù thiết kế đơn giản, hãy để lại không gian để thay đổi và mở rộng.
Đừng chạy theo xu hướng: Đừng áp dụng công nghệ hoặc mô hình chỉ vì chúng đang “hot”.
Hiểu trade-offs: Mỗi quyết định đều có cái được và cái mất, hãy cân nhắc chúng một cách kỹ lưỡng.

Kết luận#

Kiến trúc phần mềm không chỉ là về kỹ thuật, mà còn là sự kết hợp giữa kinh doanh, kỹ thuật và trải nghiệm thực tế. Các yếu tố định hướng kiến trúc (architectural drivers) không chỉ giúp bạn đưa ra quyết định tốt hơn mà còn giúp bạn điều chỉnh hệ thống linh hoạt khi yêu cầu thay đổi. PS: Luôn đặt câu hỏi: “Điều gì là quan trọng nhất với dự án này?” Và thiết kế mọi thứ xoay quanh câu trả lời đó.