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

freedom.9 đã nói:

Thôi anh @rongthhieng2007 lo đi trang bị kiến thức chứ ko sau già rồi không làm freelancer, ko kiếm được việc fulltime thì khổ ra
Đi xin việc bị mấy thằng trẻ trẻ phỏng vấn vô nó hỏi solid thì lại khổ. Chứ tôi ở Mỹ rồi làm biếng vật nhau đọ tiền với anh quá, qua làm culi tư bản lo trả bill chết mẹ rồi

via theNEXTvoz for iPhone

Nhấp để mở rộng...

The_Hermit đã nói:

Lol mới hồi tháng 5 còn than ko có kinh nghiệm kiến thức, giờ tranh luận như người có 10 năm làm enterprise ấy nhể. Lại còn mấy cái clean code, architecture đã rành từ 4, 5 năm trước lol.
Đúng là Voz, lọai nào cũng có

Nhấp để mở rộng...

meekoo đã nói:

Tập trung vào thảo luận vấn đề đi, công kích cá nhân, ko vui đâu.

Ông rồng có thể cùn, nhưng ko có nghĩa là ổng nói gì cũng sai nhé.

Nhấp để mở rộng...

telbook đã nói:

Clean code chủ yếu là principle, convention đặt ra để code dễ đọc, hiểu, bảo trì
Clean Architecture thừa hưởng tư tưởng này nhưng để implement thì cũng có một số bất cập do over engineering có thể kể đến là:
- Chia tách quá nhiều lớp => Dẫn đến các quy định code quá nhiều, hướng dẫn dev dài như sớ, dev không biết vào đâu để sửa chức năng mong muốn. Code bị phức tạp hóa và không thực sử giải quyết vấn đề
- Quá phụ thuộc vào abstract, đôi khi abtract gây ra thay vì giải quyết vấn đề .
- Code không thực sự "clean". Code ở service cũng xấu như ở lớp controller, khác mỗi cái là bị abtract đi.
Quan trọng là tư tưởng clean code chứ đừng cứng nhắc, dập khuôn. Cá nhân tôi đang tìm hiểu thấy vertical slice architecture khá hay, trong mỗi slice cũng có thể làm onion/clean arch cũng đc tùy team.

Nhấp để mở rộng...

vertical slice architecture

Nhấp để mở rộng...

The_Hermit đã nói:

Ôi dào, các enterprise pattern có phải cái gì mới lạ, cao siêu đâu, ai nêu lên mấy cái đó cậu kia đều kêu là lý thuyết sáo rỗng, noob, sinh viên cả thì còn bàn luận gì?
Một số comment cho thấy cậu kia còn có thể ko phân biệt được UT, SIT, NFT các kiểu, chỉ được mỗi cái cùn.
Cái nữa, anh có thể tin lời mấy đứa xạo lol, còn tôi thì ko

Nhấp để mở rộng...

meekoo đã nói:

Tôi hiểu ý ông mà, chính bản thân tôi cũng đang làm y chang ông đây, cũng solo, cũng tự design, chả clean arch gì cả. Nhưng ở đời, cái gì tồn tại thì đều có lý do của nó.

Tôi được cái hay tò mò nên cũng muốn xem tại sao nó lại xuất hiện, tại sao tôi ko xài bao giờ, mà nhiều chỗ người ta vẫn xài, mấy anh trên này cũng nói là đang xài? Chắc phải có bí ẩn nào đó.
Nếu ông ko giúp tôi giải đáp được thì thôi vậy.

Nhấp để mở rộng...

soibac123bk đã nói:

bác ơi mình close thôi bác, tập trung để chia sẻ kiến thức thôi, từ hôm qua h tốn time cho những vẫn để đả kích cá nhân rồi. Bác đào nữa ông ấy lại ngoi lên mệt lắm.

Nhấp để mở rộng...

soibac123bk đã nói:

thank bác đã suggest cho em, em có tìm và đoc về

sau khi đọc tài liệu và xem video này

Em có một số câu hỏi sau muốn hỏi bác 1 tí về vertical slice architecture.
1. Em thấy vertical slice architecture sẽ gom những thứ liên quan với nhau về 1 unit, rồi trong đơn vị này thì lại có thể chia theo layers. Vậy để giải quyết được vấn đề dễ viết unittest thì em cảm thấy việc chia theo chiều dọc này không giải quyết được nó, mặc dù em thấy rằng việc chia theo chiều dọc như vậy sẽ làm code trở nên cohesive hơn.

2. Nếu có 2 entities trong business logic nó chỉ liên quan với nhau 1 tẹo thôi thì có thể gom nó về trong một unit không ạ? vì nếu để ra riêng thì em thấy sẽ phải import vòng quanh mà gom vào thì thấy không đáng lắm.

Mong bác trả lời giúp em với ạ.

Nhấp để mở rộng...

The_Hermit đã nói:

Ok sorry bác. Mình cũng góp ý rồi. Mấy cái bác nếu thì bất cứ layered arch nào cũng gặp. Hiện tại cá nhân mình follow vertical slice architecture.

Nhấp để mở rộng...

soibac123bk đã nói:

Em có một số câu hỏi sau muốn hỏi bác 1 tí về vertical slice architecture.
1. Em thấy vertical slice architecture sẽ gom những thứ liên quan với nhau về 1 unit, rồi trong đơn vị này thì lại có thể chia theo layers. Vậy để giải quyết được vấn đề dễ viết unittest thì em cảm thấy việc chia theo chiều dọc này không giải quyết được nó, mặc dù em thấy rằng việc chia theo chiều dọc như vậy sẽ làm code trở nên cohesive hơn.

2. Nếu có 2 entities trong business logic nó chỉ liên quan với nhau 1 tẹo thôi thì có thể gom nó về trong một unit không ạ? vì nếu để ra riêng thì em thấy sẽ phải import vòng quanh mà gom vào thì thấy không đáng lắm.

Mong bác trả lời giúp em với ạ.

Nhấp để mở rộng...

soibac123bk đã nói:

em cũng có 1 số câu hỏi về vertical slice architecture, nếu được bác giúp em với nhé.

Nhấp để mở rộng...

telbook đã nói:

Vertical slice architecture ý tưởng là chia hệ thống theo từng chức năng nghiệp vụ. Những thứ phải thay đổi cùng nhau ở gần nhau hơn.
Tôi thấy nó giống như chia hệ thống thành các microservice vậy, project dùng CQRS hay event-sourcing dùng kiến trúc này rất hợp. Tất nhiên monolith vẫn chia folder theo features được, cũng tiện sau tách microservice nếu cần scale up.

Về 2 câu hỏi thì tôi trả lời theo ý kiến của tôi như sau:

1. Slice giải quyết góc nhìn chứ không ảnh hưởng cách bác code. Chia tách hệ thống thành các thành phần riêng biệt là để chuyển đổi ngữ cảnh (context switching) dễ hơn. Về unit test cũng giống như khi bác code ở các architect khác thôi, mỗi slice gần như một project con riêng biệt. Tôi nghĩ test chức năng tổng thể của cả feature sẽ dễ hơn vì logic ở gần nhau.

2. Vậy phải hỏi, 2 entity đó có vai trò gì trong feature/chức năng này không? Feature A thay đổi dữ liệu có dẫn đến feature B bị lỗi không. Nếu liên quan nhiều, dẫn đến việc A B phải nói chuyện với nhau nhiều thì hoàn toàn có thể gộp lại thành 1. Cái này ở microservice gọi là Overly Chatty và là một dấu hiệu nhận biết nên hợp service lại

Nhấp để mở rộng...

• Tuổi và giới tính của user (User)
• Phụ thuộc vào platform user dó đang nhập, app_version hiện đang dùng (Device)
• Phụ thuộc vào subscription hiện tại của user đó (Subscription).

The_Hermit đã nói:

1. Bạn thích code ko layer, all-in-one cũng được. Vertical slice không phải là layered từng slice. Tuy nhiên bạn nên tự cân nhắc lại cons/pros. Thú thực mình thấy bạn complain về chuyện change 1 cái gì đó nó propagate qua các layer khác tốn công mình thấy nó hơi buồn cười, không rõ cái tốn công bạn nói nó ở mặt nào? Còn nếu change code đơn thuần thì với IDE xịn xò hiện tại chuyện refact quá đơn giản và nhanh.
2. Vertical slice ko phải là chia code theo entitiy. Bạn chia code theo feature

Nhấp để mở rộng...

soibac123bk đã nói:

Vì em thấy nếu chia theo feature, có những lúc nhiều feature dùng chung một số entities thì mình sẽ giải quyết thế nào ạ, ví dụ feature A dùng entities của featureB, còn featureB lai ngược lại dùng entities của featureA

Nhấp để mở rộng...

soibac123bk đã nói:

ý em không phải là nó propagate từ layer này qua layers khác mà là tính năng có sự thay đổi và mình phải thay đổi ở nhiều layers, khiến tốn thời gian switch qua lại.
Việc này khiến việc thêm requirement mới trở nên cồng kềnh và tốn thời gian hơn (cái này em hiểu là sự đánh đổi, đã áp dụng thì phải chấp nhận). Nhưng ý em là liệu có một architecture nào khác làm viêc này tốt hơn không.

Nhấp để mở rộng...

soibac123bk đã nói:

Em có xem qua vertical slice architecture, cũng rất hay nhưng em đang cảm thấy cách này apply để structure folder để dễ nhìn hơn. Chứ không có tác dụng nhiều về những mặt như reusibility, easy to maintain and extend, easy to write unittest.

Nhấp để mở rộng...

telbook đã nói:

Coupling thì share DB thôi, không nhất thiết DB phải riêng hoàn toàn. ShareDB thì khi thay đổi thiết kế DB thì phải sửa ở các slice luôn, và cẩn thận khi feature dẫm chân nhau

Cái này là điểm yếu của abtraction nói chung, nếu quá nhiều layer sẽ làm code phức tạp hơn cần thiết. sửa 1 cái khéo phải nhảy cả chục file.

Folder dễ nhìn, logic tập trung là maintain dễ hơn rồi. Vertical slice chỉ là cái khung, trong từng slice bác thích làm như nào thì làm xài layer như clean arch hoặc bỏ không xài abtract cũng được.
Extend thì slice tính năng mới sẽ không bị gò bó bởi tính năng cũ nên extend feature thì chỉ tạo folder theo template đã có là xong.
Về reusibility repo, entity hoàn toàn được nhưng có trade off là duplicate code để tránh coupling, hoặc reuse code thì sẽ có indirect coupling. Tôi nghĩ chỉ nên reuse chỉ khi phải dùng đến shared db.
Unit test thì không liên quan gì cái khung cả? Nó là do cách code cụ thể trong từng slice.

Nhấp để mở rộng...

soibac123bk đã nói:

ý em không phải là nó propagate từ layer này qua layers khác mà là tính năng có sự thay đổi và mình phải thay đổi ở nhiều layers, khiến tốn thời gian switch qua lại. Em ví dụ:
- có thêm requirement là yêu cầu hiện thị blog theo độ tuổi của user, trước đây mình cho phép hiển thị hết (cái này em giải sử thôi, nếu phi lý đừng gạch đá em.)

- như vậy thì em sẽ phải sử repository, sửa entity (là cái giúp service nói chuyện với repository), rồi phải thay đổi cả service nữa.

Việc này khiến việc thêm requirement mới trở nên cồng kềnh và tốn thời gian hơn (cái này em hiểu là sự đánh đổi, đã áp dụng thì phải chấp nhận). Nhưng ý em là liệu có một architecture nào khác làm viêc này tốt hơn không.

Em có xem qua vertical slice architecture, cũng rất hay nhưng em đang cảm thấy cách này apply để structure folder để dễ nhìn hơn. Chứ không có tác dụng nhiều về những mặt như reusibility, easy to maintain and extend, easy to write unittest.

Mong các bác chỉ giúp em với.

Nhấp để mở rộng...

soibac123bk đã nói:

Vì vậy mà vertical slice architecture nó k giải quyết được triệt để vấn đề mà clean architecture gây ra (có thể phải switch qua lại nhiều layers khi requirement có sự thay đổi), cách để giải quyết đó là không dùng clean architecture hoặc dùng nhưng giản lược đi (giảm số lượng layers xuống).

Nhấp để mở rộng...

telbook đã nói:

Điểm yếu là của abtract. Nguyên tắc là chỉ tạo abtract khi thực sự cần, chứ bác đẻ ra nhiều layer - abtract thì phải chấp nhận thôi, có pros cons cả mà?
Trong slice nếu vẫn dùng clean arch thì nó vẫn có abtract thôi. Nhưng nó giúp feature A cần thì abtract, feature B không cần thì không cần abtract làm gì. Giảm thiểu tối đa việc xuất hiện abtract rồi còn gì.

Nhấp để mở rộng...