Chia sẻ kiến trúc - Giải thích Clean Architecture

Рет қаралды 17,091

Күн бұрын

Trong video này mình chủ yếu chia sẻ về ý tưởng, triết lý và các đặc tính quan trọng của Clean Architecture. Một lỗi sai mình thường thấy nhất là các bạn hiểu sai cái Dependency Rule nên phần nào gây nhầm lẫn và khó triển khai.
1. Triết lý của Clean Architecture giống với Hexagonal và Onion Architecture: cô lập và lấy business logic làm trọng tâm (có thể gọi là Domain). Bên ngoài giao tiếp thông qua các Ports: Input và Output.
2. Các vòng tròn ở ngoài cùng là chi tiết nhất (low-level/details), trong cùng là high level (trừu tượng).
3. Cái "mũi tên" trong ảnh Clean Architecture không phải là "call direction" mà là "dependency direction". Bởi vì:
4. Clean Architecture sử dụng Dependency Inversion (DI) - chữ D trong SOLID.
- High level không phụ thuộc vào low level, chúng lệ thuộc abstraction.
- Abstraction không lệ thuộc vào implements/details của nó.
Từ đó các thay đổi từ các tầng low-level (chi tiết) không gây ảnh hưởng gì đến Domain ở trong. Và domain dễ dàng test, maintain một cách độc lập.
Khi implement Clean Architecture thì cấu trúc thư mục, cách phân chia package sao cũng được, miễn thoả các đặc tính trên.
Thường để đảm bảo DI, các SE kinh nghiệm thường khai báo các interfaces cần thiết ở trong domain, sau đó viết business logic, mocktesting các kiểu xong hết mới đi xử các tầng details bên ngoài: Như DB, HTTP Handlers,...
Cách này có thể gọi là Use Case first hoặc Doman Driven. Tuy nhiên để gọi là DDD và làm đúng và đủ thì còn khá nhiều thứ nữa.
Có thời gian mình sẽ nói DDD sau!!!

Пікірлер: 39

@200labeducation4 Жыл бұрын

Clip hướng dẫn implement Clean Architecture: kzbin.info/www/bejne/j5C3lmiHaMyrg6s

@namvu3996 11 ай бұрын

anh ơi! giải thích thêm về domain driven design đi ak.

@Huỳnh-n7q 4 ай бұрын

A ơi! em bị yếu về mấy thứ kiến trúc này. Em xem nhiều mà không hiểu rõ. Em nghĩ là em nên học lại cho chắc phần kiến trúc. Anh cho em lời khuyên em nên bắt đầu từ đâu ạ

@maison9508 Жыл бұрын

Tôi xác nhận bạn giải thích đúng, vì tôi cũng đang làm kiến trúc này trong dự án Mobile. Bổ sung thêm phần presentation sẽ là MVVM, MVP hay MVC. Và nó gọi vào class Usecase implement kế thừa IUsecase.

@lvthuong7759 Жыл бұрын

interface IRepositoryPlayer { getAllPlayer: () => Promise; } class RepositoryPlayer implements IRepositoryPlayer { getAllPlayer() { // get from DB return Promise.resolve(["thuong"]); } } class PlayerService { constructor(private repository: IRepositoryPlayer) {} } const repoPlayer = new RepositoryPlayer(); const player = new PlayerService(repoPlayer); Theo em hiểu cái đoạn 9:11 sẽ là ntn đúng k a ạ ?.

@viettx Жыл бұрын

Yes e

@trungbui7518 Жыл бұрын

Nói xuông vậy thì em xem nhiều rồi. Chưa thấy ai bắt tay xây dựng một cái project giống y như vậy cho dễ hiểu đó anh @@

@viettx Жыл бұрын

Nhiều mà, từ template tới demo ở rất nhiều ngôn ngữ, a cũng có một demo nho nhỏ cho cả Clean Architecture và Miroservices: github.com/viettranx/micro-clean-architecture-service-demo

@trungbui7518 Жыл бұрын

@@viettx anh làm 1 video step by step đi anh

@lewis.chien_ Жыл бұрын

@@viettx a Việt ơi, nếu theo demo của anh, thì e dùng "go mockery" để gen test mock, thì ở folder business sẽ không có mock interface của chính tầng business đó. và cái test mock được gen bởi "go mockery" chính là test mock của folder storage. a có thể hướng dẫn viết test theo kiến trúc mà a refer được không ạ. e cảm ơn ạ.

@viettx Жыл бұрын

@@lewis.chien_ e check lại nhánh master vì a có refactor lại bỏ đi storage cho đơn giản và fit CA hơn

@viettx Жыл бұрын

@@lewis.chien_ e mock cái repository để unit test cho business nha.

@dongtruong3323 7 ай бұрын

Khi mình implement ở layer usercase mình sẽ define IRepository và IUserCase, còn data layer ở tầng low level nó phải import interface repo từ usercase phải k vậy?

@tonghoangvudev 7 ай бұрын

Mình đọc nhiều về các loại architecture rồi, nhưng khi xem clip này mới thấy thực sự ưng ý.

@nguyenucminh8993 2 ай бұрын

Kiến thức anh chia sẻ hay và dễ hiểu +1 respect ạ!

@linhvuquach Жыл бұрын

Nice voice, nice content. I respect you. By the way, I've subcribed and I think that I'll follow you in the future.

@dwcls Жыл бұрын

Em vẫn đang chưa hiểu chút ở đoạn 6:30 phần business logic implements IUsecase như nào anh ạ? Tức là IUsecase sẽ defind những function rồi Business logic sẽ implments IUsecase đó phải không anh?

@viettx Жыл бұрын

Clip hướng dẫn implement Clean Architecture và mock test: kzbin.info/www/bejne/j5C3lmiHaMyrg6s

@vanhieuao4154 Жыл бұрын

cho e hỏi thêm với ạ, ở phút 9:00 em thấy ý tưởng đặt `IRepository` ở tầng usecase của a rất hay. nhưng nếu làm theo cách này thì tầng data ở dưới phải import ngược lên module usecase => data layer nó phụ thuộc vào usecase layer rồi đúng k ạ, theo e ĐÚNG phải là tầng usecase phụ thuộc vào tầng data ạ. Có cách nào giải quyết vấn đề này không ạ?

@viettx Жыл бұрын

Em nghe lại đoạn nguyên lý Clean Architecture nhé. Data Layer (DB) là tầng low level (details) nên sẽ depend vào tầng high level (use case) - Dependency Inversion (lệ thuộc đảo). Nếu UseCase lệ thuộc vào Data Layer sẽ khiến UseCase sẽ thay đổi khi DL thay đổi. Việc này vi phạm nguyên lý DI.

@dinhluandev Жыл бұрын

Cám ơn những kiến thức bổ ích mà anh đã chia sẻ.

@vanhieuao4154 Жыл бұрын

dạ cho e hỏi ạ. cái dialog 4:40 . trường hợp trong project chỉ có duy nhất một 1 implementation của contract `IUseCase` và tầng Data cũng chỉ có duy nhất 1 implementation của `IRepository` thì có nhất thiết phải áp dụng DI, tạo ra 2 interface chỗ này không ạ? em thấy đang phức tạp hoá 1 vấn đề đơn giản ạ. Vì theo em hiểu mình dùng Interface để có thể thay đổi một cách dynamic at runtime mà trong project chỉ có duy nhất 1 implementation của contract đó thì "WITHOUT DI" chỗ này cũng giải quyết tốt vấn đề ạ!

@viettx Жыл бұрын

Dù chỉ có một implement duy nhất nhưng nếu ko abstraction qua interface thì: - Tightly Coupling giữa các object. Tương lai nếu cần thay đổi repo là phải đổi code ở 2 object. VD đơn giản là caching hoặc đổi db engine, hoặc chia read/write. - Vì gọi trực tiếp thì sẽ gần như ko mock để Unit Testing đc, buộc phải mở real connection để test (integration). Nếu chương trình không bao giờ thay đổi, test một lần duy nhất thì ko cần tới kiến trúc.

@viettx Жыл бұрын

Với e coi thêm clip này nhé: kzbin.info/www/bejne/j5C3lmiHaMyrg6s

@vanhieuao4154 Жыл бұрын

@@viettx dạ cảm ơn anh, em hiểu rồi ạ.

@thinhnp6771 Жыл бұрын

Cảm giác nghe nó hơi bị trừu tượng sao ấy anh Việt. Em nghĩ nếu có example demo thì sẽ tường minh hơn về kiến trúc ạ

@viettx Жыл бұрын

Example sẽ là code implement mất rồi e ạ. Quan trọng nhất vẫn là dependency rule và isolate business logic thôi à.

@viettx Жыл бұрын

Clip hướng dẫn implement Clean Architecture: kzbin.info/www/bejne/j5C3lmiHaMyrg6s

@Kai-wi1md Жыл бұрын

Em chào Anh, Anh có thể giải thích giúp em Presenters layer implement cái gì được không ạ? +, Flow từ: UI -> presenters -> use case Em không biết presenters có chức năng gì trong flow này. Cùng với đó là flow of control ở sơ đồ góc dưới dùng bên phải với ạ: +, Controller -> use case interactor -> presenters. Vì theo dependence rule thì low level sẽ depend vào high level nên em không hiểu cái flow này đi như nào cả. Em mới tìm hiểu về clean nên mong Anh thông cảm vì ngôn từ có thể không được chuẩn chỉnh ạ. Em cảm ơn Anh nhiều.

@viettx Жыл бұрын

Để dễ phân biệt, presenter thường đại diện cho view, hoặc view model (dạng dữ liệu, modeling dành cho view). UI có thể dựa trên view model để render. Thông thường chúng ta sẽ thấy presenter là một interface, và view là một implement của nó. Ở tầng này sẽ xử lý render UI, events,... Mục đích là 1 view model sẽ được thể hiện dưới nhiều view cụ thể khác nhau. Controller là tầng thường dùng để xử lý logic. Theo clean thì controller và presenter là chung một cấp (level/layer). Chẳng qua là chúng khác biệt về nhiệm vụ. Flow của clean nếu trong một application có UI thường sẽ là: UI -> controller (thường gọi là input port) -> Use Case -> Presenter (output port) - vì view đang kết nối với presenter nên khi presenter thay đổi sẽ khiến UI thay đổi theo. Output port ở đây cần hiểu rộng ra là nó có thể là một presenter (liên quan tới view model) hoặc một persistent (database, storage), remote services. Presenter, Controller đều là low level so với Use Case. Để biết điểm gọi vào, chúng ta chỉ cần xem input port là gì. Trong ảnh kiến trúc clean (góc phải bên dưới), ta có Controller chính là input còn presenter là output.

@Kai-wi1md Жыл бұрын

@@viettx tức là cái flow và cái dependence rule là 2 cái hoàn toàn khác nhau phải không anh? Phải chăng em nhầm lẫn giữa flow và Dependence rule là một nên em mới hỏi như vậy?

@viettx Жыл бұрын

@@Kai-wi1md yes. Dependency là "lệ thuộc", không phải call flow.

@Kai-wi1md Жыл бұрын

@@viettx em cảm ơn anh nhiều.