Giới thiệu về kiến trúc phần mềm

- Introducing overview about software architecture
- Introducing clean architecture

Transcript

2. Giới thiệu về kiến trúc phần mềm Thanh Nguyen & Hieu Phan 2
3. 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
4. Lịch sử kiến trúc phần mềm - 1950s: - Non-structured programming - 1951: assembly - 1960s: - Structured programming (Procedural/ functional) (List, Fortran) - Layering: 1 tier with UI, business logic and data storage - 1970s: - 1979: MVC pattern - 1980s: - Object oriented programming (OOP) - Layering: 2 tier with 1st tier is UI and 2nd tier are business logic and data storage 4
5. - 1990s: - Layering: 3 tier with each separated tier for UI, business logic and data storage - 1996: MVP pattern, SOLID principles - 1997: Aspect oriented programming, web services, enterprise service bus - 2000s: - 2003: Domain driven design (Eric Evans) - 2005 MVVM pattern, hexagonal architecture - 2006 Command Query Responsibility Separation, Event sourcing - 2008: Onion architecture - 2009: Microservice architecture (at Netflix) - 2010s: - 2010: Data-context-interaction architecture - 2012: Clean architecture (Robert Martin) - 2014: C4 model (Context, Containers, Components, Code) 5
6. https://www.infoq.com/articles/architecture-trends-2020/ 6
7. 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
8. Trade-off - Dựa vào yêu cầu của phần mềm mà ta chọn những quality attribute tương ứng 8
10. 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
11. 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
12. 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
13. Loose coupling VS high cohesion 13
15. 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
16. 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
17. Loose coupling - Giao tiếp giữa các class thông qua interface 17
18. 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
19. 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
20. Low cohesion - Các method không liên quan đến class - Utility class - Hidden object và subclass - Một class làm nhiều hơn một trách nhiệm 20
21. 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
22. 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
23. So sánh giữa cohesion và coupling 23
24. Use case 24
28. 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
29. 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
30. 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
31. Clean architecture 2. Giới thiệu 31
32. Clean architecture 2. Giới thiệu 32
33. 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
34. 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
35. 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