thảo luận Clean Architecture có thật sự giúp ta code tốt hơn?

- Mình có đọc cuốn Clean Architecture có tác giả Robert Martin, lúc mới đọc thì cảm thấy như tìm được chân lý vậy nhưng sau khi áp dung nó vào trong công việc thì thấy thưc sự có nhiều vấn đề, cụ thể như sau:

• Khối lượng code sẽ phình ra rất nhiều, và tồn tại rất nhiều boilerplate => code rất chán.
• Trong giai đoạn đầu của project, khi mà requirements thay đổi liên tục thì để sửa code được implement theo clean architecture rất tốn thời gian cụ thể: phải sửa entities, repository, business logic ...
• Hầu hết chúng ta đang sử dụng framework và hầu hết những framework này đều không tuân thủ Clean Architecture, nên để áp dụng nó mình phải bỏ những phần được framework hỗ trợ, và chọn cách đi lòng vòng hơn để tuân thủ SOLID. Đôi lúc thấy bản thân mình như chế tạo lại cái bánh xe vậy.

Đó là những khó khăn mình đang gặp phải khi áp dụng clean architecture vào các dự án hiện tại của mình. Để áp dụng được thì không khó, nhưng thực sự thấy có quá nhiều vấn đề. Mong các cao nhân trên đây chia sẻ về kiến trúc này và chia sẻ thêm về kiến trúc code trong các dự án hiện tại của mọi người.

soibac123bk said:

• Khối lượng code sẽ phình ra rất nhiều, và tồn tại rất nhiều boilerplate => code rất chán.
• Trong giai đoạn đầu của project, khi mà requirements thay đổi liên tục thì để sửa code được implement theo clean architecture rất tốn thời gian cụ thể: phải sửa entities, repository, business logic ...

Click to expand...

đây chính là vấn đề, clean architecture ko phải phù hợp trong mọi trường hợp, nó sẽ giúp cho codebase dễ maintain hơn, nhưng ko đồng nghĩa với việc dễ develop hơn

midnight_sun said:

đây chính là vấn đề, clean architecture ko phải phù hợp trong mọi trường hợp, nó sẽ giúp cho codebase dễ maintain hơn, nhưng ko đồng nghĩa với việc dễ develop hơn

Click to expand...

Clean Architectures in Python - presented by Leonardo Giorda
Mình cũng đồng ý với điều này, như trong này bài thuyết trình tác giả cũng có nói cuối cùng clean architecture cũng chỉ là tên gọi, ko tuân thủ clean architecture k hẳn là xấu mà tuân thủ clean architecture cũng k hẳn là tốt. Hóng các bác chia sẻ kiến trúc code các bác đang sử dụng là gì

soibac123bk said:

Clean Architectures in Python - presented by Leonardo Giorda
Mình cũng đồng ý với điều này, như trong này bài thuyết trình tác giả cũng có nói cuối cùng clean architecture cũng chỉ là tên gọi, ko tuân thủ clean architecture k hẳn là xấu mà tuân thủ clean architecture cũng k hẳn là tốt. Hóng các bác chia sẻ kiến trúc code các bác đang sử dụng là gì

Click to expand...

kiến trúc thì mỗi người 1 ý, nên chọn cái nào mà cả team dễ follow, dễ phát triển là ưu tiên hàng đầu, và quan trọng phải có testing, code mà ko test được thì là ko tốt, phải xem xét lại, có test thì cũng giúp cho việc maintain dễ dàng hơn, cân bằng được yếu tố develop và maintain

trong hợp đồng của project có chữ SOLID hoặc architecture có SOLID, thì đó là cái phải theo. kể cả việc code coverage, ví dụ 70% mới dc lên test env, hoặc QA ko test thì có cl mà lên dc prod env

dead line là thứ giết chết tất cả, my fen cần cứng rắn để bảo vệ quan điểm

mấy thằng senior architect nó cũng chỉ hơn ông senior dev chỗ này: bảo vệ quan điểm, phần lớn là giải thích được 1 cách hợp lý, hoặc thằng cùn thì nó bảo tao chốt thế

midnight_sun said:

kiến trúc thì mỗi người 1 ý, nên chọn cái nào mà cả team dễ follow, dễ phát triển là ưu tiên hàng đầu, và quan trọng phải có testing, code mà ko test được thì là ko tốt, phải xem xét lại, có test thì cũng giúp cho việc maintain dễ dàng hơn, cân bằng được yếu tố develop và maintain

Click to expand...

mình thấy nếu k chia layers ra thì khá là khó test á bạn, hoặc có thì code coverage không được cao cho lắm, nhất là trong nhưng dự án business logic hết sức phức tạp. Mình thấy về việc có thể test với coverage cao thì clean architecture làm khá tốt

Love U So Much said:

trong hợp đồng của project có chữ SOLID hoặc architecture có SOLID, thì đó là cái phải theo. kể cả việc code coverage, ví dụ 70% mới dc lên test env, hoặc QA ko test thì có cl mà lên dc prod env

dead line là thứ giết chết tất cả, my fen cần cứng rắn để bảo vệ quan điểm

mấy thằng senior architect nó cũng chỉ hơn ông senior dev chỗ này: bảo vệ quan điểm, phần lớn là giải thích được 1 cách hợp lý, hoặc thằng cùn thì nó bảo tao chốt thế

Click to expand...

à ý mình là bàn về những điểm được và chưa được của clean architecture khi áp dụng trong những dự án thực tế, với business khá phức tạp thôi bác. Còn kiểu cùn cùn thì mình không nói

soibac123bk said:

mình thấy nếu k chia layers ra thì khá là khó test á bạn, hoặc có thì code coverage không được cao cho lắm, nhất là trong nhưng dự án business logic hết sức phức tạp. Mình thấy về việc có thể test với coverage cao thì clean architecture làm khá tốt

Click to expand...

mình có nói là ko chia layer đâu, kiến trúc thì nhiều kiểu layer mà, thường thì controller->service->repository, có team thì ko cần repository, có team thì kết hợp cả cqrs, cái này thì mỗi team tự quyết định, nhưng cái goal chia thế nào thì cuối cùng phải là dễ test

requirements thay đổi liên tục

Click to expand...

gặp case y chang cái này
ban đầu thì có tầm 200-300 model xử lý như nhau hết, nên gom chung vô 1 cái service xử lí chung
mà kinh doanh 1 hồi thì team bên đó đòi cái này cái kia, tùm lum thứ
cuối cùng phải ngồi chia ra đủ vài vài trăm file cho cái đống trên để lúc update tiện hơn
file thì nhiều mà được cái update tiện, khỏi phải sờ mò vô cái đống clean

soibac123bk said:

• Trong giai đoạn đầu của project, khi mà requirements thay đổi liên tục thì để sửa code được implement theo clean architecture rất tốn thời gian cụ thể: phải sửa entities, repository, business logic ...

Click to expand...

Vậy nên mới có DDD, build DDD trước, cho vững rồi đắp layers ở ngoài thì thay đổi code cũng không khó. Còn nếu business thay đổi xoành xoạch thì vấn đề không phải nằm ở architecture mà là bản thân business có vấn đề.

midnight_sun said:

mình có nói là ko chia layer đâu, kiến trúc thì nhiều kiểu layer mà, thường thì controller->service->repository, có team thì ko cần repository, có team thì kết hợp cả cqrs, cái này thì mỗi team tự quyết định, nhưng cái goal chia thế nào thì cuối cùng phải là dễ test

Click to expand...

controller->service->repository
Từ bên ngoài giao tiếp với layer bên trong bác có dùng đến đến entity không bác hay chỉ dùng mỗi simple structure thôi, vì em thấy nếu không dùng thì có vẻ code khá là messy, ví dụ từ controller gọi vào service mà truyền cả một object thì khá khó cho người đọc code hiểu được trong object đó cần có những gì.

làm mà cứ lý thuyết rồi áp dụng máy móc thì méo có cái nào là tốt cả :v

billy_don said:

Vậy nên mới có DDD, build DDD trước, cho vững rồi đắp layers ở ngoài thì thay đổi code cũng không khó. Còn nếu business thay đổi xoành xoạch thì vấn đề không phải nằm ở architecture mà là bản thân business có vấn đề.

Click to expand...

mình đang thấy tư tưởng của DDD và clean architecture không khác nhau nhiều lắm. Mình không phủ nhận những điểm mạnh của DDD hay clean architecture như khi triển khai thì rất tốn thời gian và không phù hợp với những project dạng startup

Theo kinh nghiệm cá nhân thì đảm bảo phân tách được phần hiển thị (view) và nghiệp vụ (business/logic) là được rồi, cũng ko nhất thiết phải áp dụng tất cả SOLID. Một lưu ý nữa là code nên dễ hiểu và dễ bảo trì. Chứ cứ theo Clean, mấy bạn mới tiếp xúc đọc sẽ chả hiểu gì, bảo trì, backup cũng khổ.

soibac123bk said:

mình đang thấy tư tưởng của DDD và clean architecture không khác nhau nhiều lắm. Mình không phủ nhận những điểm mạnh của DDD hay clean architecture như khi triển khai thì rất tốn thời gian và không phù hợp với những project dạng startup

Click to expand...

làm DDD thì phải có 1 phòng nghiệp vụ, to ko kém phòng dev
làm clean architecture thì cũng cần mấy ông architect to đầu, và nhiều team

cơ bản là vậy, các dự án này rất phức tạp, đông người, nhân lực, thời gian với tiền ko là vấn đề

việc chốt DDD hay clean architecture nó diễn ra từ rất lâu, trước khi cả có requirement. có khi chỉ có CTO với CEO nói mồm với nhau ấy, mấy thằng to đầu cầm tiền này nó chốt hết

còn để đến lúc dev hoặc leader như fen kêu như vạc thì ngoài scope

soibac123bk said:

controller->service->repository
Từ bên ngoài giao tiếp với layer bên trong bác có dùng đến đến entity không bác hay chỉ dùng mỗi simple structure thôi, vì em thấy nếu không dùng thì có vẻ code khá là messy, ví dụ từ controller gọi vào service mà truyền cả một object thì khá khó cho người đọc code hiểu được trong object đó cần có những gì.

Click to expand...

controller vào service phải có struct riêng, vì thực tế service đó ko chỉ execute ở controller http, mà còn ở grpc, consumer, worker,command,… nên phải có struct riêng cho service, bọn nào muốn gọi phải tự parse về đúng struct đấy

đợi mấy ông solid clean xong thiên hạ nó đẻ trăm cái dự án lớn nhỏ, bớt bớt lại học vừa thôi lao vào làm đi

midnight_sun said:

controller vào service phải có struct riêng, vì thực tế service đó ko chỉ execute ở controller http, mà còn ở grpc, consumer, worker,command,… nên phải có struct riêng cho service, bọn nào muốn gọi phải tự parse về đúng struct đấy

Click to expand...

vì vậy nên mình thấy nếu chia layer là controller -> service -> repository lại phải đẻ thêm ra những thằng như thế nữa, rồi cuối cùng số lượng code nó đẻ cũng k thua gì apply clean architecture đâu bạn.

soibac123bk said:

vì vậy nên mình thấy nếu chia layer là controller -> service -> repository lại phải đẻ thêm ra những thằng như thế nữa, rồi cuối cùng số lượng code nó đẻ cũng k thua gì apply clean architecture đâu bạn.

Click to expand...

cái việc đấy là bắt buộc, clean arch thím sinh ra nhiều struct là để đúng khuôn, không cần thiết ,còn cái service kia bắt buộc phải làm như vậy, nếu không sao chạy đc, 2 cái đấy khác nhau, tất nhiên đang nói context là app có nhiều transport để trigger service , chứ còn có mỗi http thì cx chả cần, nhưng chỉ đang lấy ví dụ về mình dựa vào hệ thống trc, r ms adapt kiến trúc từ từ, chứ ko phải ngay từ đầu design 1 cục bự

hikaruu said:

đợi mấy ông solid clean xong thiên hạ nó đẻ trăm cái dự án lớn nhỏ, bớt bớt lại học vừa thôi lao vào làm đi

Click to expand...

Mvp thì làm láo nháo được, chứ kiếm ăn chạy xổi, đến lúc nhỡ may mắn, vào cầu, lượng user tăng đột biến, perf lởm, sv ngất lên ngất xuống. Hoặc tăng từ từ, biz nở ra, sửa chỗ nọ, vá víu chỗ kia. Bug lên bug xuống.