I'm Anh, from 🇻🇳 and be a 👨💻, like to build a system by DDD.
Currently have interested in System Design 👷 🏗️ , Terraform and AWS.
I'm Anh, from 🇻🇳 and be a 👨💻, like to build a system by DDD.
Currently have interested in System Design 👷 🏗️ , Terraform and AWS.
Nên cân nhắc những gì cần thiết phải đưa vào model cũng như những gì không cần thiết phải đưa vào model.
Ta lấy ví dụ với model Resume
, ta cần đưa vào nó những thông tin quan trọng
sau đây:
Còn những yếu tố dưới đây được coi là những yếu tố không quan trọng
:
Với các rules hay business logic thì khi ta có ý tưởng hay một sáng kiến nào đó về chúng, hãy viết ra dưới dạng các gạch đầu dòng.
Tiêu biểu ở đây ta có thể viết dưới dạng sơ đồ chuyển trạng thái
. Trình bày dưới dạng sơ đồ sẽ dễ hiểu hơn so với viết chữ rất nhiều. Với những trường hợp như vậy ta có thể kết hợp giữa sơ đồ chuyển trạng thái
với sơ đồ domain model
.
Khi ghi chép để biểu thị các Aggregate (kết tập), ta cần thể hiện được mối liên hệ giữa các objects, do đó việc phân biệt các object ở trong / ngoài kết tập là rất quan trọng do chúng sẽ có cách biểu thị khác nhau.
association
để trỏ đến object được tham chiếuLưu ý: 2 kí hiệu association
, composition
đều là kí hiệu dùng trong UML. (Ref: tuananhhedspibk/TeckStack#95)
Nếu model và software triển khai nó có một sự khác biệt đáng kể thì việc giải quyết vấn đề (vốn dĩ là nhiệm vụ chính của model) sẽ ngày một khó hơn.
Không những thế, việc đọc code để hiểu được model cũng trở nên khó khăn hơn.
Do đó hãy giữ cho code và model ở "gần nhau" nhất có thể, và cũng vì lí do này mà DDD hỗ trợ OOP rất mạnh.
Ta có thể thấy những thiết kế rất tốt với:
Light DDD
, thế nhưng nếu chúng không giúp software giải quyết được những bài toàn trong thực tế thì cũng không có ý nghĩa gì cả.Thế nên trong thực tế hãy áp dụng:
Các xử lí giao tiếp với UI
và DB
không nên "được trộn lẫn" vào phần code của model. Lí do là vì khi đó:
Do đó các xử lí liên quan đến UI
hay DB
, ... và code của model nên được phân chia thành các tầng riêng biệt. Tầng đảm nhiệm model được gọi là tầng domain
.
Về cơ bản ta sẽ thấy 3 loại kiến trúc sau thường xuất hiện trong thực tế:
Là sơ đồ mô tả các hành động của hệ thống nhằm đáp ứng yêu cầu từ phía người dùng.
Lấy ví dụ với ứng dụng quản lí task, ta sẽ có sơ đồ usecase như sau:
Sơ đồ use-case
sẽ được tạo ra trước sơ đồ domain model
. Vậy tại sao ta lại cần sơ đồ use-case. Sau đây là lí do:
Ngoài ra ta cũng cần phải quyết định scope của sơ đồ domain model
, lí dó là vì nếu không quyết định scope của domain model thì có thể dẫn tới tình trạng phạm vi của vấn đề sẽ trở nên quá rộng và quá trình thiết kế domain model sẽ không đem lại hiệu quả gì cả.
Khi bắt đầu ta có thể bắt đầu domain model với scope nhỏ, sau đó ta sẽ dần dần scale scope của nó lên cũng được. Khi đó ta cũng cần phải scale scope của sơ đồ use-case lên để tạo sự đồng bộ.
Về bản chất đây là sơ đồ được đơn giản hoá từ sơ đồ class. Nó sẽ chứa các yếu tố sau:
Sau khi thiết kế Aggregate xong ta có thể quyết định cách thiết kế cũng như triển khai các Repositories.
Bất kể với sơ đồ use-case hay sơ đồ domain model thì khi tiến hành trao đổi ý kiến với các thành viên khác trong team, ta đều nên viết ra white board để mọi người có thể cùng nhau trao đổi ý kiến và hoàn thành các sơ đồ trên.
Với sơ đồ use-case về ứng dụng quản lí task, ta có thể đưa ra sơ đồ domain model như sau:
Ta có thể thấy rằng 1 user có thể có 0..n task và cũng có thể thấy được các rules khi khởi tạo hoặc thay đổi user, task.
Việc tạo ra một model hoàn chỉnh ngay từ đầu là chuyện không thể. Do đó hãy tiến hành vòng tuần hoàn sau:
MODELING → TRY → FIX
Cho đến khi bạn tìm ra được một model ưng ý nhất cho mình. Hơn nữa nếu bạn cần phải đưa ra một thiết kế áp dụng cho nhiều ứng dụng cùng một lúc thì điều này là một điều vô cùng khó và dễ gây chán nản, hãy bắt đầu từ một phần nhỏ trong ứng dụng. Sau khi cảm thấy ổn hãy scale dần lên.
Domain
là lĩnh vực mà phần mềm sẽ giải quyết một vấn đề của nó.
Model
là một hệ thống các abstractions mô tả một khía cạnh của domain và có thể được sử dụng để giải quyết vấn đề liên quan đến domain đó.
Modeling
là quá trình tạo ra một model.
Domain Model
: là model dùng để giải quyết vấn đề của domain.
Data model
: là model dùng để giải quyết vấn đề liên quan đến việc lưu trữ dữ liệu.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.