Cám ơn bài viết hay, nhưng mình thấy lý thuyết hơn nhiều, chưa có ví dụ để làm rõ

Nin Tran

<html><body><h2 style="text-align:justify;">1. Kiến trúc N-Layer</h2>Chúng ta sẽ có các lớp logic và vật lý khác nhau đáp ứng cho các nhu cầu trong quá trình phát triển ứng dụng. Hầu hết các ứng dụng sử dụng kiến trúc này đều sẽ chứa 4 lớp: presentation, business, persistence và database. Tùy thuộc vào độ phức tạp của ứng dụng mà các lớp sẽ nhiều hoặc ít hơn.<figure class="image"><img src="https://api.careers.saigontechnology.com/storage/ck-editor/CKEDITOR-qMDyPoAWykT2Iwws5bsA5h2lA9Asp2r769b8hj8N.png"></figure><h6 style="text-align:justify;">Nguồn: <a href="https://www.oreilly.com/library/view/software-architecture-patterns/9781491971437/?_gl=1*7a1tjd*_ga*NzE5NTM3ODY4LjE2NzkzODcyOTk.*_ga_092EL089CH*MTY3OTYzMDAzNy42LjEuMTY3OTYzMDA1NS40Mi4wLjA.">Software Architecture Patterns by Mark Richards</a></h6>Các lớp trong mô hình kiến trúc này sẽ đảm nhiệm một vai trò cụ thể, và khi đứng từ một lớp nào đó, chúng ta chỉ có thể giao tiếp với các lớp bên trên hoặc bên dưới của nó. Trong đó:<ul><li style="text-align:justify;">Presentation: là lớp sẽ đảm nhiệm việc tương tác với người dùng, như là giao diện người dùng hoặc cung cấp thông tin dưới dạng Web API.</li><li style="text-align:justify;">Business: được xem như là thành phần chính trong các ứng dụng, là lớp sẽ chứa các logic nghiệp vụ, ánh xạ trực tiếp đến các nghiệp vụ thực tế mà ứng dụng cần đáp ứng.</li><li style="text-align:justify;">Persistence: là lớp truy xuất và lưu trữ dữ liệu bằng cách giao tiếp với lớp Database.</li><li style="text-align:justify;">Database: là nơi lưu trữ dữ liệu của ứng dụng, như là các cơ sở dữ liệu (SQL, No-SQL) hoặc File (Excel, CSV) ...</li></ul>Kiến trúc N-Layer có một số ưu điểm có thể kể đến đó là đơn giản, có thể tái sử dụng, kiểm thử độc lập, giúp cho lập trình viên có thể dễ tiếp cận và làm việc với các logic nghiệp vụ nhanh chóng. Vì vậy, chúng ta có thể sử dụng kiến trúc này cho các ứng dụng quy mô nhỏ hoặc thông thường.Tuy nhiên, đối với các ứng dụng quy mô lớn, tính mở rộng và phức tạp cao, thì kiến trúc sẽ hoạt động không hiệu quả. Do thiết kế phân lớp, việc thay đổi logic ở một lớp nào đó sẽ khó cập nhật lại ở các lớp khác, đồng thời cũng gây giảm hiệu suất vì các lớp không liền kề phải giao tiếp gián tiếp thông qua một lớp khác. Điều này làm cho ứng dụng sẽ ngày càng trở nên phức tạp và cồng kềnh hơn khi logic nghiệp vụ cũng nhiều hơn.<h2 style="text-align:justify;">2. Kiến trúc Onion</h2>Được giới thiệu lần đầu tiên bởi Jeffrey Palermo và năm 2008, để khắc phục các vấn đề kể trên của N-Layer, dựa trên mô hình Domain Driven, tức là xây dựng ứng dụng theo hướng tập trung vào Domain (nghiệp vụ). Từ cái tên "Onion", dịch ra là củ hành tây, ta có thể hiểu được ý đồ của mô hình này là đặt domain làm trung tâm, và bao bọc dần xung quanh bởi các lớp hệ thống khác.<figure class="image"><img src="https://api.careers.saigontechnology.com/storage/ck-editor/CKEDITOR-PLCfIJtUNLXs2P2w7dVtbBJaIFlEafSq30vXLWIj.png"></figure><h6 style="text-align:justify;">Nguồn: <a href="https://www.thoughtworks.com/insights/blog/architecture/demystify-software-architecture-patterns">Demystifying software architecture patterns</a></h6>Các lớp trong Onion được cải tiến dựa trên nguyên lý Dependency Inversion để giải quyết vấn đề phân lớp quá chặt chẽ của N-Layer. Đối với các lập trình viên .NET Core, việc cải tiến này được thể hiện thông qua Dependency Injection, được hỗ trợ sẵn, nhằm giảm tối đa sự phụ thuộc giữa các lớp, service với nhau.Thông thường, Onion sẽ có 4 lớp chính: domain model, domain services, application service và presentation. Như đã đề cập ở trên, Domain Model sẽ là lớp trung tâm của kiến trúc này. Trong đó:<ul><li style="text-align:justify;">Domain Model: là nơi tập trung các trạng thái và phương thức, hành vi nghiệp vụ của ứng dụng.</li><li style="text-align:justify;">Domain Services: là lớp kế tiếp domain model, chứa các interfaces cho việc lưu trữ dữ liệu, phương thức truy xuất, còn được gọi là Repository.</li><li style="text-align:justify;">Application Services: chứa các interfaces với các phương thức như là Thêm, xóa, sửa.. Ở các lớp services sẽ chỉ chứa các interfaces và các commons class.</li><li style="text-align:justify;">Presentation: chứa UI và tests. Lớp này cũng chứa các cài đặt của các interface ở tầng services.</li></ul>Một số ưu điểm của kiến trúc này:<ul><li style="text-align:justify;">Ít bị ràng buộc giữa các lớp với nhau</li><li style="text-align:justify;">Xây dựng tập trung vào nghiệp vụ</li><li style="text-align:justify;">Linh hoạt, dễ chuyển đổi, bổ sung và mở rộng</li><li style="text-align:justify;">Có thể đưa vào phát triển với mẫu DDD (Domain-Driven Design)</li></ul>Bên cạnh đó, một số nhược điểm dễ nhận thấy ở kiến trúc Onion này là:<ul><li style="text-align:justify;">Khó tiếp cận đối với những lập trình viên mới bắt đầu tham gia, đòi hỏi thời gian học và tìm hiểu sâu</li><li style="text-align:justify;">Phức tạp và khó áp dụng nếu ứng dụng không có nhiều nghiệp vụ</li></ul><h2 style="text-align:justify;">3. Kiến trúc Clean</h2>Kiến trúc Clean được giới thiệu bởi Uncle Bob vào năm 2012, dựa trên nguyên lý và thừa hưởng các đặc tính của kiến trúc Onion. Điểm khác biệt là kiến trúc này lấy Entities (các đối tượng nghiệp vụ) làm trung tâm.<figure class="image"><img src="https://api.careers.saigontechnology.com/storage/ck-editor/CKEDITOR-ddf3HUlqvDtDKQ9V9OIRe0gUVlbphOCyCuX7NF5U.png"></figure><h6 style="text-align:justify;">Nguồn: The Clean Code Blog by Robert C. Martin</h6>Các lớp trong kiến trúc clean sẽ được phân tách dựa trên các vai trò cụ thể:<ul><li style="text-align:justify;">Các entities sẽ là nơi chứa các logic nghiệp vụ chính (enterprise wide business), có thể là các đối tượng cùng phương thức, hành vi của nó, hoặc là tập hợp các cấu trúc dữ liệu (danh sách, node..) và các hàm. Các entities có thể được sử dụng ở nhiều nơi khác trong ứng dụng hoặc xuyên suốt quá trình xử lý nghiệp vụ. Các entities sẽ chỉ ràng buộc với chính nó.</li><li style="text-align:justify;">Bên ngoài sẽ là lớp chứa nghiệp vụ của ứng dụng - use cases (application specific business). Các thành phần trong lớp này sẽ chứa những cài đặt cho việc ứng dụng đó làm những gì (use cases). Những thay đổi ở lớp này sẽ không được tác động tới các entities, cũng như chính nó cũng sẽ không bị tác động bởi sự thay đổi của các thành phần khác (database, UI, thư viện...).</li><li style="text-align:justify;">Bao bọc các lớp nghiệp vụ sẽ là lớp thứ ba, chứa các interface adapters, dùng để khai báo interface chuyển đổi dữ liệu và thông tin được yêu câu giữa các lớp nghiệp vụ và các dịch bên ngoài, như là cơ sở dữ liệu, các frameworkss hay là API bên thứ ba.</li><li style="text-align:justify;">Lớp ngoài cùng sẽ chứa các frameworks và drivers, là các cái đặt cụ thể cho các interface adapters. Đây được xem là nơi chứa mọi chi tiết mà ở các lớp khác khai báo thông qua interfaces. Các frameworks và tools như là cơ sở dữ liệu, web framework, các thư viện bên thứ ba...</li></ul>Kiến trúc Clean vẫn đi theo nguyên lý của Onion: ràng buộc giữa các lớp nên là từ cấp thấp hơn sẽ phụ thuộc vào lớp cấp cao hơn thông qua các interfaces, có thể sử dụng Dependency Injection. Như vậy các logic xử lý chính sẽ không bị phụ thuộc vào các thay đổi đến từ lớp bên ngoài (frameworks and drivers). Ngoài ra, số lượng các lớp ở kiến trúc này cũng không cố định. Nó tùy thuộc vào ứng dụng cụ thể phức tạp ra sao, các yêu cầu nghiệp vụ như thế nào...Từ đó, ta có thể thấy một số ưu nhược điểm của kiến trúc này:<ul><li style="text-align:justify;">Ưu điểm:<ul><li style="text-align:justify;">Có thể sử dụng với mô hình microservices hay mẫu DDD</li><li style="text-align:justify;">Các lớp độc lập với nhau, các logic nghiệp vụ không bị phụ thuộc vào các lớp khác</li><li style="text-align:justify;">Dễ kiểm thử</li><li style="text-align:justify;">Dễ mở rộng, vì các lớp đã có vai trò riêng của nó</li></ul></li><li style="text-align:justify;">Nhược điểm:<ul><li style="text-align:justify;">Khó để học và hiểu các nghiệp vụ đã được chia tách thành các lớp</li><li style="text-align:justify;">Cấu trúc phức tạp vì cần phải triển khai qua nhiều lớp</li><li style="text-align:justify;">Do các lớp không phụ thuộc nhau nên sẽ khá trừu tượng</li></ul></li></ul><h2 style="text-align:justify;">4. Vậy kiến trúc Onion và Clean có giống nhau?</h2>Tuy kiến trúc Clean ra đời có nhiều ảnh hưởng từ Onion, giữa 2 kiến trúc vẫn có những điểm giống và khác nhau.Cả hai kiến trúc đều hướng tới việc chia ứng dụng thành nhiều lớp xử lý với các vai trò khác nhau, giúp cho việc xây dựng và triển khai dự án dễ dàng hơn. Cả hai kiến trúc đều áp dụng nguyên lý Dependency Inversion giữa các lớp, giúp cho sự ràng buộc giữa các lớp giảm bớt, các lớp cấp thấp hơn sẽ phụ thuộc lớp cấp cao hơn thông qua abstractions chứ không phải là trực tiếp. Ngoài ra các ứng dụng xây dựng trên 2 kiến trúc này sẽ có khả năng mở rộng cao và có thể được kiểm thử độc lập cho từng lớp.Những điiểm khác nhau giữa hai kiến trúc:<ul><li style="text-align:justify;">Kiến trúc Onion<ul><li style="text-align:justify;">Tập trung vào xử lý nghiệp vụ và đưa nó vào trung tâm</li><li style="text-align:justify;">Các lớp được chia theo vai trò chung (domain, repositories, services..), chủ yếu để phục vụ cho lớp domain trung tâm</li><li style="text-align:justify;">Các xử lý liên quan đến kỹ thuật, công nghệ được đưa các xử lý ra các lớp bên ngoài</li></ul></li><li style="text-align:justify;">Kiến trúc Clean:<ul><li style="text-align:justify;">Chia việc xử lý nghiệp vụ thành 2 lớp: enitities (enterprise wide business) và use cases (application specific business)</li><li style="text-align:justify;">Các lớp được chia theo vai trò cụ thể (entities, interface adapters, frameworks and drivers..)</li><li style="text-align:justify;">Sử dụng dependency inversion để phân tách các xử lý rồi mới đưa ra bên ngoài</li></ul></li></ul><h2 style="text-align:justify;">5. Vậy ta nên sử dụng kiến trúc nào?</h2>Các ứng dụng khác nhau sẽ có khối nghiệp vụ và độ phức tạp khác nhau. Cho nên, tùy vào mỗi ứng dụng và các yêu cầu chức năng của nó mà ta sẽ chọn kiến trúc cho phù hợp.Một số gợi ý khi chọn kiến trúc Onion:<ul><li style="text-align:justify;">Thường dành cho mô hình nghiệp vụ của ứng dụng tương đối phức tạp, yêu cầu khá nhiều về tính nhất quán cũng như nhiều tính toán chặt chẽ.</li><li style="text-align:justify;">Các công nghệ, thư viện sử dụng ở các lớp services có thể linh động</li></ul>Chúng ta sẽ cân nhắc chọn kiến trúc Clean khi:<ul><li style="text-align:justify;">Mô hình nghiệp vụ không quá phức tạp, có thể chứa trong các đối tượng truyền dữ liệu cùng các hành vi và phương thức</li><li style="text-align:justify;">Các công nghệ, thư viên sử dụng ở các lớp services có tính phổ biến, cung cấp nhiều tính năng cho hệ thống</li></ul><h2 style="text-align:justify;">6. Kết luận</h2>Onion và Clean đều là những kiến trúc rất hay, hướng ứng dụng tới việc xử lý những khía cạnh của nghiệp vụ, đưa các thư viện, dịch vụ khác ra các lớp bên ngoài. Những ứng dụng này sẽ có khả năng linh động cao, mở rộng tốt, và có tính bảo trì. Có thể nói, 2 kiến trúc này có thể sử dụng để xây dựng bất kỳ loại ứng dụng nào. Và các lập trình viên sẽ cần phải lựa chọn loại kiến trúc phù hợp với nhu cầu, sự phát triển của dự án, ứng dụng.Tài liệu tham khảo<ol><li style="text-align:justify;"><a href="https://www.oreilly.com/library/view/software-architecture-patterns/9781491971437/?_gl=1*7a1tjd*_ga*NzE5NTM3ODY4LjE2NzkzODcyOTk.*_ga_092EL089CH*MTY3OTYzMDAzNy42LjEuMTY3OTYzMDA1NS40Mi4wLjA.">Software Architecture Patterns by Mark Richards</a></li><li style="text-align:justify;"><a href="https://www.oreilly.com/library/view/clean-architecture-a/9780134494272/">Clean Architecture: A Craftsman’s Guide to Software Structure and Design</a></li><li style="text-align:justify;"><a href="https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html">The Clean code blog - Clean Architecture (Uncle Bob)</a></li><li style="text-align:justify;"><a href="https://jeffreypalermo.com/2008/07/the-onion-architecture-part-1/">The Onion Architecture - Jeffrey Palermo</a></li></ol></body></html>

Mô hình kiến trúc N-layer đã khá phổ biến trong phát triển phần mềm, nhưng nó vẫn có khá nhiều điểm yếu. Từ đó, nhiều kiến trúc khác đã ra đời để giúp việc phát triển được tốt hơn. Trong bài viết này, chúng ta sẽ tìm hiểu 2 mô hình được sử dụng rộng rãi là Onion và Clean.

&lt;html&gt;&lt;body&gt;&lt;h2&gt;1. Design Patterns l&agrave; g&igrave; nhỉ?&nbsp;&lt;/h2&gt;&lt;p style=&quot;text-align:justify;&quot;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Tổng quan th&igrave; Design Patterns như một c&ocirc;ng thức để ta c&oacute; thể &aacute;p dụng v&agrave;o giải quyết một số vấn đề cụ thể trong lập tr&igrave;nh, cụ thể l&agrave; Lập tr&igrave;nh hướng đối tượng (OOP). N&oacute; l&agrave; những giải ph&aacute;p đ&atilde; được đ&uacute;c kết v&agrave; tối ưu h&oacute;a cho c&aacute;c trường hợp cụ thể. Thay v&igrave; phải t&igrave;m c&aacute;ch tối ưu h&oacute;a, tổ chức code lại từ đầu, th&igrave; bạn đơn giản c&oacute; thể &aacute;p dụng c&aacute;c Design Patterns ph&ugrave; hợp v&agrave; đ&atilde; được tối ưu cho trường hợp bạn gặp phải. Từ định nghĩa đ&oacute; ta c&oacute; thể thấy được một số t&igrave;nh huống m&agrave; Design Patterns c&oacute; thể ph&aacute;t huy sức mạnh tối đa của n&oacute;:&lt;/p&gt;&lt;ul&gt;&lt;li style=&quot;text-align:justify;&quot;&gt;Bạn gặp một t&igrave;nh huống phức tạp khi lập tr&igrave;nh. Đừng lo, khả năng cao đ&atilde; c&oacute; một (hoặc c&oacute; thể l&agrave; một v&agrave;i) Design Patterns c&oacute; thể giải quyết vấn đề của bạn thật đơn giản v&agrave; gọn g&agrave;ng. Chỉ cần &aacute;p dụng theo l&agrave; xong.&lt;/li&gt;&lt;li style=&quot;text-align:justify;&quot;&gt;Bạn trao đổi với c&aacute;c developer kh&aacute;c trong team về c&aacute;ch tổ chức source code của một hệ thống kh&aacute; lớn v&agrave; phức tạp. Bạn (v&agrave; team của bạn) cảm thấy kh&oacute; khăn khi tr&igrave;nh b&agrave;y &yacute; tưởng của m&igrave;nh. H&atilde;y sử dụng Design Patterns như một ng&ocirc;n ngữ chung để n&oacute;i về những &yacute; tưởng phức tạp một c&aacute;ch đơn giản. (Giả sử thay v&igrave; n&oacute;i rằng &ldquo;Ta c&oacute; thể tạo một Abstract Class để tập trung c&aacute;c xử l&yacute; tạo c&aacute;c Instance của class Hotel để dễ d&agrave;ng che giấu việc khai b&aacute;o c&aacute;c Instance con li&ecirc;n quan đến Hotel đồng thời c&oacute; thể dễ d&agrave;ng tạo nhiều Instance của Hotel mootj c&aacute;ch dễ d&agrave;ng v&agrave; tường minh&rdquo; th&igrave; ta c&oacute; thể n&oacute;i l&agrave; &ldquo;Ta c&oacute; thể &aacute;p dụng Abstract Factory Design Patterns cho class Hotel&rdquo; thế th&ocirc;i!)&lt;/li&gt;&lt;/ul&gt;&lt;h2&gt;2. Những điểm mạnh của Design Patterns&lt;/h2&gt;&lt;p style=&quot;text-align:justify;&quot;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Việc nắm bắt v&agrave; &aacute;p dụng Design Patterns v&agrave;o trong c&ocirc;ng việc của một Developer thực sự sẽ gi&uacute;p ta c&oacute; một bước ph&aacute;t triển ho&agrave;n to&agrave;n mới về cả tư duy lẫn kỹ năng lập tr&igrave;nh. Bạn c&oacute; thể thấy r&otilde; điều đ&oacute; qua những điểm mạnh của n&oacute; sau đ&acirc;y:&nbsp;&lt;/p&gt;&lt;ul&gt;&lt;li style=&quot;text-align:justify;&quot;&gt;Gi&uacute;p bạn tăng tốc độ ph&aacute;t triển c&aacute;c ứng dụng.&nbsp;&lt;/li&gt;&lt;li style=&quot;text-align:justify;&quot;&gt;Cải thiện code structure, dễ d&agrave;ng n&acirc;ng cấp v&agrave; sửa đổi.&lt;/li&gt;&lt;li style=&quot;text-align:justify;&quot;&gt;Tăng khả năng code reusability.&lt;/li&gt;&lt;li style=&quot;text-align:justify;&quot;&gt;Tăng t&iacute;nh readable đối với những cấu tr&uacute;c code phức tạp. Tăng khả năng communicate giữa c&aacute;c th&agrave;nh vi&ecirc;n trong team (Nếu mọi người đều biết về Design Patterns)&lt;/li&gt;&lt;li style=&quot;text-align:justify;&quot;&gt;Do c&aacute;c Design Patterns đ&atilde; được tối ưu n&ecirc;n ta cũng c&oacute; thể tr&aacute;nh được những lỗi kh&ocirc;ng mong muốn ph&aacute;t sinh trong qu&aacute; tr&igrave;nh Implementation.&lt;/li&gt;&lt;/ul&gt;&lt;h2&gt;3. Những hạn chế của Design Patterns&lt;/h2&gt;&lt;ul&gt;&lt;li style=&quot;text-align:justify;&quot;&gt;Design Patterns kh&ocirc;ng phải l&agrave; ch&igrave;a kh&oacute;a vạn năng, n&oacute; chỉ c&oacute; thể giải quyết được một số những vấn đề nhất định. Nếu ta sử &aacute;p dụng Design Patterns v&agrave;o những trường hợp kh&ocirc;ng ph&ugrave; hợp c&oacute; thể l&agrave;m code trở n&ecirc;n rối v&agrave; phức tạp hơn.&lt;/li&gt;&lt;li style=&quot;text-align:justify;&quot;&gt;Design Patterns chỉ l&agrave;m cho code dễ đọc dễ hiểu với những người c&oacute; kinh nghiệm về Design Patterns đang được &aacute;p dụng. Tuy nhi&ecirc;n đối với những người mới c&oacute; thể sẽ gặp kh&oacute; khăn trong việc nắm bắt cấu tr&uacute;c v&agrave; kh&oacute; khăn trong việc debug.&lt;/li&gt;&lt;li style=&quot;text-align:justify;&quot;&gt;Bản th&acirc;n từng Design Patterns cũng c&oacute; những khuyết điểm của ri&ecirc;ng n&oacute; (ta sẽ khảo s&aacute;t cụ thể khi đi v&agrave;o chi tiết từng Pattern). N&ecirc;n khi &aacute;p dụng Design Patterns n&agrave;o ta lu&ocirc;n phải c&acirc;n nhắc kỹ lưỡng những lợi &iacute;ch v&agrave; khuyết điểm của n&oacute; để đưa ra quyết định c&oacute; n&ecirc;n sử dụng hay kh&ocirc;ng.&lt;/li&gt;&lt;/ul&gt;&lt;h2&gt;4. Ph&acirc;n loại c&aacute;c Design Patterns:&lt;/h2&gt;&lt;ul&gt;&lt;li style=&quot;text-align:justify;&quot;&gt;Nh&oacute;m Creational: Nh&oacute;m Creational l&agrave; nh&oacute;m những Design Patterns tập trung c&aacute;c giải ph&aacute;p khởi tạo đối tượng v&agrave; che giấu logic khởi tạo những đối tượng:&lt;ul&gt;&lt;li style=&quot;text-align:justify;&quot;&gt;&lt;i&gt;Nh&oacute;m Creational bao gồm: Factory Method,&nbsp;Abstract Factory, Builder, Prototype, Singleton&lt;/i&gt;&lt;/li&gt;&lt;/ul&gt;&lt;/li&gt;&lt;li style=&quot;text-align:justify;&quot;&gt;Nh&oacute;m Structural: Nh&oacute;m Structural l&agrave; nh&oacute;m những Design Patterns tập trung v&agrave;o việc tối ưu c&aacute;c thiết kế của class v&agrave; sự kết hợp c&aacute;c class v&agrave; object trở lại một cấu tr&uacute;c lớn hơn.&lt;ul&gt;&lt;li style=&quot;text-align:justify;&quot;&gt;&lt;i&gt;Nh&oacute;m Structural bao&nbsp;gồm:&nbsp;Adapter, Bridge, Composite, Decorator, Facade, Flyweight v&agrave;&nbsp;Proxy&lt;/i&gt;&lt;/li&gt;&lt;/ul&gt;&lt;/li&gt;&lt;li style=&quot;text-align:justify;&quot;&gt;Nh&oacute;m Behavioral: Nh&oacute;m Behaviour l&agrave; nh&oacute;m những Design Patterns tập trung sự ph&acirc;n chia tr&aacute;ch nhiệm của c&aacute;c class v&agrave; object để phục vụ một mục đ&iacute;ch cụ thể. Nh&oacute;m n&agrave;y tập trung nhiều hơn v&agrave;o mối quan hệ giữa c&aacute;c class v&agrave; object với nhau.&lt;ul&gt;&lt;li style=&quot;text-align:justify;&quot;&gt;&lt;i&gt;Nh&oacute;m Behavioral bao gồm:&nbsp;Interpreter, Template Method, Chain of Responsibility, Command, Iterator, Mediator, Memento, Observer, State, Strategy v&agrave; Visitor&lt;/i&gt;&nbsp;&lt;/li&gt;&lt;/ul&gt;&lt;/li&gt;&lt;/ul&gt;&lt;h2&gt;5. Cần chuẩn bị những g&igrave; trước khi t&igrave;m hiểu về Design Patterns?&lt;/h2&gt;&lt;ul&gt;&lt;li style=&quot;text-align:justify;&quot;&gt;OOP: Tất nhi&ecirc;n rồi, bạn phải nắm t&iacute;nh vũng tư duy lập tr&igrave;nh theo hướng đối tượng đ&atilde;. C&aacute;c Design Patterns đơn giản l&agrave; gi&uacute;p bạn triển khai c&aacute;c t&iacute;nh chất của OOP dễ d&agrave;ng v&agrave; linh hoạt hơn m&agrave; th&ocirc;i.&lt;/li&gt;&lt;li style=&quot;text-align:justify;&quot;&gt;C&aacute;ch đọc sơ đồ UML:&nbsp; C&aacute;c Design Pattern thường được thể hiện dưới dạng UML diagram, việc đọc hiểu một số concept UML cơ bản l&agrave; cần thiết để bắt đầu học Design Patterns&nbsp;&lt;/li&gt;&lt;li style=&quot;text-align:justify;&quot;&gt;C&aacute;c bạn c&oacute; thể tham khảo tại đ&acirc;y:&nbsp;&lt;a href=&quot;https://www.guru99.com/uml-diagrams.html&quot;&gt;&lt;i&gt;&lt;u&gt;https://www.guru99.com/uml-diagrams.html&lt;/u&gt;&lt;/i&gt;&lt;/a&gt;&lt;/li&gt;&lt;li style=&quot;text-align:justify;&quot;&gt;Dưới đ&acirc;y l&agrave; 1 số concept UML cơ bản m&igrave;nh sẽ sử dụng trong loạt b&agrave;i viết n&agrave;y:&nbsp;&lt;/li&gt;&lt;/ul&gt;&lt;p&gt;&nbsp;&lt;/p&gt;&lt;p&gt;&lt;img src=&quot;https://api.careers.saigontechnology.com/storage/ck-editor/CKEDITOR-Cn1yI9X33XdJ5N3xgCYsyzvq0ix1YjSsqI6bTqLf.png&quot; alt=&quot;A picture containing diagram
        Description automatically generated&quot;&gt;&lt;/p&gt;&lt;p&gt;&lt;img src=&quot;https://api.careers.saigontechnology.com/storage/ck-editor/CKEDITOR-CpD296nUoYXW0lMySCd5csSytIINBYEQV7eQ1CdD.png&quot; alt=&quot;Diagram
        Description automatically generated&quot;&gt;&lt;/p&gt;&lt;p&gt;&nbsp;&lt;/p&gt;&lt;ul&gt;&lt;li&gt;Ngo&agrave;i ra hiểu được 2 quy tắc thiết kế &ldquo;&lt;i&gt;program to interfaces, not implementations&rdquo;&nbsp;&lt;/i&gt;v&agrave; &ldquo;&lt;i&gt;favor composition over inheritance&rdquo;&nbsp;&lt;/i&gt;cũng kh&aacute; quan trọng. Hầu hết c&aacute;c Design Patterns đề được thiết kế dựa tr&ecirc;n 2 quy tắc n&agrave;y.&lt;/li&gt;&lt;/ul&gt;&lt;h2&gt;6. Lời Kết&lt;/h2&gt;&lt;p style=&quot;text-align:justify;&quot;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;T&oacute;m lại th&igrave;: Design Patterns l&agrave; những mẫu thiết kế để giải quyết những vấn đề phổ biến hay gặp phải trong lập tr&igrave;nh, đ&atilde; được chấp nhận v&agrave; sử dụng rộng r&atilde;i của nhiều lập tr&igrave;nh vi&ecirc;n c&oacute; kinh nghiệm.&lt;/p&gt;&lt;p style=&quot;text-align:justify;&quot;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&Aacute;p dụng Design Patterns gi&uacute;p bạn cải thiện đ&aacute;ng kể tốc độ ph&aacute;t triển ứng dụng v&agrave; dễ d&agrave;ng hơn trong việc bảo tr&igrave;, sửa chữa.&lt;/p&gt;&lt;p style=&quot;text-align:justify;&quot;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Tuy nhi&ecirc;n, bạn cũng cần phải c&acirc;n nhắc kỹ lưỡng t&iacute;nh chất của b&agrave;i to&aacute;n cần giải quyết, quy m&ocirc; dự &aacute;n đang triển khai cũng như những th&agrave;nh vi&ecirc;n trong team của bạn trước khi cố gắng &aacute;p dụng bất k&igrave; Design Patterns n&agrave;o v&agrave;o code của dự &aacute;n.&lt;/p&gt;&lt;p style=&quot;text-align:justify;&quot;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Cuối c&ugrave;ng, Design Patterns sinh ra nhằm mục đ&iacute;ch đơn giản h&oacute;a qu&aacute; tr&igrave;nh ph&aacute;t triển ứng dụng, chứ kh&ocirc;ng phải l&agrave;m cho n&oacute; phức tạp l&ecirc;n. Nhớ điều n&agrave;y nh&eacute;!&lt;/p&gt;&lt;p&gt;&nbsp;&lt;/p&gt;&lt;p&gt;&lt;strong&gt;References:&nbsp;&lt;/strong&gt;&lt;/p&gt;&lt;p&gt;&lt;a href=&quot;https://refactoring.guru/design-patterns&quot;&gt;&lt;u&gt;Design Patterns&lt;/u&gt;&lt;/a&gt;&lt;/p&gt;&lt;p&gt;&lt;a href=&quot;https://www.digitalocean.com/community/tutorials/gangs-of-four-gof-design-patterns&quot;&gt;&lt;u&gt;Gangs of Four (GoF) Design Patterns | DigitalOcean&lt;/u&gt;&lt;/a&gt;&lt;/p&gt;&lt;p&gt;Books:&nbsp;&lt;a href=&quot;https://books.google.com.vn/books/about/Head_First_Design_Patterns.html?id=GGpXN9SMELMC&amp;amp;redir_esc=y&quot;&gt;&lt;u&gt;Head First Design Patterns&lt;/u&gt;&lt;/a&gt;&lt;/p&gt;&lt;/body&gt;&lt;/html&gt;

Design Patterns là một trong những công cụ hữu hiệu nhất để giải quyết các bài toán bạn gặp phải trong khi lập trình. Trong bài viết này mình sẽ chia sẻ cho các bạn khái niệm tổng quan về Design Patterns. Ở những bài viết sau ta sẽ đi sâu vào từng Design Patterns để có thể hiểu sâu hơn về nó.

Giới thiệu tổng quan về Design Patterns

So sánh Onion Architecture và Clean Architecture

Bài viết này mình tập trung chủ yếu vào các nguyên lý của SOLID.  Nhằm hướng dẫn cho anh em lập trình viên nhà mình có một cái nhìn tổng quan về SOLID chẳng hạn như: SOLID là gì? Lợi hại của SOLID? Hy vọng có thể support được mọi người có thêm kiến thức về các nguyên lý thiết kế code.

[Design Pattern] Bài 01: SOLID Trong Thiết Kế Hướng Đối Tượng

Bài viết nằm trong chuỗi bài về design pattern. Mở đầu của serie này là một design pattern khá quen thuộc và thân thương đó chính là Singleton. Vậy Singleton là gì, làm sao để implement một Singleton...
Qua bài viết hy vọng có thể support được mọi người có thêm kiến thức về Singleton.
OK Let’s Go.

[Design Pattern] Bài 03: Sử Dụng Singleton Trong Java

Bài viết nằm trong chuỗi bài về design pattern. Là phần tiếp theo của series design pattern, Factory một design pattern cực kỳ hữu dụng trong việc tạo ra object. Vậy Factory là gì, làm sao để implement một Factory. Qua bài viết hy vọng có thể support được mọi người có thêm kiến thức về Factory.

[Design Pattern] Bài 04: Sử Dụng Factory Trong Java

Bài viết nằm trong chuỗi bài về design pattern. Là phần tiếp theo của Creational pattern, Builder một design pattern cực kỳ hữu dụng trong việc tạo ra object. Vậy Builder là gì, làm sao để implement một Builder. Qua bài viết hy vọng có thể support được mọi người có thêm kiến thức về Builder.

[Design Pattern] Bài 05: Sử Dụng Builder Trong Java

&lt;html&gt;&lt;body&gt;&lt;h2&gt;&lt;span style=&quot;color:hsl(0,0%,0%);&quot;&gt;&lt;strong&gt;1. Prototype Design Pattern L&agrave; G&igrave;&lt;/strong&gt;&lt;/span&gt;&lt;/h2&gt;&lt;p style=&quot;text-align:justify;&quot;&gt;Để đi v&agrave;o chi tiết c&aacute;c thức hoạt động cũng như t&iacute;nh chất của&nbsp;&lt;strong&gt;Prototype&lt;/strong&gt; pattern m&igrave;nh xin ph&eacute;p lấy một v&iacute; dụ về việc tạo ra c&aacute;c loại thẻ ng&acirc;n h&agrave;ng.&lt;/p&gt;&lt;p style=&quot;text-align:justify;&quot;&gt;X&atilde; hội ng&agrave;y c&agrave;ng ph&aacute;t triển v&agrave; việc kh&ocirc;ng d&ugrave;ng tiền mặt ở c&aacute;c đ&ocirc; thị lớn đang l&agrave; xu thế. Gần như mọi người đều c&oacute; ri&ecirc;ng cho m&igrave;nh &iacute;t nhất một t&agrave;i khoản ng&acirc;n h&agrave;ng. B&ecirc;n cạnh đ&oacute; c&aacute;c c&ocirc;ng việc giao dịch về tiền tệ đều được thực hiện dễ d&agrave;ng th&ocirc;ng qua thẻ ATM.&lt;/p&gt;&lt;p style=&quot;text-align:justify;&quot;&gt;C&oacute; rất nhiều loại thẻ ATM như Master, Visa&hellip;B&ecirc;n cạnh đ&oacute;, mỗi ng&acirc;n h&agrave;ng c&ograve;n ph&aacute;t h&agrave;nh h&agrave;ng loạt c&aacute;c loại thẻ kh&aacute;c nhau cho từng nh&oacute;m kh&aacute;ch h&agrave;ng như thẻ VIP, thẻ CashBack... Về mặt physical th&igrave; c&aacute;c thẻ ATM n&agrave;y c&ugrave;ng chất liệu, c&ugrave;ng k&iacute;ch thước, c&ugrave;ng h&igrave;nh dạng v&agrave; chứa nhiều th&ocirc;ng tin chung, dĩ nhi&ecirc;n mỗi loại thẻ vẫn c&oacute; nhiều th&ocirc;ng tin kh&aacute;c biệt như m&agrave;u sắc, background số CVV&hellip;v&acirc;ng v&acirc;ng v&agrave; m&acirc;y m&acirc;y.&lt;/p&gt;&lt;p style=&quot;text-align:justify;&quot;&gt;Một topic nho nhỏ cho anh em dev l&agrave; l&agrave;m thế n&agrave;o c&oacute; thể tạo ra được những loại thẻ ATM một c&aacute;ch tiện lợi m&agrave; kh&ocirc;ng mất qu&aacute; nhiều effort. C&oacute; rất nhiều giải ph&aacute;p, một trong những giải ph&aacute;p m&igrave;nh c&oacute; thể consider đ&oacute; l&agrave;&nbsp;&lt;strong&gt;Builder&lt;/strong&gt; pattern. Tuy nhi&ecirc;n, với việc tạo ra một object c&oacute; nhiều tham số v&agrave; logic phức tạp (parameters) th&igrave; c&oacute; vẻ&nbsp;&lt;strong&gt;Builder&lt;/strong&gt; kh&ocirc;ng phải l&agrave; sự lựa chọn hợp l&yacute;. Với m&igrave;nh, c&aacute;i g&igrave; l&agrave;m nhiều th&igrave; m&igrave;nh chọn giải ph&aacute;p l&agrave; sao ch&eacute;p thay v&igrave; m&igrave;nh phải l&agrave;m bằng &ldquo;cơm&rdquo;.&lt;/p&gt;&lt;p style=&quot;text-align:justify;&quot;&gt;Do đ&oacute;,&nbsp; m&igrave;nh tận dụng một trong những skill-set đỉnh ch&oacute;p của anh em lập tr&igrave;nh đ&oacute; l&agrave; copy-paste v&agrave;&nbsp;&lt;strong&gt;Prototype&lt;/strong&gt; sẽ gi&uacute;p m&igrave;nh ph&aacute;t huy tối đa c&ocirc;ng dụng của việc tạo object bằng việc&nbsp;&lt;strong&gt;clone&lt;/strong&gt; từ một mẫu c&oacute; sẵn. V&agrave; sau đ&oacute; m&igrave;nh c&oacute; thể modify theo c&aacute;ch m&igrave;nh mong muốn dựa tr&ecirc;n từng context cụ thể.&lt;/p&gt;&lt;p style=&quot;text-align:justify;&quot;&gt;Đến đ&acirc;y, m&igrave;nh tin anh em cũng đ&atilde; hiểu mục đ&iacute;ch sử dụng của pattern n&agrave;y rồi. Tiếp theo m&igrave;nh sẽ giới thiệu với anh em về c&aacute;ch thiết kế cũng như c&aacute;ch để implement pattern n&agrave;y.&nbsp;&nbsp;&lt;br&gt;Đầu ti&ecirc;n m&igrave;nh c&ugrave;ng nhau tham khảo qua class diagram của&nbsp;&lt;strong&gt;Prototype&lt;/strong&gt; để c&oacute; c&aacute;i nh&igrave;n tổng quan về em n&oacute;.&lt;/p&gt;&lt;h2&gt;&lt;span style=&quot;color:hsl(0,0%,0%);&quot;&gt;&lt;strong&gt;2. Prototype Design Pattern Diagram&lt;/strong&gt;&lt;/span&gt;&lt;/h2&gt;&lt;figure class=&quot;image&quot;&gt;&lt;img src=&quot;https://api.careers.saigontechnology.com/storage/ck-editor/prototype-design-pattern-1-3UWckMfOTe6LSnFefvA7g8cug7j5agBbvYU2xZAl.webp&quot;&gt;&lt;/figure&gt;&lt;p&gt;Trong lược đồ ph&iacute;a tr&ecirc;n, th&agrave;nh phần ch&iacute;nh l&agrave; ba class:&nbsp;&lt;strong&gt;Client, Prototype v&agrave; SubPrototype&lt;/strong&gt;&lt;/p&gt;&lt;p&gt;&lt;strong&gt;Class Client&lt;/strong&gt;: Đại diện cho class sử dụng&nbsp;&lt;strong&gt;Prototype&lt;/strong&gt; object để clone ra c&aacute;c SubPrototype&lt;/p&gt;&lt;p&gt;&lt;strong&gt;Class Prototype&lt;/strong&gt;: Interface/Abstract class chứa abstract clone() method&lt;/p&gt;&lt;p&gt;&lt;strong&gt;Class Sub-Prototype&lt;/strong&gt;: Đại diện cho c&aacute;c class con m&agrave; ch&uacute;ng m&igrave;nh sẽ implement clone() ở c&aacute;c sub-class n&agrave;y.&lt;/p&gt;&lt;h2&gt;&lt;span style=&quot;color:hsl(0,0%,0%);&quot;&gt;&lt;strong&gt;3. Prototype Pattern Implementation&lt;/strong&gt;&lt;/span&gt;&lt;/h2&gt;&lt;p style=&quot;text-align:justify;&quot;&gt;Anh em m&igrave;nh đ&atilde; xem qua class diagram. Giờ m&igrave;nh c&ugrave;ng&nbsp; nhau đi chi tiết về c&aacute;ch implement pattern n&agrave;y th&ocirc;ng qua b&agrave;i to&aacute;n tạo ra c&aacute;c loại bank card.&lt;/p&gt;&lt;p style=&quot;text-align:justify;&quot;&gt;Context l&agrave; m&igrave;nh sẽ sử dụng class&nbsp;&lt;strong&gt;BankCard&lt;/strong&gt; để tạo ra c&aacute;c loại card như&nbsp;&lt;strong&gt;PlatinumCard&lt;/strong&gt; v&agrave;&nbsp;&lt;strong&gt;DiamondCard&lt;/strong&gt; hai loại thẻ d&agrave;nh cho hai tập kh&aacute;ch h&agrave;ng của một ng&acirc;n h&agrave;ng, bằng c&aacute;ch sử dụng&nbsp;&lt;strong&gt;Prototype&lt;/strong&gt; pattern.&lt;/p&gt;&lt;p style=&quot;text-align:justify;&quot;&gt;Đầu ti&ecirc;n m&igrave;nh tạo ra một class&nbsp;&lt;strong&gt;BankCard&lt;/strong&gt;, class n&agrave;y đại diện cho c&aacute;c loại&nbsp;&lt;strong&gt;BankCard&lt;/strong&gt; (Visa, Master&hellip;). Class n&agrave;y chứa c&aacute;c thuộc t&iacute;nh th&ocirc;ng dụng như: CardNumber, HolderName, CardType&hellip; Tuy nhi&ecirc;n, giả thuyết l&agrave; để tạo ra một object của&nbsp;&lt;strong&gt;BankCard&lt;/strong&gt; th&ocirc;ng qua constructor() th&igrave; cần điền th&ocirc;ng tin cho rất nhiều field, việc n&agrave;y l&agrave;m tăng effort một c&aacute;ch đ&aacute;ng kể cho cả lập tr&igrave;nh vi&ecirc;n v&agrave; hệ thống. Do đ&oacute; m&igrave;nh sẽ thay thế bằng phương ph&aacute;p sử dụng cơ chế clone của&nbsp;Cloneable interface.&lt;/p&gt;&lt;p&gt;Chi tiết của class&nbsp;&lt;strong&gt;BankCard&lt;/strong&gt; như sau:&lt;/p&gt;&lt;pre&gt;&lt;code class=&quot;language-plaintext&quot;&gt; public class BankCard implements Cloneable{

    public String cardNumber;
    public String holderName;
    public String cardType;
    public BigDecimal amount;

    public BankCard(String cardType){
        this.cardType = cardType;
    }

    @Override
    protected BankCard clone() {
        try {
            return (BankCard) super.clone();
        } catch (CloneNotSupportedException e) {
            e.printStackTrace();
        }
        return null;
    }

    @Override
    public String toString() {
        return &quot;BankCard [cardNumber=&quot; + cardNumber + &quot;,
 holderName=&quot; + holderName + &quot;,
 cardType=&quot;+ cardType + &quot;, amount=&quot;+amount+&quot; ]&quot;;
    }

// Getters and Setters
}

&lt;/code&gt;&lt;/pre&gt;&lt;p style=&quot;text-align:justify;&quot;&gt;Theo như class diagram, m&igrave;nh cần tạo ra class&nbsp;CardClient,&nbsp;class n&agrave;y sẽ&nbsp;sử dụng&nbsp;&lt;strong&gt;Prototype&lt;/strong&gt;&nbsp;để tạo ra nhiều loại thẻ cho c&ugrave;ng một customer bằng c&aacute;ch sử dụng&nbsp;clone() method của class&nbsp;BankCard.&lt;/p&gt;&lt;pre&gt;&lt;code class=&quot;language-plaintext&quot;&gt; public class CardClient{

    public static void main(String[] args){
        BankCard platinumCard = new BankCard(&quot;master&quot;);
        platinumCard.setHolderName(&quot;Tom&quot;);
        platinumCard.setCardNumber(&quot;1234&quot;);

        BankCard diamondCard = masterCard.clone();
        diamondCard.setCardType(&quot;visa&quot;);

        System.out.println(platinumCard);
        System.out.println(diamondCard);
    }
}
&lt;/code&gt;&lt;/pre&gt;&lt;p style=&quot;text-align:justify;&quot;&gt;Implementation của Prototype cũng rất đơn giản, kh&ocirc;ng qu&aacute; cầu k&igrave;, phức tạp. Đến đ&acirc;y, m&igrave;nh nghĩ sẽ c&oacute; một v&agrave;i question được đặt ra như sau.&lt;/p&gt;&lt;p style=&quot;text-align:justify;&quot;&gt;C&acirc;u hỏi đầu ti&ecirc;n, đ&oacute; l&agrave; nếu m&igrave;nh update một attribute n&agrave;o đ&oacute; của&nbsp;&lt;strong&gt;platinumCard&lt;/strong&gt; th&igrave; attribute tương ứng của&nbsp;&lt;strong&gt;diamondCard&lt;/strong&gt; c&oacute; bị thay đổi gi&aacute; trị hay kh&ocirc;ng? Bởi v&igrave;&nbsp;&lt;strong&gt;diamondCard&lt;/strong&gt; được tạo ra bằng c&aacute;ch&nbsp;copy th&ocirc;ng tin từ&nbsp;&lt;strong&gt;platinumCard.&lt;/strong&gt;&lt;/p&gt;&lt;p style=&quot;text-align:justify;&quot;&gt;Good question. Dĩ nhi&ecirc;n c&acirc;u trả lời trong trường hợp n&agrave;y l&agrave; &ldquo;&lt;strong&gt;Kh&ocirc;ng&lt;/strong&gt;&rdquo; v&igrave; bản chất của h&agrave;m clone() l&agrave; deep copy, n&ecirc;n việc modify một newly object sẽ kh&ocirc;ng l&agrave;m ảnh hưởng đến original object.&lt;/p&gt;&lt;p style=&quot;text-align:justify;&quot;&gt;C&acirc;u hỏi số hai, điểm kh&aacute;c nhau trong việc sử dụng phương thức clone() v&agrave; to&aacute;n tử dấu&nbsp;&ldquo;=&rdquo;.&lt;/p&gt;&lt;p style=&quot;text-align:justify;&quot;&gt;&lt;span style=&quot;color:hsl(0,75%,60%);&quot;&gt;&nbsp;BankCard diamondCard = platinumCard.clone() vs&nbsp;&nbsp;BankCard diamondCard = platinumCard;&lt;/span&gt;&lt;/p&gt;&lt;p style=&quot;text-align:justify;&quot;&gt;Khi ch&uacute;ng ta sử dụng to&aacute;n tử&nbsp; dấu&nbsp;&ldquo;=&rdquo; đều n&agrave;y c&oacute; nghĩa l&agrave; object&nbsp;&lt;strong&gt;diamondCard&lt;/strong&gt; tham chiếu đến object&nbsp;&lt;strong&gt;platinumCard&lt;/strong&gt;, nếu&nbsp;&lt;strong&gt;platinumCard&lt;/strong&gt; thay đổi th&ocirc;ng tin điều n&agrave;y dẫn đến&nbsp;&lt;strong&gt;diamondCard&lt;/strong&gt; cũng thay đổi th&ocirc;ng tin theo&nbsp;(shallow copy)&lt;/p&gt;&lt;p style=&quot;text-align:justify;&quot;&gt;M&igrave;nh cũng sẽ c&oacute; một b&agrave;i viết về hai phương ph&aacute;p&nbsp;&lt;strong&gt;Deep-Copy&lt;/strong&gt; v&agrave;&nbsp;&lt;strong&gt;Shallow-Copy&lt;/strong&gt; để giải th&iacute;ch cụ thể sự kh&aacute;ch biệt của hai loại copy n&agrave;y với mọi người.&lt;/p&gt;&lt;p style=&quot;text-align:justify;&quot;&gt;Đến đ&acirc;y th&igrave; anh em m&igrave;nh cũng đ&atilde; t&igrave;m hiểu về c&ocirc;ng năng cũng như implementation của&nbsp;&lt;strong&gt;Prototype&lt;/strong&gt; rồi. M&igrave;nh cũng đ&atilde; apply pattern n&agrave;y cho nhiều dự &aacute;n n&ecirc;n tiếp theo, m&igrave;nh sẽ liệt k&ecirc; ra pros v&agrave; cons của pattern n&agrave;y dựa tr&ecirc;n kinh nghiệm thực chiến của m&igrave;nh.&lt;/p&gt;&lt;h2&gt;&lt;span style=&quot;color:hsl(0,0%,0%);&quot;&gt;&lt;strong&gt;4. The Pros and Cons of Prototype Design Pattern&lt;/strong&gt;&lt;/span&gt;&lt;/h2&gt;&lt;h3&gt;&lt;span style=&quot;color:hsl(0,0%,0%);&quot;&gt;&lt;strong&gt;The Pros of Prototype&lt;/strong&gt;&lt;/span&gt;&lt;/h3&gt;&lt;p&gt;Một trong những điểm mạnh nổi bật nhất của&nbsp;&lt;strong&gt;Prototype&nbsp;&lt;/strong&gt;m&agrave; bất kỳ lập tr&igrave;nh vi&ecirc;n n&agrave;o cũng c&oacute; thể nhận ra đ&oacute; ch&iacute;nh l&agrave; việc tạo ra c&aacute;c object mới dựa tr&ecirc;n một object đ&atilde; tồn tại sẵn một c&aacute;ch tiện lợi. Điều n&agrave;y gi&uacute;p giảm đi rất nhiều effort cho anh em coder cũng như đem lại performance xịn hơn cho hệ thống.&lt;/p&gt;&lt;p&gt;Prototype rất hữu &iacute;ch khi bạn muốn tạo ra c&aacute;c object c&oacute; logic phức tạp, b&ecirc;n cạnh đ&oacute; pattern n&agrave;y c&ograve;n gi&uacute;p m&igrave;nh hạn chế được việc phải tạo th&ecirc;m c&aacute;c class con kh&ocirc;ng cần thiết.&lt;/p&gt;&lt;p&gt;Trong qu&aacute; tr&igrave;nh l&agrave;m project thực tế m&igrave;nh đ&atilde; kết hợp Prototype v&agrave; Factory với nhau, để implement một t&iacute;nh năng kh&aacute; phức tạp đ&oacute; l&agrave; tạo ra c&aacute;c loại contract cho kh&aacute;ch h&agrave;ng trong c&aacute;c hệ thống finance khi kh&aacute;ch mua bảo hiểm, hoặc hợp đồng vay thế chấp, t&iacute;n chấp&hellip;Đồng thời, kết hợp với&nbsp;&lt;strong&gt;Map&lt;/strong&gt; collection để n&acirc;ng cao tối đa hiệu quả của&nbsp;&lt;strong&gt;Prototype&lt;/strong&gt;.&lt;/p&gt;&lt;pre&gt;&lt;code class=&quot;language-plaintext&quot;&gt; public class ContractFactory{

    public Map&amp;lt;String, Contract&amp;gt; contractMaps = new HashMap&amp;lt;&amp;gt;();

    public void extendContract(String customerId){
        Contract extended = null;
        if(contractMaps.containsKey(customerId)) {
            Contract original = contractMaps.get(customerId);
            extended = original.clone();
            extended.setRenewDate(new Date());
        }else {
            extended = new Contract();
        }
        contractMaps.put(customerId, extended);
    }
}
&lt;/code&gt;&lt;/pre&gt;&lt;h3&gt;&lt;strong&gt;The Cons of Prototype&lt;/strong&gt;&lt;/h3&gt;&lt;p style=&quot;text-align:justify;&quot;&gt;&lt;strong&gt;Prototype&lt;/strong&gt; pattern ph&ugrave; hợp đối với việc tạo ra c&aacute;c object c&oacute; nhiều th&ocirc;ng tin chung. Tuy nhi&ecirc;n, cần phải xem x&eacute;t kỹ lưỡng trong trường hợp cần tạo ra object đặc biệt khi m&agrave; object mới c&oacute; qu&aacute; nhiều field cần phải update.&lt;/p&gt;&lt;p style=&quot;text-align:justify;&quot;&gt;Dĩ nhi&ecirc;n việc tạo ra c&aacute;c object mới bằng c&aacute;ch clone từ object hiện tại th&igrave; khả năng cao object mới sẽ chứa nhiều th&ocirc;ng tin dư thừa từ original object.&lt;/p&gt;&lt;h2&gt;&lt;span style=&quot;color:hsl(0,0%,0%);&quot;&gt;&lt;strong&gt;5. The Conclusion&lt;/strong&gt;&lt;/span&gt;&lt;/h2&gt;&lt;p style=&quot;text-align:justify;&quot;&gt;Prototype design pattern rất hiệu quả trong việc tạo ra object phức tạp. B&ecirc;n cạnh đ&oacute;, n&oacute; cũng thể hiện kha kh&aacute; điểm yếu. Tất cả m&igrave;nh đều đ&atilde; liệt k&ecirc; trong b&agrave;i viết. Dĩ nhi&ecirc;n, sẽ kh&ocirc;ng c&oacute; một giải ph&aacute;p n&agrave;o l&agrave; to&agrave;n diện. V&igrave; vậy, anh em n&ecirc;n xem x&eacute;t kỹ trước khi đưa ra quyết định l&agrave; n&ecirc;n d&ugrave;ng pattern n&agrave;o, để đạt được hiệu quả tối ưu nhất.&lt;/p&gt;&lt;/body&gt;&lt;/html&gt;

Creational Design Pattern là một nhóm pattern vô cùng hữu ích trong việc tạo ra một object. Việc tạo ra object phụ thuộc nhiều vào ngữ cảnh như: số lượng tham số truyền vào, điều kiện cơ sở…Là một trong những pattern phổ biến của nhóm Creational, Prototype pattern đem lại hiệu quả cao trong việc tạo ra một object phức tạp. Chúng mình cùng nhau tìm hiểu chi tiết về kỹ thuật thiết kế một Prototype pattern như thế nào  nhé

[Design Pattern] Bài 06: Sử Dụng Prototype Trong Java

Design Patterns

Tech Lead

Phuong Bui

.NET Developer

Vu Truong

Senior Developer

Trung Tran

Tech lead

Wind

Long Nguyen

Business Analyst

Duong Dat Thanh

<html><body><h2>1/ What is a Database Transaction?</h2>Database Transaction is a unit of work, which may include many actions we want to perform with the database system. In a simple word, the transaction represents any change in the database.The main purpose of the transaction is:<ul><li>Furnish a dependable operational entity capable of facilitating accurate recovery and preserving database consistency during system failure.</li><li>Provide isolation between programs and allow concurrent access to the database.</li></ul><figure class="image image_resized" style="width:35.94%;"><img src="https://api.careers.saigontechnology.com/storage/ck-editor/database-nj4N9CS0ArL3krODuPO9XLykiFwjdWyA6THcbKa6.webp"></figure><h2>2/ Transaction basic and ACID properties</h2>Each transaction can have a single operation or a set of operations, which will be performed sequentially. Transaction will wrap this set and use the following pattern to handle SQL execution:<ul><li>Begin the transaction.</li><li>Perform a series of data manipulations and/or queries.</li><li>If executed without encountering errors, commit the transaction.</li><li>However, if an error arises during the process, roll back the transaction to its initial state.</li></ul><figure class="image image_resized" style="width:79.12%;"><img src="https://api.careers.saigontechnology.com/storage/ck-editor/Data%203-xzNeMcIxl87PmIk3glBKO8IMWq7llhuzFddFdgJl.webp"></figure>By following this pattern, the database can ensure it will provide the ACID properties, which will guarantee data validity despite errors, power failures, and other mishaps.<figure class="image image_resized" style="width:81.75%;"><img src="https://api.careers.saigontechnology.com/storage/ck-editor/Data%201-q35H71HVdpwhb2wVlJtpjweXJY9XcYTZNvbRKFkC.webp"></figure><h3>2.1/ Atomicity</h3>Atomicity ensures that every transaction is viewed as a singular "unit," ensuring it either completes entirely or fails. In a simple word, it means all or nothing. All the statements (operations) in one transaction must either succeed or fail.Consider a monetary transfer from bank account A to account B as an illustration of an atomic transaction. This process entails two distinct operations: withdrawing funds from account A and depositing them into account B. To maintain consistency, we mustn't observe the deduction from account A until we're confident that the corresponding credit has been made to account B. By executing these actions within an atomic transaction, we ensure that the database preserves its integrity. In the event of a failure in either operation, the database remains consistent, preventing any debits or credits from occurring.<h3>2.2/ Consistent</h3>Consistency guarantees that a transaction transitions the database from one coherent state to another, upholding database invariants. This means that any data modifications adhering to defined rules, such as constraints, cascades, triggers, and their combinations, must maintain validity. In essence, consistency ensures that the database remains in a reliable and predictable state after each transaction, preventing the introduction of invalid or contradictory data.CREATE TABLE acid test (A INTEGER, B INTEGER, CHECK (A + B = 100));Let’s imagine we have a table with a validation requirement check that A+B = 100.Suppose a transaction attempts to deduct 10 from A without updating B. Given that consistency checks occur after each transaction, it's established that A + B equals 100 before the transaction initiation. While the deduction from A may succeed, ensuring atomicity, a subsequent validation check reveals A + B now equals 90, violating the database's rules. Consequently, the entire transaction must be aborted, and the affected rows rolled back to their pre-transaction state to maintain consistency.<h3>2.3/ Isolation</h3>If our system only executes one transaction by one, everything will be simple. Transactions are frequently executed concurrently, necessitating isolation to ensure that concurrent transaction execution results in the same database state as if the transactions were executed sequentially. Isolation serves as the primary objective of concurrency control, guaranteeing that each transaction's effects on the database remain isolated from those of concurrently executing transactions. This isolation prevents interference or inconsistency between transactions, maintaining data integrity and consistency across the database.Consider two transactions:<ul><li>T1 transfers 10 from A to B.</li><li>T2 transfers 20 from B to A.</li></ul>Combined, there are four actions:<ul><li>T1 subtracts 10 from A.</li><li>T1 adds 10 to B.</li><li>T2 subtracts 20 from B.</li><li>T2 adds 20 to A.</li></ul>If isolation is maintained, these operations are performed in order.But if isolation is not maintained, the order of operations might be messed up. One of the possibilities might be:<ul><li>T1 subtracts 10 from A.</li><li>T2 subtracts 20 from B.</li><li>T2 adds 20 to A.</li><li>T1 adds 10 to B.</li></ul>Consider if T1 fails, but T2 already modified data so it cannot restore data before T1.Depending on the isolation level used, the effects of an incomplete transaction might not be visible to other transactions, which we will deep dive into in another section of this article.<h3>2.4/ Durability</h3>Durability ensures that once a transaction has been successfully committed, its changes are permanently saved and will persist even in the event of a system failure, such as a power outage or crash. This means that once a transaction is confirmed as complete, its effects on the database are guaranteed to endure and will not be lost due to unexpected system failures.<h2>3/ Concurrently control mechanism</h2>There are many mechanisms to ensure that transactions are executed reliably, maintaining data integrity and allowing multiple transactions to work concurrently while preserving consistency like concurrency control mechanisms, transaction logging, and buffer management. In this section, I will talk about concurrent control mechanisms and how they work.Executing transactions sequentially can indeed lead to increased waiting times for other transactions, potentially causing delays in overall execution. To enhance system throughput and efficiency, multiple transactions are executed concurrently. Concurrency control plays a crucial role in database management systems (DBMS) by facilitating simultaneous data manipulation or execution by multiple processes or users without compromising data consistency. By carefully coordinating the concurrent execution of transactions, concurrency control mechanisms ensure that data remains consistent and that transactions do not interfere with each other's operations, thereby optimizing system performance and resource utilization.There are some commonly used concurrency control mechanisms: Lock-based concurrency control, Timestamp-based concurrency control, multi-version concurrency control (MVCC), Optimistic concurrency control, Two-phase locking (2PL), and Snapshot isolation. However, the most popular methods to be used to handle concurrent control are Lock-based and MVCC.<h3>3.1/ Lock-based</h3>This mechanism involves acquiring and releasing locks on database objects such as tables, rows, or columns to control access by concurrent transactions.<figure class="image image_resized" style="width:59.61%;"><img src="https://api.careers.saigontechnology.com/storage/ck-editor/Data%204-A26jrksvP0Sx9GnYZ5yFkTwgyMnZ9CMB3iScsqSa.webp"></figure><h4>Type of locks</h4>There are different types of locks, including shared locks (read locks) and exclusive locks (write locks), which help prevent conflicting operations:<ul><li>Share locks: Allows multiple transactions to read the data item concurrently but prevents any transaction from modifying it until all shared locks are released.</li><li>Exclusive locks: Grants exclusive access to a data item, preventing other transactions from reading or writing it until the lock is released. Once a process acquires a lock on a resource, other processes attempting to acquire the same lock must wait.</li></ul>Multiple shared locks can be held simultaneously on a resource. However, if a resource is already locked with a shared lock, another process can't acquire an exclusive lock. Likewise, a process can't acquire a shared lock on a resource that's exclusively locked.<h4>Locking problems</h4>Although locking is a good way to handle concurrent access, it still has some issues. The three most common problems of locking are:<ul><li>Fails to release the lock:  What if the lock fails to release? It will block other transactions and the whole process will be blocked. </li><li>Lock contentions: Some resources may be accessed frequently and multiple transactions could try to acquire locks on these resources at the same time. It leads to subsequent transactions that may encounter delays while waiting for others to complete, resulting in contention for these resources or locks. Imagine you are in a line waiting to check out but there is only 1 counter.</li><li>Locking deadlock: one transaction locks resource A and tries to access the lock on resource B before releasing the lock on the first resource. Simultaneously, another process acquires the lock on resource B while attempting to acquire the lock on resource A. Consequently, both processes remain incomplete until they obtain these locks.</li></ul><h3>3.2/ MVCC</h3>An alternative approach to locking is multiversion concurrency control (MVCC), where the database offers each reading transaction the original, unaltered version of data being modified by another active transaction. This enables readers to function without requiring locks, meaning writing transactions doesn't impede reading transactions, and vice versa.<h4>Isolation and its problems</h4>Remember that the results of the transaction are only visible after a commit to the database happens so what happens when a transaction tries to read a row updated by another transaction? Now our application can handle multiple concurrent actions at the same time, that’s why we will be faced with more complex problems.Most of our operations are READ and that’s why most of the problem is about read phenomena.We have 4 common read phenomena including:<ul><li>Dirty read: Occurs when a transaction reads data modified by another concurrent transaction that has not yet been committed. This can lead to reading inconsistent or erroneous data.</li><li>Nonrepeatable read: This happens when a transaction re-reads data it has previously retrieved and finds that the data has been altered by another transaction that has since been committed. This inconsistency may cause unexpected behaviour.</li><li>Phantom read: Occurs when a transaction re-executes a query with a search condition and finds that the set of rows satisfying the condition has changed due to another transaction being committed in the meantime. This can lead to inconsistencies in query results.</li><li>Serialization anomaly: Refers to a situation where the outcome of executing a group of transactions together is different from the result obtained by executing the same transactions sequentially, one after the other. This inconsistency can violate the desired consistency of the database.</li></ul><h4>Isolation levels</h4>With the special problems of reading data when operating with multiple concurrent operations, our database system needs to implement different levels of isolation to solve problems for different use cases.<ul><li>Read uncommitted: The lowest isolation level, allowing transactions to read data that hasn't been committed by other transactions. This level doesn't provide isolation, meaning that concurrent transactions may see uncommitted data, potentially leading to inconsistent or incorrect results.</li><li>Read committed: This level allows transactions to read only committed data, preventing dirty reads. However, it doesn't address non-repeatable or phantom reads, as it doesn't lock data during read operations. This is the default isolation level in PostgreSQL.</li><li>Read committed: Transactions at this level lock resources throughout the transaction, preventing other transactions from modifying the same data. While it helps against non-repeatable reads, it may still encounter phantom reads. This level is often used to maintain consistency in data-intensive operations.</li><li>Serializable: The highest level of isolation, emulating serial execution of transactions. All concurrent transactions are treated as if they were executed one after the other, ensuring the highest level of consistency and preventing all concurrency-related anomalies, including non-repeatable reads and phantom reads.</li></ul><figure class="image"><img src="https://api.careers.saigontechnology.com/storage/ck-editor/Data%205-A3N7amL9p17duVPtyxsPcxNXMqBu9QyfKKw9rGc4.webp"></figure>Although read uncommitted is the lowest isolation level. Some modern relational database systems like PostgreSQL do not allow it to happen in their system.<h2>4/ Demo</h2>One of the most valuable characteristics of isolation with developers is Atomicity. When you have to implement an API with a ton of operations including read, write, and update and once an operation fails, others fail and immediately roll back data to the previous state to make sure our database system is consistent. Remember to use database transactions in this case.  My simple demo will help you to know how you can use transactions with NodeJS and Prisma: wrap all your operations with Prisma inside the transaction. In my code, assume my application is an application that only allows users to add money to their account with a specific money source: MOMO and VPBANK. My scenario is to create a transaction to add money from the “MOMON” source, which is not allowed in our system.  Please check my code for more details.<h2>5/ Conclusion</h2>In conclusion, transactions are a vital aspect of database management systems, providing a mechanism for ensuring data integrity, consistency, and reliability. By grouping database operations into atomic units, transactions allow for the execution of multiple operations as a single, indivisible entity. This ensures that either all operations succeed and are committed to the database, or none of them are executed, maintaining data integrity and preventing partial updates.Choosing a higher isolation level usually comes with a performance trade-off due to increased locking or versioning mechanisms to maintain consistency. The choice of isolation level depends on the specific requirements of your application, balancing the need for data consistency with the desired level of concurrency.Resources:<ul><li>Demo source code: <a href="https://github.com/saigontechnology/Blog-Resources/tree/main/NodeJS/Khanh.Nguyen/NestJS-Prisma-Transaction">Repo’s link</a></li></ul>References:   - https://medium.com/inspiredbrilliance/what-are-database-locks-1aff9117c290  - https://www.postgresql.org/docs/current/transaction-iso.html</body></html>

Let's take a look into one of the most fundamental concepts of databases. This article will show you the main concepts of transaction and  how you can manage transactions in NodeJS with Prisma.

Database Transaction and how to handle it in NodeJS with Prisma

AWS Lambda and Google Cloud Functions are serverless computing platforms. Lambda offers broader language support and integrates well within the AWS ecosystem, while Cloud Functions excels at integration with Google Cloud services and shines in real-time data processing scenarios.

Comparison of AWS Lambda and Google Cloud Functions

<html><body>In recent years, AI development has rapidly evolved from simple, single-purpose tools to more complex, intelligent systems. As we enter 2025, multi-agent systems (MAS) stand at the forefront of this evolution, offering significant advantages over traditional monolithic AI approaches. This article explores the rise of multi-agent systems, their benefits compared to “godlike” single agents, and how choosing the right agent for each task creates optimal balance between cost, speed, and quality. Understanding Multi-Agent Systems A multi-agent system consists of multiple specialized AI agents that work together to accomplish tasks that would be difficult or inefficient for a single agent to handle alone. Unlike traditional “godlike” models that attempt to excel at everything, multi-agent systems distribute responsibilities among specialized components.<figure class="image"><img src="https://api.careers.saigontechnology.com/storage/ck-editor/Multi-Agent-Systems-1-sFycV6JisNQva1mcCJbZDlexmbHmJ1aJzqrGM9U6.webp"></figure>Each agent in the system focuses on specific skills or domains, such as: <ul><li>Architects: Design high-level systems and evaluate technical approaches </li><li>Technical leads: Implement code and manage technical details </li><li>Documentation experts: Create clear explanations and user guides </li><li>Analysis specialists: Process and interpret complex data </li><li>Customer support agents: Handle user inquiries and issues </li></ul>These specialized agents communicate through a coordination mechanism, often managed by an orchestrator or agent manager that routes tasks appropriately. The Limitations of “Godlike” Single Agents Traditional “godlike” AI models attempt to handle all possible tasks through a single, large, general-purpose model. While impressive in their versatility, these approaches face several significant challenges: <ul><li>Resource intensity: Larger models require more computational power, memory, and energy </li><li>Jack of all trades, master of none: Performance on specialized tasks often suffers </li><li>Inefficient resource allocation: Using powerful models for simple tasks wastes resources </li><li>Scaling difficulties: Adding new capabilities often requires retraining the entire model </li><li>Limited specialization: Cannot fully optimize for domain-specific knowledge </li></ul>These limitations become increasingly problematic as AI systems tackle more complex, varied tasks in production environments. Benefits of Multi-Agent Systems The multi-agent approach offers several compelling advantages over monolithic systems: 1. Specialized Expertise Multi-agent systems allow for deep specialization, with each agent focusing on what it does best. Just as human organizations benefit from specialists in different roles, multi-agent AI systems leverage targeted expertise for superior results.  <figure class="image"><img src="https://api.careers.saigontechnology.com/storage/ck-editor/Multi-Agent-Systems-2-Py5J2viN7zrUTZMrItm9KM6P9YYxprleKL7s6s7W.webp"></figure>2. Resource Optimization Perhaps the most significant practical benefit is resource optimization. In a multi-agent system, computational resources are allocated according to need: <ul><li>Simple tasks use lightweight models that consume fewer tokens and less processing power </li><li>Complex tasks engage more powerful models only when necessary </li><li>Overall system efficiency improves through appropriate resource allocation </li></ul>Consider this real-world comparison of resource usage: <figure class="table"><table><tbody><tr><td>Task Type </td><td>“Godlike” Agent </td><td>Multi-Agent System </td></tr><tr><td>Simple FAQ response </td><td>Uses full-sized model (high cost) </td><td>Uses small specialized model (low cost) </td></tr><tr><td>Complex reasoning </td><td>Uses full-sized model </td><td>Uses large specialized model </td></tr><tr><td>Mixed workflow </td><td>Uses full-sized model for all steps </td><td>Distributes tasks to appropriate models </td></tr></tbody></table></figure>3. Improved Fault Tolerance Multi-agent systems exhibit greater fault tolerance through their distributed nature. If one agent fails, others can continue functioning, often with minimal impact on the overall system. This creates more reliable systems, especially for critical applications. 4. Faster Innovation and Integration Adding new capabilities to a multi-agent system doesn’t require retraining the entire model. Instead, new specialized agents can be developed independently and integrated into the existing framework. This accelerates innovation and allows for more agile development. 5. Enhanced Collaboration Multi-agent systems mirror human teamwork, with different specialists collaborating on complex problems. This collaborative approach often produces better outcomes than having a single entity attempt to master all aspects of a problem. <figure class="image"><img src="https://api.careers.saigontechnology.com/storage/ck-editor/Multi-Agent-Systems-3-1536x513-1A5hYjGAC44iyFLCEiHjZvG6ShHSOF0mNXMiXsha.webp"></figure>Real-World Example: Multi-Agent Repository Analysis The example repository in this article provides a practical example of multi-agent architecture in action. The system includes: <ol><li>An AgentManager that coordinates between different specialized agents </li><li>A base Agent class that defines core functionality shared by all agents </li><li>Specialized agents like ArchitectAgent, TechLeadAgent, and DocumentationAgent </li><li>A handoff mechanism that routes tasks to the most appropriate agent </li></ol>This implementation demonstrates how multi-agent systems can efficiently distribute responsibilities, with each agent registering only the tools it needs for its specific domain. Choosing the Right Agent and Model A critical aspect of effective multi-agent systems is selecting the right specialized agent and underlying model for each task. This selection process requires balancing three key factors: 1. Cost Considerations AI model usage costs vary significantly based on model size, token usage, and processing requirements. Multi-agent systems can optimize costs by deploying: <ul><li>Smaller, more efficient models for routine tasks </li><li>Larger, more powerful models only when necessary </li><li>The right-sized model for each specific function </li></ul>2. Speed Requirements Different tasks have different latency requirements: <ul><li>Customer-facing interactions may require near-instant responses </li><li>Background analysis can tolerate longer processing times </li><li>Critical operations may need to balance speed with accuracy </li></ul>Multi-agent systems can prioritize speed where it matters most while allowing more processing time for complex operations that require it. 3. Quality Demands Quality requirements also vary by task: <ul><li>Some operations require perfect accuracy (financial calculations, medical diagnostics) </li><li>Others can tolerate occasional imperfections (creative suggestions, non-critical analyses) </li><li>Many tasks fall somewhere in between </li></ul><figure class="image"><img src="https://api.careers.saigontechnology.com/storage/ck-editor/Multi-Agent-Systems-4-JWi19FKtt4Or5QlZAXslUJpBak5wp0kfEmjX0RtD.webp"></figure>Effective multi-agent systems match quality levels to actual requirements rather than applying the highest possible quality standard universally. The Future of Multi-Agent Systems in 2025 As we progress through 2025, multi-agent systems are becoming increasingly sophisticated. According to recent research and industry trends: <ol><li>Orchestration will become more intelligent: Agent managers will evolve from simple routers to sophisticated coordinators that optimize workflows in real-time </li><li>Models will be precisely matched to tasks: Systems will automatically select and configure the optimal model for each specific task based on complexity, importance, and resource availability </li><li>Agent-to-agent collaboration will increase: Rather than simple handoffs, agents will work collaboratively, sharing information and building on each other’s outputs </li><li>Enterprise adoption will accelerate: Organizations will increasingly shift from single-model approaches to multi-agent systems for mission-critical applications </li><li>Customization will become standard: Systems will allow organizations to easily configure agent teams for their specific industry needs and use cases </li></ol>Conclusion Multi-agent systems represent the natural evolution of AI from powerful but inefficient general-purpose models to optimized, collaborative specialist teams. By distributing tasks among specialized agents and selecting the right model for each job, these systems deliver better results with lower resource requirements. As we continue through 2025, expect to see multi-agent architectures become the standard approach for complex AI implementations, with specialized agents working together to tackle increasingly challenging problems. Organizations that adopt this approach will gain significant advantages in cost efficiency, performance, and capability compared to those relying on traditional single-agent models. By understanding the importance of choosing the right agent and model for each task, AI architects can build systems that effectively balance cost, speed, and quality—achieving optimal results while maximizing resource efficiency. References Academic and Industry Sources <ol><li>Salesforce. (2025). Future of AI Agents 2025. <a href="https://www.salesforce.com/news/stories/future-of-ai-agents-2025/">https://www.salesforce.com/news/stories/future-of-ai-agents-2025/</a> </li><li>Disaster Recovery Journal. (2025). The Year of Multi-Agent Systems. <a href="https://drj.com/industry_news/2025-the-year-of-multi-agent-systems/">https://drj.com/industry_news/2025-the-year-of-multi-agent-systems/</a> </li><li>InclusionCloud. (2025). What Are Multiagent Systems? The Future of AI in 2025. <a href="https://www.linkedin.com/pulse/what-multiagent-systems-future-ai-2025-inclusioncloud-s8kzf">https://www.linkedin.com/pulse/what-multiagent-systems-future-ai-2025-inclusioncloud-s8kzf</a> </li><li>InData Labs. (2025). Multi-Agent AI Benefits, Advantages &amp; Developments. Retrieved from <a href="https://indatalabs.com/blog/multi-agent-ai">https://indatalabs.com/blog/multi-agent-ai</a> </li><li>Digital Ocean. (2025). Single-Agent vs Multi-Agent Systems: Two Paths for the Future of AI. Retrieved from <a href="https://www.digitalocean.com/resources/articles/single-agent-vs-multi-agent">https://www.digitalocean.com/resources/articles/single-agent-vs-multi-agent</a> </li><li>IBM. (2025). AI Agents in 2025: Expectations vs. Reality. Retrieved from <a href="https://www.ibm.com/think/insights/ai-agents-2025-expectations-vs-reality">https://www.ibm.com/think/insights/ai-agents-2025-expectations-vs-reality</a> </li><li>OpenAI. (2025). New tools for building agents. Retrieved from <a href="https://openai.com/index/new-tools-for-building-agents/">https://openai.com/index/new-tools-for-building-agents/</a> </li></ol>Implementation Example 8. Multi-Agent System Repository: <a href="https://github.com/daltonnyx/swissknife/">https://github.com/daltonnyx/swissknife/</a>   This repository demonstrates a practical implementation of a multi-agent system with specialized agents (Architect, TechLead, Documentation) and an agent manager that handles coordination and handoffs. Additional Resources 9. MIT Technology Review. (2025). The collaborative future of artificial intelligence. [Publication details to be added] 10. Stanford HAI. (2025). Multi-agent systems: Towards more resilient AI. [Publication details to be added] Note: Some references from 2025 represent projected publications and developments as part of the forward-looking nature of this article. </body></html>

Discover how Multi-Agent Systems (MAS) are revolutionizing AI in 2025! Learn why specialized AI agents outperform traditional "godlike" AI, offering enhanced efficiency and scalability. Explore the key benefits of MAS, including optimized resource allocation and improved fault tolerance. Understand how strategic agent and model selection can balance cost, speed, and quality for your AI projects. Stay ahead of the curve with insights into the future of AI and the growing adoption of MAS in enterprise applications.