Cần bao nhiêu thiết kế Kiến trúc trước trên quy mô từ hoàn toàn không có thiết kế đến giải pháp được lập thành văn bản đầy đủ? Tất nhiên không có cực đoan nào là tốt nhưng đâu là thước đo thực sự và làm thế nào để chọn ra?

Vấn đề là với việc giới thiệu cách thức làm việc Agile, mọi thứ đã thay đổi cách phát triển phần mềm, do đó kiến ​​trúc phần mềm cũng nên tuân theo. Lập trước một kế hoạch chi tiết chi tiết trong khi chạy nước rút và chấp nhận sự thay đổi ( giá trị thứ 4 của Tuyên ngôn Agile ) không phải là sự kết hợp tốt nhất. Một số cách tiếp cận khác là cần thiết để bạn có thể nghe đến thuật ngữ Kiến trúc Agile nhưng nó thực sự là gì và nó tạo ra kiểu thiết kế kiến ​​trúc nào?

Kiến trúc theo định nghĩa là một thứ gì đó là cơ sở tốt không nên thay đổi. Vấn đề với ngành phát triển phần mềm là một thực tế là bối cảnh thay đổi rất được nhấn mạnh. Vì vậy, kiến ​​trúc phần mềm không thể được coi là kiến ​​trúc trong các ngành công nghiệp khác (ví dụ: xây dựng) mà là một thứ gì đó dễ thích nghi và nhanh nhẹn hơn nhiều.

Giới thiệu MVA

MVP ( Sản phẩm khả thi tối thiểu ) là tạo tác quan trọng cho các khuôn khổ Lean và Agile . Khái niệm này giải thích cách sản phẩm nên được xây dựng theo từng bước trong khi hướng đến tầm nhìn sản phẩm. Kể từ khi cách làm việc Agile đó trở thành tiêu chuẩn thực tế cho phát triển phần mềm, tôi tin rằng Kiến trúc phần mềm phải giới thiệu Kiến trúc khả thi tối thiểu như một tạo tác - MVA .

Vì vậy, MVA trong lần lặp đầu tiên, trong sprint đầu tiên hoặc trước khi bắt đầu dự án, phải chứa đựng tầm nhìn về Kiến trúc phần mềm của ứng dụng sẽ được phát triển. Mức độ của các chi tiết nên thay đổi dựa trên nhiều tiêu chí và nhiệm vụ của Kiến trúc sư là làm cho nó tối ưu. Ví dụ: nếu miền giống với miền mà nhóm đã làm việc trước đây thì hầu hết mọi thứ đều đã được biết đến, thì sẽ có một sự học hỏi rất lớn và một số phương pháp hay có thể được tái chế. Nhưng nếu tên miền là hoàn toàn mới thì cần phải chú ý nhiều hơn. Ngoài ra, một trong những tiêu chí rõ ràng nhất là kích thước và độ phức tạp của ứng dụng, vì vậy quy tắc ngón tay cái phải phức tạp hơn một trong những yêu cầu thiết kế kiến ​​trúc từ trước.

Nó không chỉ là về mức độ chi tiết mà còn là trọng tâm nên ở đâu? Nếu ứng dụng yêu cầu SLA hoặc các trường hợp sử dụng đồng thời có lưu lượng cao, trọng tâm nên tập trung vào những phần cho phép khả năng mở rộng và tính khả dụng của giải pháp. Hoặc nếu rủi ro là về bảo mật và quyền riêng tư, trọng tâm của MVA có thể là một phần đầu tiên của giải pháp.

Nội dung MVA

Bellow là một ví dụ về MVA có thể được sử dụng làm điểm khởi đầu. Danh sách này nên được nâng cấp dựa trên ứng dụng cụ thể sẽ được xây dựng.

• Cảnh quan kiến ​​trúc của ứng dụng (n-tier, microservice, serverless, v.v.)
• Các thành phần được hình dung và mối quan hệ và sự phụ thuộc của chúng
• Ngăn xếp công nghệ và công cụ
• Xây dựng và tự động hóa các công cụ và môi trường