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

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ó.

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

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

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

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.

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.
OK Let’s Go.

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

Design Patterns

Senior Developer

Trung Tran

Senior AI Engineer

Phong Le

Duy Le

Long Nguyen

Middle Developer

Nguyễn Nhật Minh

Tung Hoang

Are you facing problems with data consistency in a highly concurrent environment? Are you looking for a way to limit and synchronize access to a shared resource across services in a distributed system? Let's see how a distributed lock can help in this situation.

Implement Distributed Lock For a Microservices Software System

The AI, Machine Learning, and Deep Learning definition are becoming viral recently. Let's see how we could apply them to address our problems in the real world, especially in the Computer Vision field for the Image Classification task.

Build Deep Learning model for the Image Classification task (Part1): Pytorch model

Build a Deep Learning model for the Image Classification task in a simple way

Many individuals wish to build their own 3D website but may feel unsure of where to begin and have the confidence it would run smoothly. If you’re searching for a way to build 3d websites as a developer then this article will 100% help you.

Apply 3d content on a webpage using three.js library

Do you know Web 3.0? Have you ever listened to some keywords like Blockchain, Tokens, Smart Contracts, Block, Semantic website and do not really understand them? You want to deeply understand Web 3.0 and its application architecture. Let me explain for you in this blog.