Giaosucan's blog - Chia sẻ kiến thức theo cách bá đạo

Ticker

20/recent/ticker-posts

Hiểu Domain Design theo cách bá đạo - part 1

Image result for domain driven design

Trong thiết kế kiến trúc Microservice, có thể bạn sẽ được nghe nhiều về thuật ngữ Domain Driven Design, một phương pháp thiết kế phần mềm theo hướng business domain. Phương pháp này được giới thiệu bởi Eric Evan, viết thành một cuốn sách dày cộp bán trên Amazon, mình đã đọc cuốn sách này cả phiên bản tiếng Anh và tiếng Việt. Tuy nhiên câu từ trong cuốn này xác cmnd là éo hiểu gì, chữ viết như giun bò, kiến chạy, dài dòng lê thê, có lẽ cỡ như Bill Gate mới hiểu được.Thế rồi một đêm xem xvideo, lướt vài vòng webtretho nghe các mẹ tâm sự chuyện tâm sinh lý, mình mới chợt ngộ ra bí ẩn trong cuốn sách của Eric Evan, quả là một bầu trời kiến thức, bài viết này sẽ mô tả lại phương pháp này một cách giản đơn, để cỡ như JAV idol như Yuina Hatano cũng hiểu được

Vì sao lại đẻ ra DDD (Domain Driven Design)

Giả sử một anh dev được giao nhiệm vụ phát triển một ứng dụng bán hàng online. Thanh niên coder thì sẽ áp dụng mô hình quen thuộc MVC hay MVVM

Image result for Model view controller source

Nhìn source code thì kiểu thế này

Image result for Model view controller source structure

OK, cool, tuy nhiên đem cấu trúc này cho một BA (Business Analysis) thì anh ta lại không hiểu controller, view là cái giề. Anh ấy chỉ biết về nghiệp vụ bán hàng, order online, thanh toán thì đi theo flow abc, xyz. Còn chú coder thì biết mỗi Java, .NET design pattern. Kiểu nhưng 1 anh tàu nói tiếng Chinese với 1 anh US. Như vậy phải có 1 phương pháp nào đó để anh dev và anh BA có thể ngồi được với nhau sử dụng 1 ngôn ngữ chung để cả 2 có thể hiểu, và Domain Driven Design ra đời.

DDD là gì

DDD không phải là công nghệ gì cả, nó là một design pattern, một phương pháp thiết kế phần mềm, nhìn trên góc độ architect. Trong đó ứng dụng sẽ được chia thành 4 layer như ở dưới

architect

Đoạn định nghĩa này lấy nguồn trên internet cho nhanhUser  Interface Layer:  làm nhiệm vụ biểu diễn thông tin trực quan cho user và dịch các user command ( ở đây chúng ta có thể hiểu là các event xảy ra trên giao diện khi được trigger ( nhấn nút trên các UI input control ) là các sẽ được dịch thành các command xử lý ở các tầng dưới.Application Layer: Tầng này được thiết kế khá mỏng ( thin ) với ít logic xử  lý chỉ để làm nhiệm vụ coordinate các Activity của Application và không chứa Business Logic, nó không chứa state của các Business Object mà chỉ chứa state của Application Task Progress. Chúng ta có thể hình dung phần này gần giống với các Controller trong mô hình MVC chỉ làm nhiệm vụ forward các task đến nơi cần xử lý.Domain Layer: Đây là trái tim của ứng dụng ( Business Software ), các  state của Business Object đều nằm ở đây. Việc lưu trữ ( persistence ) các Business Object và các state của nó được chuyển giao cho tầng Infrastructure ở dưới.Trái tim của mô hình này chính là ở phần Domain Layer, các nghiệp vụ sẽ được mô tả tại đây, và cấu trúc source code cũng được tổ chức theo tên các nghiệp vụ chứ không để kiểu view, controller như truyền thốngChẳng hạn như Order App thì chia thành thư mục hướng nghiệp vụ như Buyer, Order… Như vậy anh BA nhìn vào có thể hiểu ngay là app này có chức năng gì

Image result for domain driven design source structure

Infrastructure Layer:  Đóng vai trò cung cấp thư viện ( supporting libraries )cho các tầng khác. Nó cung cấp cơ chế giao tiếp ( communication ) giữa các Layer  với nhau, cũng như cung cấp các chức năng khác như lưu trữ ( persistence ) các Business Object của tầng Domain.Cái tầng Infrastructure Layer dễ làm người đọc lầm lẫn sang hạ tầng phần cứng như máy chủ, database server, nhưng thật ra không phải, do chú tây viết sách thích tỏ ra nguy hiểm. Còn trong DDD, layer này có thể hiểu như tầng common library như logging, utility và phần data persistent layer của tầng Data Access trong mô hình thông thường, tức là vẫn chỉ là phần mềm

DDD vs Mô hình 3 lớp truyền thống

So sánh DDD với mô hình 3 lớp truyền thống có thể ví như cái nhà ống 3 tầng có cấu thang bộ với nhà 4 tầng có thêm thang máyMô hình 3 lớp truyền thống, tầng 3 (Presentation) muốn xuống tầng 1 (Data Tier) phải qua tầng 2 Business Tier

Image result for 3 layer architecture

Mô hình DDD thì tầng 4 (UI) muốn xuống tầng 1 (Persistence) có thể qua thang máy là (Infrastructure) để xuống luôn cho nhanh, có muốn tập thể dục thì đi tuần tự từng tầng như truyền thống.

Image result for Domain driven architecture

Thuật ngữ trong DDD

Mỗi lĩnh vực (domain) trong cuộc sống đều có thuật ngữ khác nhau. Dramma hàn quốc thì có thuật ngữ như uppa, ung thư. Kiếm hiệp Hoa Ngữ thì có tuyệt chiêu, bí kíp, kiếm pháp. Chính trị thì có tư tưởng HCM, lý luận Đặng Tiểu Bình, cách mạng, đường lối chính sách. DDD cũng có những thuật ngữ riêng như Entity, Value Object, Aggregate vân vân và mây mây. Cuốn sách của Evic giải thích thì vô cùng khó hiểu. Tuy nhiên giaosucan’s blog sẽ giải thích dần dần cho các bạn những thuật ngữ này theo cách đơn giản nhất trong các phần sau…(Còn tiếp)

Đăng nhận xét

5 Nhận xét

  1. lmao,
    thank giaosucan. Đọc blog cười phọt rắm :)

    Trả lờiXóa
  2. Bài viết thân thiện quá, đọc dễ hiểu, dễ nhớ.
    Mình thích nhất phần so sánh "thang bộ", "thang máy", 2 cái hành lang chạy dọc ^^

    Trả lờiXóa
  3. Dạy nhằng dạy nhịt, Ko hiểu thì đừng đi chia sẻ bậy bạ làm người khác hiểu sai

    Trả lờiXóa