Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

6ddf14675dfb386411b41f6737bc758f?s=47 thanhgit
January 24, 2021

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

- Introducing overview about software architecture
- Introducing clean architecture

6ddf14675dfb386411b41f6737bc758f?s=128

thanhgit

January 24, 2021
Tweet

Transcript

  1. 1

  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
  9. 9

  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

  14. 14

  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

  25. 25

  26. 26

  27. 27

  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