telbook
Senior Member
1 slice hoàn toàn có thể dùng micro ORM hay full ORM hoặc dùng external API, sẽ có những đoạn code bị lặp nhưng bù lại sẽ có slice feature độc lập và ít phụ thuộc vào nhau thì tôi thấy cũg được
thảo luận Clean Architecture có thật sự giúp ta code tốt hơn?
- Thread starter soibac123bk
- Start date
dark_matter
Senior Member
Ah ok, mình quên mất có multi mapping. Cái này micro ORM hay full ORM đều được.
The_Hermit
Senior Member
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.
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
Đúng là Voz, lọai nào cũng có
Last edited:
meekoo
Senior Member
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é.
The_Hermit
Senior Member
Ô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ì?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é.
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
soibac123bk
Junior Member
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 ạ.
soibac123bk
Junior Member
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.
Love U So Much
Senior Member
Tôi có thể trả lời bạn, bid đc project là cto / chairman level, toàn thằng già 50 60 tuổi. Tầm đó ở cty tôi thì clean architect là tối thiểu
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.
The_Hermit
Senior Member
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.
soibac123bk
Junior Member
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é.
seastar
Member
1. Thực ra t thấy khái niệm "clean code" cũng khá là trừu tượng. Chả có một metric nào để có thể đo đạc chính xác đc là code này clean k, mức độ clean thế nào. Mà một khi không đo đạc được thì sẽ không thể kiểm soát hoàn toàn đc. Ngoài review thì k biết ở cty ae kiểm soát bằng cách nào?
2. Ngoài ra khi nhìn tổng quát mọi vấn đề t từng gặp thì hầu như nó đều bắt nguồn từ sự thay đổi nào đó. Để giải quyết thì ngta lại tạo ra một sự thay đổi rồi nó lại kéo theo vấn đề khác một cách trực tiếp hoặc gián tiếp,... Vậy nên hầu như tất cả principle, patterns cũng nhắm đến một mục đích cuối cùng là để code dễ thay đổi. Vậy nên trước khi làm gì hay review code của member thì t sẽ hỏi câu đơn giản đó. K cần phải đao to búa lớn làm gì.
3. Ngoài ra t cũng thấy nhiều ae bị over engineering. Kiểu thấy giải pháp nào đó hay hay rồi tìm cách áp dụng cho project của mình. Thực ra mọi thứ phải xuất phát từ vấn đề. Khi có vấn đề cụ thể mới đi tìm giải pháp.
2. Ngoài ra khi nhìn tổng quát mọi vấn đề t từng gặp thì hầu như nó đều bắt nguồn từ sự thay đổi nào đó. Để giải quyết thì ngta lại tạo ra một sự thay đổi rồi nó lại kéo theo vấn đề khác một cách trực tiếp hoặc gián tiếp,... Vậy nên hầu như tất cả principle, patterns cũng nhắm đến một mục đích cuối cùng là để code dễ thay đổi. Vậy nên trước khi làm gì hay review code của member thì t sẽ hỏi câu đơn giản đó. K cần phải đao to búa lớn làm gì.
3. Ngoài ra t cũng thấy nhiều ae bị over engineering. Kiểu thấy giải pháp nào đó hay hay rồi tìm cách áp dụng cho project của mình. Thực ra mọi thứ phải xuất phát từ vấn đề. Khi có vấn đề cụ thể mới đi tìm giải pháp.
naiveryan
Đã tốn tiền
rongthieng nói chẳng có gì sai đâu, chừng nào làm product dạng nặng về productivity và efficiency thì các bạn mới hiểu.
Đa phần các bác trong thread làm sản phẩm thiên về stablability, nên mới rảnh như vậy. Tôi mà đc làm việc với bạn rongthieng sẽ rất happy.
Còn sách vở của mấy ông bên hội Agile thì có áp dụng đc mấy đâu mà, đọc thì hay tính ứng dụng thì thấp.
Đa phần các bác trong thread làm sản phẩm thiên về stablability, nên mới rảnh như vậy. Tôi mà đc làm việc với bạn rongthieng sẽ rất happy.
Còn sách vở của mấy ông bên hội Agile thì có áp dụng đc mấy đâu mà, đọc thì hay tính ứng dụng thì thấp.
telbook
Senior Member
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.
Last edited:
The_Hermit
Senior Member
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
soibac123bk
Junior Member
Ở câu hỏi thứ 2 em có một có môt thắc mắc thế này, trong dư án của em đến 5-6 business entities liên quan với nhau ví du để hiển thị content cho người dùng (Content) nó sẽ phụ thuộc vào:
- 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).
Trong trường hợp này thì theo bác áp dụng vertical slide architecture còn ổn k ạ. 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
Last edited:
4nh7i3m
Senior Member
Ai làm dự án nhiều người cùng làm thì mới thấy Clean Architecture quan trọng cỡ nào. Càng làm nhiều, càng làm lâu thì sẽ thấy nó càng đúng.
Mà đã làm tới mức chuyên nghiệp như vậy thì tự nhiên sẽ không ngồi đôi co là có cần hay không cần nữa.
Tới giờ mà còn ngồi đôi co những cái đã thành chuẩn 20, 30 năm thì cũng phải nể độ chém gió mấy ông thật.
Mà đã làm tới mức chuyên nghiệp như vậy thì tự nhiên sẽ không ngồi đôi co là có cần hay không cần nữa.
Tới giờ mà còn ngồi đôi co những cái đã thành chuẩn 20, 30 năm thì cũng phải nể độ chém gió mấy ông thật.
soibac123bk
Junior Member
ý 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.
telbook
Senior Member
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.
soibac123bk
Junior Member
ý em là reusibility, và dễ viết unittest sẽ phụ thuộc các implement code trong từng slice đó bác. Vì vậy nên em đang nghĩ là clean architecture và vertical slice architecture là 2 cái không giống nhau lắm. Có thể sử dụng 1 cái hoặc cả 2 cùng lúc, nên k thể so sánh 2 cái đó với nhau. 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).
Note that: cái clean architecture mà ý em nói ở đây là tư tưởng chia nhiều layers khi implement code, và tuân thủ nguyên tắc từ layers ngoài có thể gọi trực tiếp layers trong, và từ layers muốn giao tiếp với layers ngoài phải thông qua interface. Chứ không cần phải chính xác cái được nhắc đến trong cuốn sách.
The_Hermit
Senior Member
Mình chịu, nếu ai biết thì sẵn giúp mình mở mang tầm mắt chứ mình chưa bao giờ thấy 1 cái solution nào gọi là one fit all
Similar threads
