Nội dung - Lịch sử kiến trúc phần mềm - Xu hướng của kiến trúc phần mềm 2020 - Một số thuật ngữ trong kiến trúc phần mềm - Khái niệm về kiến trúc phần mềm - Chất lượng phần mềm với loose coupling, high cohesion - Một số use-case ứng dụng kiến trúc phần mềm - Giới thiệu về clean architecture 3
No silver bullets - Không có một kiến trúc phần mềm nào thỏa mãn tất cả các yêu cầu của tất cả các loại phần mềm - Dựa vào yêu cầu của khách hàng mà chọn những kiến trúc phù hợp dựa vào sự ưu tiên những non-functional (quality attribute) tương ứng, ví dụ: + Phần mềm phục vụ lượng truy cập lớn cần đảm bảo tính chất availability => scalability, elasticity + Phần mềm xử lý dữ liệu lớn đảm bảo tính chất performance => highly distributed system: hadoop, spark, cache system + Phần mềm cần phát triển lâu dài cần đảm bảo tính maintainability 7
Architectural style - Định nghĩa một họ các kiến trúc về cách các thành phần được tổ chức và sắp xếp với nhau như thế nào, bị giới hạn bởi từ vựng về element, connector, các topology rule và các ràng buộc về mặt ngữ nghĩa - Ví dụ: - Component-based - Monolithic - Layered - Client-server - Service-oriented - … => chúng chỉ là khái niệm định hình lên "phong cách, ý tưởng" xây dựng hệ thống 10
Architectural pattern - Là một giải pháp giải quyết một vấn đề lặp đi lặp lại theo định hướng của architectural style, ảnh hưởng trực tiếp đến codebase - Ví dụ: - Three layer, domain driven design, clean architecture => layered - Three tier, client-server => multi-tier - MV* architecture (MVC, MVP, MVVM, MVI) - Microservices 11
Design pattern - Là một giải pháp giải quyết một vấn đề lặp đi lặp lại, nhưng giải quyết những vấn đề cục bộ, không ảnh hưởng lớn đến codebase - Ví dụ: - Cách tạo đối tượng: factory method, builder, singleton - Cách xây dựng giải thuật bằng cách tạo mối quan hệ giữa các đối tượng: adapter, bridge, composite, decorator - Cách hiện thực các hành vi giữa các đối tượng: template method, chain of responsibility, command, mediator, state, strategy 12
Coupling - Coupling đề cập đến quá trình phụ thuộc lẫn nhau giữa các components như class, module, … - Tight coupling là một trạng thái mà ở đó các component quá phụ thuộc vào nhau, khi một component thay đổi thì các component phụ thuộc nó cũng thay đổi => chương trình dễ vỡ do không kiểm soát được logic (side-effect) - Loose coupling là một trạng thái mà ở đó các component phụ thuộc yếu vào nhau => dễ thay đổi mà không thay đổi quá nhiều module phụ thuộc vào nó => tăng tốc độ dự án và bảo trì 15
Tight coupling - Sử dụng variable bên ngoài, vi phạm luật Demeter => thay đổi logic variable bên ngoài sẽ phải xem xét tính logic trong class sử dụng nó 16
Giải pháp - Mục tiêu thiết kế chúng ta cần hướng đến là đảm bảo hệ thống ít bị ảnh hưởng khi có thay đổi, từ đó tăng tốc độ thực thi dự án và bảo trì dự án => Giải pháp để đạt loose coupling: - Dependency inversion: tất cả module kế thừa, giao tiếp với nhau nên phụ thuộc vào abstraction (interface) - Law of demeter "Don't talk to strangers" 18
Cohesion - Phản ánh sự gắn kết của các thành phần trong module có thể về mặt tính năng hoặc logic, thủ tục, thông tin - Low cohesion là một trạng thái mà tại đó một tính năng bị dàn trải qua nhiều module => khi thay đổi thì phải thay đổi ở tất cả các module - High cohesion là một trạng thái mà tại đó các module rõ ràng và tách biệt với các module khác (một module đáp ứng một tính năng) 19
High cohesion - Các method sử dụng các private variable - Không có method dư thừa như: method làm những nhiệm vụ không khớp với chức năng của class, method thuộc dạng utility - Mỗi class chỉ làm một trách nhiệm và chỉ có một lý do để thay đổi 21
Giải pháp - Sử dụng các công cụ static analysis như sonar, NDepend, JDepend để tìm ra các class cần phải refactor, để các class gắn kết hơn, thiết kế code đơn giản hơn cho các bên liên quan sử dụng - Một chức năng nên được phát triển trong một module - Loại bỏ các phụ thuộc ẩn vì nó gây khó hiểu, spaghetti code, lỗ hổng hệ thống 22
Tóm tắt - Không có kiến trúc "tốt" hoặc "tệ" nếu không đi kèm ngữ cảnh, kiến trúc cần có những thuộc tính chất lượng đặc trưng trong nó - Kiến trúc phần mềm cho thấy cấu trúc tổng quát, vĩ mô của phần mềm bao gồm các elements, các connector gắn kết các elements, các thuộc tính chất lượng - Kiến trúc phần mềm không chỉ là thiết kế mã mà còn là: quản lý các yêu cầu phi chức năng, định nghĩa kiến trúc, lựa chọn công nghệ, đánh giá kiến trúc, sự cộng tác thiết kế kiến trúc và chuyển giao kiến trúc phần mềm Theo http://www.apexglobal.com.vn 28
Giới thiệu về clean architecture 1. Vì sao clean architecture ra đời 2. Giới thiệu về clean architecture 3. Lợi ích của clean architecture 4. Hạn chế của clean architecture 29
Clean architecture 1. Vì sao clean architecture ra đời a. Tạo 1 kiến trúc dễ hiểu, dễ phát triển, dễ bảo trì b. Giảm thiểu chi phí lâu dài của hệ thống và tối đa hóa năng suất của lập trình viên 30
Clean architecture 3. Lợi ích - Tách ra các lớp rõ ràng với nhiệm vụ riêng => dễ đọc/chỉnh sửa code - Giảm sự phụ thuộc giữa các thành phần - Dễ test hơn 33
Clean architecture 4. Hạn chế - Tách ra nhiều lớp => implement hơi cồng kềnh - Không phải project nào cũng áp dụng được. Thường dùng để build server 34
Tài liệu tham khảo - Hgraca - The Software Architecture Chronicles https://herbertograca.com/2017/07/03/the-software-architecture-chronicles/ - Hgraca - Clean Architecture: Standing on the shoulders of giants https://herbertograca.com/2017/09/28/clean-architecture-standing-on-the-sho ulders-of-giants/ - Mario Sanoguera de Lorenzo - Clean Architecture Guide https://proandroiddev.com/clean-architecture-data-flow-dependency-rule-615ff dd79e29 - Iman Tumorang - Trying Clean Architecture on Golang https://hackernoon.com/golang-clean-archithecture-efd6d7c43047 35
thanhgit
ghtaro
kentaroy47
otanet
s_mizuki_nlp
takehaya
pw
masakat0
gpeyre
cocomoff
kuribayashi4
ebisawahayata
sgnm
dotmariusz
jennybc
paulrobertlloyd
vanstee
malarkey
csswizardry
deanohume
smashingmag
ammeep
tmm1
hatefulcrawdad