Domain Driven Design

Chào các bạn! Sau 1 khoảng thời gian làm việc theo hướng thiết kế micro services và domain driven design, tôi cảm thấy đây là một cách tư duy mới để xây dựng phần mềm. Thực tế DDD không mới ở Việt Nam và có nhiều ứng dụng đã apply tư tưởng này vào trong các dự án, tuy nhiên để tìm được 1 ví dụ thực tế và giúp các bạn hiểu được tổng quan DDD và các áp dụng nó như thế nào thì thực tế là không nhiều. Các kiến thức tổng quan về DDD ở trên mạng rất nhiều nếu tôi đi copy lại các bài viết thực sự là điều không cần thiết với các bạn

Tôi sẽ gửi tới các bạn 1 ví dụ rất cụ thể của mình đã áp dụng DDD như thế nào và các công nghệ tôi đã áp dụng

Frederick DDD - Mã nguồn trên github

Đây là một project opensource và mục tiêu của dự án này là vận dụng các công nghệ được sử dụng phổ biến nhất và chia sẻ với mọi người cách tốt nhất để phát triển các ứng dụng tuyệt vời với .NET (Cụ thể mình đang ứng dụng trên nền tảng .NET Core)

How to use

  • Các bạn cần có Visual studio 2017 và cài .NET Core SDK (2.1.2)
  • Trong project các bạn cần xem lại cấu hình của dự án với SDK trên máy hiện tại đã khớp hay chưa
  • SDK mới nhất các bạn có thể download tại đây https://dot.net/core.

Technologies

  • ASP.NET Core 2.0 (with .NET Core)
  • ASP.NET WebApi Core
  • Entity Framework Core 2.0
  • .NET Core Native DI
  • AutoMapper
  • FluentValidator
  • MediatR
  • Swagger UI

Về các công nghệ này đều là các công nghệ không có gì xa lạ với tất cả mọi người, mình sẽ giải thích vắn tắt các công nghệ này cho mọi người

  • ASP.NET Core được ra mắt cùng .NET Core giúp các bạn code ASP.NET MVC giờ có thể chạy được đa nền tảng, nếu các bạn triển khai các dịch vụ trên cloud thì các bạn có thể hiểu được giá trị của .NET Core, chi phí giảm cực nhiều khi triển khai trên LINUX so với WINDOWS SERVER
  • ASP.NET WebApi Core cũng giống như ASP.NET Core để tạo ra các API, mà các bạn cũng đã biết WEB API cũng giống Restfull Services base trên HTTP Request và HTTP Response, bạn nào viết WEB API 1.0 thì rất quen thuộc với ASP.NET Core WEB API cũng tương tự vậy đơn giản là có thể chạy được trên đa nền tảng
  • Entity Framework core 2.0 giống như EF framework nhưng chạy trên .NET Core bạn nào code EF nhiều sang bên EF Core cũng sẽ không gặp nhiều vướng mắc nhưng do lib convert qua .NET Core nên vẫn chưa đầy đủ
  • .NET Core Native DI bạn nào làm nhiều về Dependency Injection thì sẽ không có nhiều xa lạ, khái niệm của nó nôm na là như thế này đây là một cách để hiện thực Inversion of Control Pattern (Có thể coi nó là một design pattern riêng cũng được). Các module phụ thuộc (dependency) sẽ được inject vào module cấp cao.
  • AutoMapper là một thư viện có sẵn trên nuget support vụ mapping giữa các model với dto, model với model, cứ là cần tới vụ mapping là xài ông này.
  • FluentValidator thằng này cũng là 1 lib có trên nuget dùng để validate theo rules, setup rules rất linh hoạt, xài ông này ở tầng Business Layer hay là Domain Layer để validate các nghiệp vụ
  • MediatR thằng này cũng mới mới cũng mới có trên .NET Core thằng này thực hiện theo đúng Mediator pattern. Về Mediator Patern (mô hình trung gian) được sử dụng để giảm sự phức tạp trong "giao tiếp" giữa các lớp và các đối tượng. Mô hình này cung cấp một lớp trung gian có nhiệm vụ xử lý thông tin liên lạc giữa các tầng lớp, hỗ trợ bảo trì mã code dễ dàng bằng cách khớp nối lỏng lẻo. Ví dụ Tháp điều khiển tại sân bay có kiểm soát là một ví dụ về hoạt động của Mediator pattern. Các phi công của các máy bay đang cất cánh hoặc hạ cánh kết nối với tháp chứ không phải giao tiếp rõ ràng với nhau. Những khó khăn về việc ai có thể cất hoặc hạ cánh được thi hành bởi tháp điều khiển. Điều quan trọng cần lưu ý là tháp không kiểm soát toàn bộ chuyến bay. Nó tồn tại chỉ để thực thi các quy định an toàn trong lúc cất và hạ cánh.
  • Swagger UI thằng này quá quen thuộc với ae nào code web api, tạo ra 1 giao diện cho phép xem được đầy đủ tất cả các API, và try it out thay cho vụ xài thằng postman

Architecture

  • Domain Driven Design (Application Layer, Domain Layer, Infrastructure Layer)
  • Domain Events
  • Domain Notification
  • CQRS (Command Query Responsibility Segregation)
  • Event Sourcing
  • Unit of Work
  • Repository and Generic Repository

Phần này thực sự là trọng tâm của dự án, thực tế làm gì thì làm mọi người phải đồng ý với mình là cơ sở lý thuyết phải chắc chắn, giờ anh em lập trình cũng đã qua cái thời tiếp cận theo kiểu data driven design giờ họ đã chuyển qua hướng domain driven design

  • DDD là gì thì thực tế google anh em tìm thấy rất nhiều nôm na Domain-driven design (DDD) là một cách tiếp cận cho phát triển các phần mềm phức tạp; sự phức tạp ở đây là do nghiệp vụ của lĩnh vực kinh doanh (domain business). Cách tiếp cận của DDD là kết nối chặt chẽ việc cài đặt phần mềm với sự tiến hoá của mô hình kinh doanh. Dự án đặt sự chú trọng nhiều cho phần nghiệp vụ chính (core domain) và các logic nghiệp vụ liên quan.
  • Domain Events Bản chất của Domain Event là bạn sử dụng nó để nắm bắt những thứ có thể kích hoạt thay đổi trạng thái của ứng dụng mà bạn đang phát triển. Các event objects này sau đó được xử lý theo một nhiệm vụ cụ thể nào đó và được lưu trữ thành nhật ký. Một ví dụ cụ thể như sau bạn tạo mới một người dùng và bạn cần log lại thông tin vào bảng history và send email cho người dùng đó là mày đã được tạo account, thì ở đây cái vụ log và vụ send email thì ko có liên quan tới vụ bạn thông báo à tao tạo thành công tài khoản cho mày rồi đấy, cái vụ gửi email hay log là hệ quả của việc tạo account thành công chính vì vậy, khi tôi tạo thành công 1 account tôi ngay lập tức send về api là ok rồi và api trả về người dùng thành công rồi, còn vụ send email hay log history nằm tại domain sẽ có raise 1 event send email và logging để xử lý phần này, người dùng ko cần biết là ông có logging thành công hay không hay send email hay không tôi chỉ quan tâm là tài khoản của tôi nó đã được tạo hay chưa
  • Domain Notification là một cách bạn đẩy các expection hoặc nội dung dữ liệu nào đó từ domain layer lên presentation layer, ví dụ có lỗi xảy ra ở domain layer đi thì thông thường là anh em hay return lỗi hoặc là throw lên trên nhưng mình ko sử dụng cách này mình coi như notification như một event, tôi có lỗi tôi sẽ raise event là notification với nội dung như này như kia và ông presentation layer capture xem các lỗi là như thế nào và thông báo cho người dùng
  • CQRS (Command Query Responsibility Segregation) cái vụ này cũng đã nhiều anh em viết rồi, CQRS là cái cách mà tôi chia 2 luồng nghiệp vụ CUD ra 1 góc và R ra 1 góc, nôm na là như thế này CUD là create update delete những thao tác mà làm thay đổi state của entity, còn read thì không nên tôi cần tách nó làm 2 luồng độc lập nhau, theo mô hình tiêu chuẩn thì CUD sẽ thao tác với CSDL sau đó sẽ được đồng bộ sang 1 DB khác ví dụ như redis để làm tăng hiệu suất của việc R dữ liệu nên việc chia 2 luồng CUD và R mình thấy thực tế rất hay, đáp ứng rất tốt cho các ứng dụng cần hiệu suất cao, còn ứng dụng của bạn đơn giản hay như ví dụ của mình thì chỉ là cách mình làm code nó clean và rõ ràng
  • Event Sourcing là giống như CQRS cũng là optional có cũng được không có cũng được, thằng này là làm nhiệm vụ khi bạn CUD tức là làm thay đổi state của 1 entity mình log lại để sau này sử dụng nó để migrate sang database khác để làm nhiệm vụ read data, trong ví dụ của mình mình cũng làm demo luôn Event Sourcing cho các bạn xem cách nó vận hành như thế nào, chỉ có điều mình không có vụ migrate log sang 1 hệ thống khác cho các bạn xem
  • Unit of Work cái này thì đơn giản rồi UOW được sử dụng để đảm bảo nhiều hành động như insert, update, delete...được thực thi trong cùng một transaction thống nhất. Nói đơn giản hơn, nghĩa là khi một hành động của người dùng tác động vào hệ thống, tất cả các hành động như insert, update, delete...phải thực hiện xong thì mới gọi là một transaction thành công. Gói tất cả các hành động đơn lẻ vào một transaction để đảm bảo tính toàn vẹn dữ liệu.
  • Repository bạn nào code nhiều thì cũng hiểu nó làm cái gì Repository Pattern là lớp trung gian giữa tầng Business Logic và Data Access, giúp cho việc truy cập dữ liệu chặt chẽ và bảo mật hơn. Repository đóng vai trò là một lớp kết nối giữa tầng Business và Model của ứng dụng. Thông thường thì các phần truy xuất, giao tiếp với database năm rải rác ở trong code, khi bạn muốn thực hiện một thao tác lên database thì phải tìm trong code cũng như tìm các thuộc tính trong bảng để xử lý. Điều này gây lãng phí thời gian và công sức rất nhiều.

Contact us/ Instant feedback

skype: ducthang24
mail: ducthang.se.gr@gmail.com

Bình luận


White
{{ comment.user.name }}
Bỏ hay Hay
{{comment.like_count}}
Male avatar
{{ comment_error }}
Hủy
   

Hiển thị thử

Chỉnh sửa

White

Thang Nguyen

1 bài viết.
24 người follow
Kipalog
{{userFollowed ? 'Following' : 'Follow'}}
{{like_count}}

kipalog

{{ comment_count }}

bình luận

{{liked ? "Đã kipalog" : "Kipalog"}}


White
{{userFollowed ? 'Following' : 'Follow'}}
1 bài viết.
24 người follow

 Đầu mục bài viết

Vẫn còn nữa! x

Kipalog vẫn còn rất nhiều bài viết hay và chủ đề thú vị chờ bạn khám phá!