Nguyên tắc chủ chốt

Kiến trúc phần mềm được mô tả như là tổ chức của một hệ thống, trong đó hệ thống đại diện cho một tập hợp các thành phần hoàn thành các chức năng đã xác định.

Phong cách kiến trúc

Các architectural style, còn được gọi là architectural pattern, là một tập hợp các nguyên tắc định hình một ứng dụng. Nó xác định một khuôn khổ trừu tượng cho một họ hệ thống về mô hình tổ chức cấu trúc.

Phong cách kiến trúc có trách nhiệm -

Cung cấp từ vựng về các thành phần và trình kết nối với các quy tắc về cách chúng có thể được kết hợp.
Cải thiện phân vùng và cho phép tái sử dụng thiết kế bằng cách đưa ra giải pháp cho các vấn đề thường xuyên xảy ra.
Mô tả một cách cụ thể để cấu hình một tập hợp các thành phần (một mô-đun có giao diện được xác định rõ, có thể tái sử dụng và có thể thay thế) và các đầu nối (liên kết giao tiếp giữa các mô-đun).

Phần mềm được xây dựng cho các hệ thống dựa trên máy tính thể hiện một trong nhiều phong cách kiến trúc. Mỗi kiểu mô tả một danh mục hệ thống bao gồm:

Một tập hợp các loại thành phần thực hiện một chức năng yêu cầu của hệ thống.
Một tập hợp các trình kết nối (lệnh gọi chương trình con, lệnh gọi thủ tục từ xa, luồng dữ liệu và ổ cắm) cho phép giao tiếp, phối hợp và hợp tác giữa các thành phần khác nhau.
Các ràng buộc ngữ nghĩa xác định cách các thành phần có thể được tích hợp để tạo thành hệ thống.
Bố cục cấu trúc liên kết của các thành phần chỉ ra mối quan hệ qua lại trong thời gian chạy của chúng.

Thiết kế kiến trúc chung

Bảng sau liệt kê các kiểu kiến trúc có thể được sắp xếp theo khu vực trọng tâm chính của chúng:

thể loại	Thiết kế kiến trúc	Sự miêu tả
Giao tiếp	Xe buýt tin nhắn	Quy định việc sử dụng một hệ thống phần mềm có thể nhận và gửi tin nhắn bằng một hoặc nhiều kênh liên lạc.
Giao tiếp	Kiến trúc hướng dịch vụ (SOA)	Xác định các ứng dụng hiển thị và sử dụng chức năng như một dịch vụ bằng cách sử dụng hợp đồng và tin nhắn.
Triển khai	Máy khách / máy chủ	Tách hệ thống thành hai ứng dụng, nơi máy khách thực hiện các yêu cầu đến máy chủ.
Triển khai	3 bậc hoặc N-tier	Tách chức năng thành các phân đoạn riêng biệt với mỗi phân đoạn là một cấp nằm trên một máy tính vật lý riêng biệt.
Miền	Thiết kế theo hướng miền	Tập trung vào việc lập mô hình miền kinh doanh và xác định các đối tượng kinh doanh dựa trên các thực thể trong miền kinh doanh.
Kết cấu	Dựa trên thành phần	Chia nhỏ thiết kế ứng dụng thành các thành phần chức năng hoặc logic có thể sử dụng lại để hiển thị các giao diện truyền thông được xác định rõ ràng.
	Nhiều lớp	Chia các mối quan tâm của ứng dụng thành các nhóm (lớp) xếp chồng lên nhau.
	Hướng đối tượng	Dựa trên việc phân chia trách nhiệm của một ứng dụng hoặc hệ thống thành các đối tượng, mỗi đối tượng chứa dữ liệu và hành vi liên quan đến đối tượng.

Các loại kiến trúc

Có bốn loại kiến trúc từ quan điểm của một doanh nghiệp và gọi chung, những kiến trúc này được gọi là enterprise architecture.

Business architecture - Xác định chiến lược kinh doanh, quản trị, tổ chức và các quy trình kinh doanh chính trong doanh nghiệp và tập trung vào việc phân tích và thiết kế các quy trình kinh doanh.
Application (software) architecture - Đóng vai trò là bản thiết kế cho các hệ thống ứng dụng riêng lẻ, các tương tác của chúng và mối quan hệ của chúng với các quy trình kinh doanh của tổ chức.
Information architecture - Xác định tài nguyên dữ liệu logic và vật lý và tài nguyên quản lý dữ liệu.
Information technology (IT) architecture - Xác định các khối xây dựng phần cứng và phần mềm tạo nên hệ thống thông tin tổng thể của tổ chức.

Quy trình thiết kế kiến trúc

Quá trình thiết kế kiến trúc tập trung vào việc phân rã một hệ thống thành các thành phần khác nhau và sự tương tác của chúng để thỏa mãn các yêu cầu chức năng và phi chức năng. Các yếu tố đầu vào quan trọng để thiết kế kiến trúc phần mềm là:

Các yêu cầu do nhiệm vụ phân tích tạo ra.
Kiến trúc phần cứng (kiến trúc phần mềm lần lượt cung cấp các yêu cầu cho kiến trúc sư hệ thống, người định cấu hình kiến trúc phần cứng).

Kết quả hoặc đầu ra của quá trình thiết kế kiến trúc là một architectural description. Quy trình thiết kế kiến trúc cơ bản bao gồm các bước sau:

Hiểu vấn đề

Đây là bước quan trọng nhất vì nó ảnh hưởng đến chất lượng của thiết kế sau đó.
Nếu không hiểu rõ vấn đề thì không thể tạo ra giải pháp hữu hiệu.
Nhiều dự án và sản phẩm phần mềm bị coi là thất bại vì chúng không thực sự giải quyết được vấn đề kinh doanh hợp lệ hoặc có lợi tức đầu tư (ROI) dễ nhận biết.

Xác định các yếu tố thiết kế và mối quan hệ của chúng

Trong giai đoạn này, hãy xây dựng đường cơ sở để xác định ranh giới và bối cảnh của hệ thống.
Phân rã hệ thống thành các thành phần chính của nó dựa trên các yêu cầu chức năng. Sự phân rã có thể được mô hình hóa bằng cách sử dụng ma trận cấu trúc thiết kế (DSM), cho thấy sự phụ thuộc giữa các phần tử thiết kế mà không chỉ rõ mức độ chi tiết của các phần tử.
Trong bước này, xác nhận đầu tiên của kiến trúc được thực hiện bằng cách mô tả một số trường hợp hệ thống và bước này được gọi là thiết kế kiến trúc dựa trên chức năng.

Đánh giá thiết kế kiến trúc

Mỗi thuộc tính chất lượng được đưa ra một ước tính để thu thập các thước đo định tính hoặc dữ liệu định lượng, thiết kế được đánh giá.
Nó liên quan đến việc đánh giá kiến trúc về sự phù hợp với các yêu cầu thuộc tính chất lượng kiến trúc.
Nếu tất cả các thuộc tính chất lượng ước tính theo tiêu chuẩn yêu cầu, thì quá trình thiết kế kiến trúc đã kết thúc.
Nếu không, giai đoạn thứ ba của thiết kế kiến trúc phần mềm được bước vào: chuyển đổi kiến trúc. Nếu thuộc tính chất lượng quan sát được không đáp ứng yêu cầu của nó, thì một thiết kế mới phải được tạo ra.

Chuyển đổi thiết kế kiến trúc

Bước này được thực hiện sau khi thẩm định thiết kế kiến trúc. Thiết kế kiến trúc phải được thay đổi cho đến khi hoàn toàn thỏa mãn các yêu cầu thuộc tính chất lượng.
Nó liên quan đến việc lựa chọn các giải pháp thiết kế để cải thiện các thuộc tính chất lượng trong khi vẫn duy trì chức năng miền.
Một thiết kế được biến đổi bằng cách áp dụng các toán tử, kiểu hoặc mẫu thiết kế. Để chuyển đổi, hãy sử dụng thiết kế hiện có và áp dụng toán tử thiết kế như phân rã, sao chép, nén, trừu tượng và chia sẻ tài nguyên.
Thiết kế được đánh giá một lần nữa và quá trình tương tự được lặp lại nhiều lần nếu cần thiết và thậm chí được thực hiện một cách đệ quy.
Các chuyển đổi (tức là các giải pháp tối ưu hóa thuộc tính chất lượng) thường cải thiện một hoặc một số thuộc tính chất lượng trong khi chúng ảnh hưởng tiêu cực đến những thuộc tính khác

Nguyên tắc kiến trúc chính

Sau đây là các nguyên tắc chính cần được xem xét khi thiết kế kiến trúc:

Xây dựng để thay đổi thay vì xây dựng để cuối cùng

Xem xét cách ứng dụng có thể cần thay đổi theo thời gian để giải quyết các yêu cầu và thách thức mới, đồng thời xây dựng tính linh hoạt để hỗ trợ điều này.

Giảm rủi ro và mô hình để phân tích

Sử dụng các công cụ thiết kế, trực quan hóa, hệ thống mô hình hóa như UML để nắm bắt các yêu cầu và quyết định thiết kế. Các tác động cũng có thể được phân tích. Không chính thức hóa mô hình đến mức nó ngăn cản khả năng lặp lại và điều chỉnh thiết kế một cách dễ dàng.

Sử dụng Mô hình và Hình ảnh hóa làm Công cụ Giao tiếp và Cộng tác

Giao tiếp hiệu quả về thiết kế, các quyết định và những thay đổi liên tục đối với thiết kế là rất quan trọng đối với kiến trúc tốt. Sử dụng các mô hình, khung nhìn và các hình ảnh trực quan khác về kiến trúc để giao tiếp và chia sẻ thiết kế một cách hiệu quả với tất cả các bên liên quan. Điều này cho phép truyền thông nhanh chóng các thay đổi đối với thiết kế.

Xác định và hiểu các quyết định kỹ thuật quan trọng và các lĩnh vực thường mắc sai lầm nhất. Đầu tư vào việc đưa ra các quyết định quan trọng ngay lần đầu tiên để làm cho thiết kế trở nên linh hoạt hơn và ít có khả năng bị phá vỡ bởi những thay đổi.

Sử dụng phương pháp tiếp cận tăng dần và lặp lại

Bắt đầu với kiến trúc đường cơ sở và sau đó phát triển các kiến trúc ứng viên bằng cách thử nghiệm lặp đi lặp lại để cải thiện kiến trúc. Lặp lại thêm các chi tiết vào thiết kế qua nhiều lần để có được bức tranh lớn hoặc đúng và sau đó tập trung vào các chi tiết.

Nguyên tắc thiết kế chính

Sau đây là các nguyên tắc thiết kế được xem xét để giảm thiểu chi phí, yêu cầu bảo trì và tối đa hóa khả năng mở rộng, khả năng sử dụng của kiến trúc -

Tách các mối quan tâm

Chia các thành phần của hệ thống thành các tính năng cụ thể để không có sự chồng chéo giữa các chức năng thành phần. Điều này sẽ mang lại sự gắn kết cao và khả năng ghép nối thấp. Cách tiếp cận này tránh được sự phụ thuộc lẫn nhau giữa các thành phần của hệ thống, giúp dễ dàng bảo trì hệ thống.

Nguyên tắc trách nhiệm đơn lẻ

Mỗi và mọi mô-đun của hệ thống phải có một trách nhiệm cụ thể, giúp người dùng hiểu rõ hệ thống. Nó cũng sẽ giúp tích hợp thành phần với các thành phần khác.

Nguyên tắc Kiến thức Ít nhất

Bất kỳ thành phần hoặc đối tượng nào không được có kiến thức về các chi tiết bên trong của các thành phần khác. Cách tiếp cận này tránh phụ thuộc lẫn nhau và giúp bảo trì.

Giảm thiểu thiết kế lớn trả trước

Giảm thiểu thiết kế lớn trả trước nếu yêu cầu của ứng dụng không rõ ràng. Nếu có khả năng sửa đổi các yêu cầu, thì tránh thiết kế lớn cho toàn bộ hệ thống.

Không lặp lại chức năng

Chức năng không lặp lại chỉ định rằng chức năng của các thành phần không được lặp lại và do đó một đoạn mã chỉ nên được triển khai trong một thành phần. Việc trùng lặp chức năng trong một ứng dụng có thể gây khó khăn cho việc triển khai các thay đổi, giảm độ rõ ràng và tạo ra các mâu thuẫn tiềm ẩn.

Ưu tiên Sáng tác hơn Kế thừa trong khi Sử dụng lại Chức năng

Kế thừa tạo ra sự phụ thuộc giữa các lớp con và lớp cha và do đó nó ngăn chặn việc sử dụng miễn phí các lớp con. Ngược lại, thành phần cung cấp một mức độ tự do lớn và giảm các thứ bậc kế thừa.

Xác định các thành phần và nhóm chúng trong các lớp logic

Các thành phần nhận dạng và khu vực quan tâm cần thiết trong hệ thống để thỏa mãn các yêu cầu. Sau đó, nhóm các thành phần liên quan này thành một lớp logic, điều này sẽ giúp người dùng hiểu được cấu trúc của hệ thống ở mức cao. Tránh trộn các thành phần của các loại mối quan tâm khác nhau trong cùng một lớp.

Xác định giao thức giao tiếp giữa các lớp

Hiểu cách các thành phần sẽ giao tiếp với nhau, điều này đòi hỏi kiến thức đầy đủ về các kịch bản triển khai và môi trường sản xuất.

Xác định định dạng dữ liệu cho một lớp

Các thành phần khác nhau sẽ tương tác với nhau thông qua định dạng dữ liệu. Không trộn lẫn các định dạng dữ liệu để các ứng dụng dễ triển khai, mở rộng và duy trì. Cố gắng giữ nguyên định dạng dữ liệu cho một lớp để các thành phần khác nhau không cần mã / giải mã dữ liệu trong khi giao tiếp với nhau. Nó làm giảm chi phí xử lý.

Các thành phần dịch vụ hệ thống phải là trừu tượng

Mã liên quan đến bảo mật, truyền thông hoặc các dịch vụ hệ thống như ghi nhật ký, lập hồ sơ và cấu hình phải được tóm tắt trong các thành phần riêng biệt. Không trộn mã này với logic nghiệp vụ, vì nó dễ dàng mở rộng thiết kế và duy trì nó.

Thiết kế Ngoại lệ và Cơ chế Xử lý Ngoại lệ

Xác định trước các ngoại lệ, giúp các thành phần quản lý lỗi hoặc tình huống không mong muốn một cách thanh lịch. Việc quản lý ngoại lệ sẽ giống nhau trong toàn bộ hệ thống.

Quy ước đặt tên

Quy ước đặt tên nên được xác định trước. Họ cung cấp một mô hình nhất quán giúp người dùng hiểu hệ thống một cách dễ dàng. Các thành viên trong nhóm sẽ dễ dàng xác nhận mã do người khác viết hơn và do đó sẽ tăng khả năng bảo trì.