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

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

thanhgit

January 24, 2021
Tweet

More Decks by thanhgit

Other Decks in Research

Transcript

  1. Giới thiệu về kiến trúc phần mềm
    Thanh Nguyen & Hieu Phan
    2

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  5. https://www.infoq.com/articles/architecture-trends-2020/
    6

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  11. Loose coupling VS high cohesion
    13

    View full-size slide

  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

    View full-size slide

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

    View full-size slide

  14. Loose coupling
    - Giao tiếp giữa các class
    thông qua interface
    17

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  20. So sánh giữa cohesion và coupling
    23

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  24. Clean architecture
    2. Giới thiệu
    31

    View full-size slide

  25. Clean architecture
    2. Giới thiệu
    32

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide