Data consistency is a vital part of software systems. With relational databases, we’re already familiar with how the transaction mechanism ensures ACID operations on the database storage. However, when it comes to a distributed system, how can we ensure data consistency across services? Yes, in this post, we will see how the Saga design pattern allows us to create a distributed transaction.

Implement a distributed transaction in microservices software system using Saga pattern

In the previous section (part 2), I provided an overview of how to set up a working environment using Docker containers and build a Product Service. In this section (part 3), we will shift our focus to building Customer Service using .NET, Minimal API, and PostgreSQL.

<html><body><h2 style="text-align:justify;">Microservices là gì?   </h2><ul><li>Microservices là một kiến trúc phần mềm bao gồm nhiều services nhỏ (micro-service). Ý tưởng của microservices là chia bài toán lớn thành nhiều bài toán nhỏ.   </li><li>Kiến trúc microservices khá phổ biến hiện nay và được nhiều công ty lớn sử dụng như: Netflix, eBay, Amazon, Twitter, PayPal,...   </li><li>Mỗi service trong kiến trúc này là mỗi module độc lập giúp dễ dàng phát triển, kiểm thử, mở rộng và triển khai…   </li></ul><img src="https://api.careers.saigontechnology.com/storage/ck-editor/CKEDITOR-Mewjv7fi3suPq2CCAtJF0o301ALiBtXDl6TkhQTk.png">  <h2>Lợi ích của microservices?</h2><img src="https://api.careers.saigontechnology.com/storage/ck-editor/CKEDITOR-GUiY1ZOvBclZZJQsHuJmcENmljTDZcZcUs5aumJ2.png">   <ul><li>Linh động: các services được tổ chức thành các modules độc lập phân tán giúp dễ dàng phát triển, tích hợp và triển khai từng phần (CI/CD).   </li><li>Nhiều lựa chọn về công nghệ: có thể lựa chọn các kiến trúc, công nghệ, ngôn ngữ, cơ sở dữ liệu cho từng service.</li></ul>Ví dụ: có thể tận dụng nguồn lực thế mạnh của nhiều team để áp dụng công nghệ phù hợp cho mỗi service. Service này sử dụng .net, sql server, service khác sử dụng nodejs, mongodb, cosmosdb...<ul><li>Khả năng chịu lỗi: Khi một hoặc một vài service xảy ra lỗi thì các services khác không hoặc ít bị ảnh hưởng. Đảm bảo toàn hệ thống vẫn vận hành được. Khi sửa lỗi chỉ sửa lỗi ở đúng service đó do các service được thiết kế độc lập, ít phụ thuộc vào nhau nhất có thể.   </li><li>Tối ưu hiệu quả về chi phí: tối ưu và chia nhỏ chi phí cho từng service nhỏ thay vì một ứng dụng lớn.   Ví dụ: service cần lưu trữ dung lượng database, file.. thì ta sẽ scale trên riêng service đó, hoặc đôi lúc có thể tận dụng nhiều công nghệ miễn phí cho các service nhỏ.   </li></ul><h2 style="text-align:justify;">So sánh monolithic và microservices   </h2><ul><li>Monolithic  <ul><li>Tập trung toàn bộ vào một ứng dụng lớn, dự án lớn thì team size và soure code sẽ phình to ra.   </li><li>Việc triển khai (deployment) sẽ đơn giản do toàn bộ tập trung vào một dự án.   </li><li>Kiến trúc truyền thống, dễ tiếp cận.   </li><li>Quá trình deployment không linh hoạt, thời gian build ứng dụng sẽ lâu, khi có một thay đổi nhỏ cũng phải build lại toàn bộ ứng dụng.   </li><li>Khó khăn trong việc kiểm tra lỗi và bảo trì do các modules, services trong dự án phụ thuộc chặt chẽ vào nhau (coupling code).   </li><li>Gặp vấn đề về khả năng chịu lỗi. Khi bị bất kỳ một lỗi nào thì có khả năng toàn bộ ứng dụng bị chết.   </li><li>Khả năng mở rộng hạn chế do tập trung một khối lớn.   </li><li>Khó áp dụng nhiều công nghệ vào dự án.</li></ul></li></ul> <img src="https://api.careers.saigontechnology.com/storage/ck-editor/CKEDITOR-q3M6Qc9vOBMnX5mcuzaZsL99ieLtelloX59KhL0a.png"> <ul><li>Microservices  <ul><li>Chia nhỏ ứng dụng thành các services nhỏ hơn. Ý tưởng của microservices là chia bài toán lớn thành các bài toán nhỏ.   </li><li>Các services được xây dựng độc lập, có khả năng phát triển, kiểm lỗi và triển khai độc lập.   </li><li>Các team làm việc độc lập trên từng services, từng features.   </li><li> Áp dụng các công nghệ, ngôn ngữ khác nhau vào từng services.   </li><li>Khả năng chịu lỗi tốt do các service độc lập, một service bị lỗi thì toàn hệ thống có khả năng vẫn hoạt động được và dễ dàng sửa lỗi đúng service đó.</li></ul></li></ul><img src="https://api.careers.saigontechnology.com/storage/ck-editor/CKEDITOR-vRHmvtjLk6G4z9cXcw4wF248JGhu7rkr6Aj4xlNs.png"><h2 style="text-align:justify;">Ưu và nhược điểm của microservices   </h2><ul><li>Ưu điểm<ul><li>Chia nhỏ hệ thống lớn thành các services nhỏ độc lập nên dễ dàng phát triển, bảo trì và triển khai độc lập.</li><li>Dễ dàng cho các thành viên mới khi tham gia vào dự án, chỉ cần học các service nhỏ.</li><li>Khả năng kiểm soát lỗi tốt, một hoặc vài services bị lỗi thị hệ thống không bị crash.</li><li>Có thể lựa chọn nhiều công nghệ khác nhau cho từng services.</li><li>Khả năng mở rộng linh hoạt, khi cần scale module, feature nào thì scale service tương ứng.</li></ul></li><li>Nhược điểm<ul><li>Kiến trúc phức tạp, đòi hỏi phải có kiến thức chuyên sâu về devops (CI/CD) để có thể triển khai các services nhỏ trong một hệ thống lớn</li><li>Khó để đồng bộ và thống nhất giữa các services (dữ liệu, mã nguồn, con người trong các team..), cần phải chú ý việc giao tiếp giữa các services sao cho hiệu quả.</li><li>Khó đảm bảo sự toàn vẹn và nhất quán dữ liệu giữa các services do mỗi service sử dụng một database riêng.   </li></ul></li></ul><h2 style="text-align:justify;">Các nguyên lý khi xây dựng service trong microservices </h2><img src="https://api.careers.saigontechnology.com/storage/ck-editor/CKEDITOR-J1NR21J9UiZ0pCvFU35ifBXiwbyrMrUAF1vylsYV.png"><ul><li>Một service chỉ nên xử lý một nhiệm vụ chính duy nhất.   </li><li>Mỗi service phải độc lập, có khả năng đóng gói và triển khai độc lập. (CI/CD)   </li><li>Có thể di chuyển các services từ môi trường này sang môi trường khác dễ dàng, thuận tiện cho việc tích hợp và triển khai.   </li><li>Mỗi service nên có dữ liệu của riêng nó, không nên chứa dữ liệu của các service khác. Nếu các service muốn chia sẻ dữ liệu thì nên giao tiếp qua các public interface.   </li><li>Khi một service bị lỗi thì không ảnh hưởng đến toàn hệ thống. Có thể dễ dàng hủy và tạo lại service theo yêu cầu.   </li></ul><h2 style="text-align:justify;">Giới thiệu về series thực chiến xây dựng hệ thống microservices</h2><ul><li>Phần 1 chủ yếu lý thuyết tổng quan về kiến trúc microservices. Hiểu được khái niệm và tư tưởng.</li><li>Phần 2 sẽ giới thiệu cấu trúc dự án microservices. Đồng thời xây dựng 2 services đầu tiên là product (.net 6 + mySql) và customer (.net 6 Minimal API + PostgreSQL)</li></ul><img src="https://api.careers.saigontechnology.com/storage/ck-editor/CKEDITOR-qLj1llkf735WjoFuThx1oA7ZYt6xYxlMfY2ejItU.png"><ul><li>Phần 3 nội dung về Clean Architecture và CQRS pattern. Đồng thời xây dựng 3 service: basket service (.net 6 + redis), order service (.net 6 + sql server) và email service.</li></ul><img src="https://api.careers.saigontechnology.com/storage/ck-editor/CKEDITOR-aiMfOSPBsazfROOz1eOttNvaK4PaJCrcByXRxrjk.png"><ul><li>Phần 4 nội dung tập trung vào cách các micro service giao tiếp với nhau. Phần này mình sẽ giới thiệu về RabbitMQ và Kaffka. Tích hợp RabbitMQ vào hệ thống hiện tại cho quy trình đặt hàng - 2 services Basket và Order sẽ giao tiếp với nhau.</li></ul><img src="https://api.careers.saigontechnology.com/storage/ck-editor/CKEDITOR-NYxyyimZvdGmiBWMw58hKfsboBCN5aJV7omqOXOx.png"><img src="https://api.careers.saigontechnology.com/storage/ck-editor/CKEDITOR-wGUMGuu8WLpsYAJ1Lc0B3FL0dulfQ6X3nvWtd7S7.png"><ul><li>Phần 5 về API Gateway (Ocelot) trong microservices  <img src="https://api.careers.saigontechnology.com/storage/ck-editor/CKEDITOR-UMvqaAIhhxwHKr3oKiPVz5ajX8ck5lbhFolqhPEA.png"></li><li>Phần cuối là một số nội dung khác về micorservices như quản lý transaction giữa các services, xử lý logging cho các request giữa các service, health check và retry (polly),.…</li></ul><h2 style="text-align:justify;">Tổng kết   </h2><ul><li>Vậy là chúng ta đã đi qua tổng quan về microservices và giới thiệu về nội dung tiếp theo trong series thực chiến xây dựng hệ thống microservices.</li><li>Cảm ơn mọi người đã xem bài viết. Chúc mọi người một cuối tuần vui vẻ.</li><li>Nếu có thắc mắc về các phần trong bài này mọi người có thể inbox qua mail: <a href="mailto:long.nguyendh@saigontechnology.com">long.nguyendh@saigontechnology.com</a>. Mình sẽ giải đáp thắc mắc trong tầm hiểu biết. Cảm ơn mọi người.</li></ul> References<ul><li><a href="https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/microservices">Microservice architecture style - Azure</a></li><li><a href="https://learn.microsoft.com/en-us/dotnet/architecture/microservices/architect-microservice-container-applications/microservices-architecture">Microservices architecture | Microsoft Learn</a></li><li><a href="https://learn.microsoft.com/en-us/dotnet/architecture/microservices/architect-microservice-container-applications/direct-client-to-microservice-communication-versus-the-api-gateway-pattern">The API gateway pattern versus the direct client-to-microservice communication | Microsoft Learn</a></li><li><a href="https://rabbitmq.com/">https://rabbitmq.com/</a></li><li>https://kafka.apache.org/</li></ul></body></html>

Giới thiệu tổng quan về microservice, lợi ích khi xây dựng dự án sử dụng kiến trúc microservice, các nguyên lý khi xây dựng microservice, điểm mạnh điểm yếu của microservices, đồng thời giới thiệu series thực chiến xây dựng hệ thống microservices.

Tổng quan về Microservices (Phần 1)

Cài đặt môi trường làm việc cho dự án microservices với docker, xây dựng cấu trúc ban đầu cho dự án, triển khai logging và product service, containerize cho product.service.

THỰC CHIẾN XÂY DỰNG KIẾN TRÚC DỰ ÁN MICROSERVICES VÀ TRIỂN KHAI PRODUCT SERVICE (PHẦN 2)

Build Customer service (.NET, Minimal API, and PostgreSQL)

Microservices

<html><body><h2>Giới Thiệu Về EC2</h2>Mình đã có một bài giới thiệu tổng quan về Amazon Web Service. Các bạn có thể xem lại ở đây <a href="https://docs.google.com/document/d/1rv_FUMNt585OLYVLFG41IX03fYDZljjbXVrIxS4Stzs/edit#heading=h.yjayaup0tlbk">[AWS] Bài 01: Giới Thiệu Về Amazon Web Service (AWS)</a>Trước hết anh em coder mình cùng nhau tìm hiểu về Elastic Compute Cloud để biết xem em nó là gì. Elastic Compute Cloud hay còn được gọi với một cái tên thân mật là EC2. Đây là một service rất thông dụng và nổi tiếng của AWS, cung cấp hệ thống máy tính ảo theo nhu cầu của người sử dụng. Với EC2 chúng ta có thể dễ dàng tạo ra một máy tính ảo chạy một hệ điều hành bất kỳ. Ngoài ra, người dùng cũng có thể dễ dàng tăng hoặc giảm tài nguyên của máy ảo như CPU, RAM…<h2>Điểm Mạnh Của EC2</h2>          Như mình có đề cập ở phần trên thì EC2 cung cấp cho chúng ta các máy tính ảo hóa. Dĩ nhiên đối với các bạn developer, ít nhiều trong quá trình làm việc cũng cần phải thao tác trên một hệ điều hành nào đó, khác với hệ điều hành đang chạy trên máy host. Lấy một ví dụ như sau: mình coding một application bằng ngôn ngữ Java trên hệ điều hành Window. Nhưng khi deploy thì lại phải deploy lên một con server chạy hệ điều hành Ubuntu. Tuy nhiên, mình lại không có kinh nghiệm trên Ubuntu và mình cần tìm hiểu về cách sử dụng hệ điều hành đó trước. Hoặc một ví dụ khác là mình đang sử dụng Macbook nhưng lại cần phải thao tác trên Window…cuộc sống đúng là khó khăn mà. Giải pháp cho vấn đề trên là mình có thể cài đặt máy tính ảo trên VirtualBox hoặc mình cũng có thể sử dụng Docker. Ở đây, mình muốn giới thiệu thêm cho các bạn một giải pháp khác nữa, đó chính là sử dụng EC2 của AWS.Vậy nếu sử dụng EC2 thì nó có gì sang xịn mịn hơn VirtualBox hoặc Docker? Thật ra thì cũng tùy thuộc vào nhu cầu của người sử dụng, nếu chỉ cần một máy ảo với tài nguyên nhỏ hoặc vừa, kiểu như cần một máy ảo Ubuntu với RAM khoản 4G, nhằm mục đích mày mò học hỏi CLI lúc đó dùng VirtualBox or Docker thì vẫn cực kỳ tốt và tiện lợi.  Nhưng với nhu cầu cao hơn thì sao? Mình cần một máy server Ubuntu, RAM là 32G để triển khai một hệ thống micro-services siêu to khổng lồ cho công ty Saigon Technology. Rõ ràng các phần mềm ảo hóa chạy trên máy host sẻ khó có thể đáp ứng được yêu cầu này. Lúc này, giải pháp có thể là mình đi thuê hoặc mua một máy chủ vậy lý. Tuy nhiên với giải pháp này mình lại phải tự setup các phương thức để bảo mật server, rồi khi cần nâng cấp resource cũng là một vấn đề lớn, chưa kể tới việc có khi mình cần nhiều hệ điều hành như Ubuntu, Centos… Amazon EC2 hoàn toàn có thể giúp anh em mình giải quyết những vấn đề trên.<ul><li>Mình có thể dễ dàng tạo ra một hoặc nhiều máy chủ ảo hóa nhanh chóng với thông số resource như CPU , RAM và hệ điều hành được chỉ định.</li><li>Khi không có nhu cầu sử dụng nữa, thì mình có thể stop máy chủ lại hoặc xóa hẳn khỏi EC2.</li><li>Thông tin đăng nhập vào máy chủ được bảo mật và sử dụng cơ chế keypair (public và private key).</li><li>EC2 còn cung cấp tính năng giúp mình thiết lập rank IP Private.</li><li>Chúng ta cũng có thể cấu hình Security Group và Network ACLS để kiểm soát inbound và outbound cho từng instance EC2.</li><li>EC2 cung cấp IPv4 tĩnh.</li><li>Virtual Private Clouds (VPC): Giúp cho bạn có thể cô lập hoặc kết nối các máy chủ ảo hóa với nhau.</li></ul><h2>Hạn Chế Của EC2</h2>          Hạn chế thứ nhất mình muốn đề cập là là về chi phí. Cái này cũng không hẳn là hạn chế, nếu bạn cần một máy ảo mạnh mẽ thì dĩ nhiên bạn phải chịu chi phí hàng tháng khá cao. Mọi thứ hầu như đã được support tận răng rồi, mình chỉ sử dụng thôi mà, nên tốn thêm chi phí thì cũng hợp lý. Tuy nhiên nếu mình cần một máy ảo nhỏ gọn kiểu để học hỏi là chính thì mình có thể dùng Free-Tier, tuy nói là free nhưng nó support khá tốt cho anh em. Chổ này anh em cần chú ý là nếu không sử dụng thì nên stop hoặc xóa Instance của EC2 luôn để tránh AWS charge phí lưu trữ nha.           Hạn chế thứ hai đó là khi mình stop instance đi do không có nhu cầu sử dụng, thì lúc mình start lại instance đó, địa chỉ IPv4 đã sẽ bị thay đổi. Này là một câu chuyện buồn của mình, khi mình tìm hiểu về EC2 do cũng muốn tiết kiệm chi phí nên mình stop instance lại khi nào cần thì start lên. Lúc đó, start lên thì mình lại không connect lại được bằng CLI. Kết quả là tốn hết một ngày mới mò ra lý do. Buồn dễ sợ.           Nếu mình chưa có kinh nghiệm trên VPC hoặc cách cấu hình Security Group, IAM…thì đây cũng là một hạn chế dẫn đến nhiều khó khăn trong việc sử dụng EC2           EC2 là một IaaS (Infrastructure as a service) nên việc sử dụng EC2 còn phụ thuộc vào network. Do đó nếu network của bạn không ổn định hoặc đường truyền internet yếu thì việc kết nối đến EC2 cũng không được mượt mà. Qua bài viết mình đã giới thiệu về EC2, điểm mạnh và những hạn chế của công nghệ này, hy vọng có thể support được mọi người có thêm kiến thức bước vào thế giới “mênh mông” của AWS. Tiếp theo mình có làm một video hướng dẫn mọi người cài đặt một máy EC2 chạy hệ điều hành Window.<h2>Hướng dẫn Setup một EC2 với Hệ Điều Hành Window</h2>          Mình có làm một video để hướng dẫn mọi người cách cài đặt một máy chủ Window trên nền tảng AWS EC2. Mọi người có thể xem qua video ở <a href="https://drive.google.com/file/d/1M6CGzoUmGTdjCM2mz7arov6-uVZZveIY/view">setup-ec2-window </a>. Tùy vào từng thời điểm có thể giao diện của AWS Console khác đôi chút so với video của mình. Các bài viết trong cùng chủ đề về AWS<ul><li><a href="https://docs.google.com/document/d/1rv_FUMNt585OLYVLFG41IX03fYDZljjbXVrIxS4Stzs/edit">[AWS] Bài 01: Giới Thiệu Về Amazon Web Service (AWS)</a></li><li><a href="https://docs.google.com/document/d/1WATiaGfdKX7fmGof7G4o7SE5pVnlizj5RUksKQwk-Nc/edit?usp=share_link">[AWS] Bài 03 - Hướng Dẫn Cài Đặt EC2 Linux</a></li><li><a href="https://docs.google.com/document/d/11Pdg5TWUqZutIiZQ_ydjYtjUlpIUsgYGo7zeFV0OtGo/edit?usp=share_link">[AWS] Bài 04 - Các Lệnh Cơ Bản Trong Linux</a></li><li><a href="https://docs.google.com/document/d/1ZwbYiRrmYikXHhpkFJ8N49KJ-WMKsY598yeHmZXHqps/edit?usp=share_link">[AWS] Bài 05 - Tạo User Trong Linux</a></li><li><a href="https://docs.google.com/document/d/1uR7oqiAOyLX7g3cLS6jrxEdPJcwW_ivUqnakxCsJk58/edit?usp=share_link">[AWS] Bài 06 - Tạo User và Group, Phân Quyền File Trong Linux</a></li></ul></body></html>

Bài viết này mình tập trung chủ yếu vào Elastic Compute Cloud (EC2).  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 nhất về EC2 chẳng hạn như: EC2 là gì? Lợi ích của EC2?
Qua bài viết hy vọng có thể support được mọi người có thêm kiến về AWS EC2.
OK Let’s Go.

[AWS] Bài 02 - Hướng Dẫn Cài Đặt Elastic Compute Cloud (EC2) Window

<html><body><h2>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 image_resized" style="width:69.42%;"><img src="https://api.careers.saigontechnology.com/storage/ck-editor/CKEDITOR-qMDyPoAWykT2Iwws5bsA5h2lA9Asp2r769b8hj8N.png"></figure><h6 style="text-align:center;">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>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>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>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>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>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 image_resized" style="width:69.42%;"><img src="https://api.careers.saigontechnology.com/storage/ck-editor/CKEDITOR-PLCfIJtUNLXs2P2w7dVtbBJaIFlEafSq30vXLWIj.png"></figure><h6 style="text-align:center;">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>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>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>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>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>Ít bị ràng buộc giữa các lớp với nhau</li><li>Xây dựng tập trung vào nghiệp vụ</li><li>Linh hoạt, dễ chuyển đổi, bổ sung và mở rộng</li><li>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>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>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>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 image_resized" style="width:69.42%;"><img src="https://api.careers.saigontechnology.com/storage/ck-editor/CKEDITOR-ddf3HUlqvDtDKQ9V9OIRe0gUVlbphOCyCuX7NF5U.png"></figure><h6 style="text-align:center;">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>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>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>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>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>Ưu điểm:<ul><li>Có thể sử dụng với mô hình microservices hay mẫu DDD</li><li>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>Dễ kiểm thử</li><li>Dễ mở rộng, vì các lớp đã có vai trò riêng của nó</li></ul></li><li>Nhược điểm:<ul><li>Khó để học và hiểu các nghiệp vụ đã được chia tách thành các lớp</li><li>Cấu trúc phức tạp vì cần phải triển khai qua nhiều lớp</li><li>Do các lớp không phụ thuộc nhau nên sẽ khá trừu tượng</li></ul></li></ul><h2>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>Kiến trúc Onion<ul><li>Tập trung vào xử lý nghiệp vụ và đưa nó vào trung tâm</li><li>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>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>Kiến trúc Clean:<ul><li>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>Các lớp được chia theo vai trò cụ thể (entities, interface adapters, frameworks and drivers..)</li><li>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>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>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>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>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>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>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.<h2>Tài liệu tham khảo</h2><ol><li><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><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><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><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.

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

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

&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;

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

Bài viết 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 nhất về Amazon Web Service (AWS) chẳng hạn như: AWS là gì? Có gì trong AWS? Lợi ích của AWS? Nên tìm hiểu AWS từ đâu.
Qua bài viết hy vọng có thể support được mọi người có thêm kiến thức về AWS.
OK Let’s Go.

[AWS] Bài 01: Giới Thiệu Về Amazon Web Service (AWS)

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.

Blog where we tell stories and share IT knowledge