Trong những năm qua, với sự phát triển không ngừng của ngành công nghiệp phần mềm, các hệ thống phần mềm ngày càng trở nên phức tạp và khó bảo trì hơn. Tại thời điểm này, ngày càng nhiều nhóm phát triển bắt đầu chọn thực hành thiết kế dựa trên miền DDD. Thiết kế hướng miền là một ý tưởng thiết kế phần mềm rất xuất sắc. Nó có thể giúp chúng ta sắp xếp các hoạt động kinh doanh phức tạp và giải quyết việc thiết kế, phát triển, cập nhật và bảo trì các hệ thống kinh doanh quy mô lớn. Tuy nhiên, chi phí học theo miền rất cao, khiến nhiều sinh viên khó hiểu chính xác về DDD và khó thực hiện thiết kế và mã hóa các dự án thực tế. Vì mục đích này, thông qua loạt bài chia sẻ kiến thức này, tôi muốn mọi người hiểu một cách thực sự và chính xác những khái niệm mơ hồ này trong DDD, đặc biệt là cách chúng được triển khai cuối cùng trong thiết kế và phát triển các dự án phần mềm.

Hôm nay, trước tiên chúng ta thảo luận về khái niệm rắc rối và khó hiểu nhất trong DDD - "đối tượng giá trị" là gì? Để hiểu ý tưởng thiết kế về "đối tượng giá trị", trước tiên chúng ta hãy phân loại ý tưởng cốt lõi của điều khiển miền. Domain-driven tin rằng bản chất của phần mềm là sự mô phỏng của thế giới thực. Tiêu chí duy nhất để xác định liệu tất cả logic nghiệp vụ trong phần mềm có đúng hay không là liệu nó có nhất quán với thế giới thực hay không. Nếu chúng nhất quán thì thiết kế sẽ ổn, nếu không người dùng sẽ đưa ra lỗi hoặc thay đổi yêu cầu. Miễn là chúng ta hiểu được bản chất này thì thiết kế phần mềm rất đơn giản: trước tiên chúng ta hiểu hoạt động kinh doanh trong thế giới thực và sau đó hình thành sự hiểu biết của chúng ta về hoạt động kinh doanh thành thiết kế phần mềm.

Tuy nhiên, có một câu hỏi ở đây, đó là phần mềm tương ứng với thế giới thực như thế nào? Sự tương ứng này được thể hiện ở ba khía cạnh sau:

1) Dù có gì trong thế giới thực thì sẽ có đối tượng trong thế giới phần mềm;

2) Những thứ này có những hành vi gì trong thế giới thực và những đối tượng này trong thế giới phần mềm có những phương pháp gì;

3) Mối quan hệ giữa những thứ này trong thế giới thực là gì và mối quan hệ giữa những đối tượng này trong thế giới phần mềm là gì.

Do đó, khi thiết kế phần mềm, trước tiên chúng tôi sử dụng các kịch bản kinh doanh làm đơn vị để phân tích từng đối tượng miền trong từng kịch bản kinh doanh cũng như hành vi và mối quan hệ của chúng với nhau để tạo thành một mô hình miền. Sau đó lấy mô hình miền làm cốt lõi để hoàn thiện việc thiết kế và phát triển phần mềm.

Ví dụ: nếu chúng ta muốn thiết kế một hệ thống thương mại điện tử, nó sẽ được chia thành nhiều chức năng tùy theo nhu cầu kinh doanh và mỗi chức năng là một kịch bản kinh doanh. Ví dụ: trong kịch bản kinh doanh "đặt hàng", những thứ trong thế giới thực là gì? Đầu tiên là "đơn hàng", có thể tạo thành một đối tượng đơn hàng; mỗi đơn hàng tương ứng với một người dùng, nhưng một người dùng có thể có nhiều đơn hàng, do đó có mối quan hệ "nhiều-một" từ đơn hàng đến người dùng; địa chỉ, nhưng một đơn hàng chỉ có thể tương ứng với một địa chỉ...Như được hiển thị bên dưới, chúng tôi thực hiện theo các bước sau để phân tích từng đối tượng miền và mối quan hệ giữa chúng. Cuối cùng, chúng ta phải làm gì với đơn hàng? Có "đặt hàng", "thanh toán", "xem đơn hàng"...

Đây là mô hình miền. Các lớp như đơn hàng, người dùng, địa chỉ, chi tiết đơn hàng, v.v. đều là các đối tượng miền. Tuy nhiên, trong DDD, các đối tượng miền phải được phân chia chặt chẽ thành "thực thể" và "đối tượng giá trị". Lúc này, nhiều học sinh đang bối rối, thực thể là gì? Đối tượng giá trị là gì? Để hiểu chính xác nơi này, trước tiên chúng ta hãy xem cuốn sách gốc "Thiết kế hướng tên miền" nói gì.

Thực thể: Còn được gọi là Đối tượng tham chiếu, nó có vòng đời và trong vòng đời, hình thức và nội dung của nó có thể thay đổi, nhưng danh tính của nó sẽ không bao giờ thay đổi. Điều đó có nghĩa là, mỗi thực thể có một mã định danh duy nhất, chẳng hạn như ID người dùng, được sử dụng để phân biệt "anh ấy" với những người khác trong thế giới thực. Các thực thể có vòng đời, chẳng hạn như đăng ký và hủy bỏ người dùng; mọi thứ trong thực thể có thể thay đổi, ví dụ: Xiao Zhang đã chuyển tài khoản của mình cho Li Si, nhưng ID tài khoản sẽ không thay đổi. Mã định danh duy nhất này là khóa chính Trong hình thức thiết kế này, người dùng có ID người dùng, tài khoản có ID tài khoản và đơn hàng có ID đơn hàng, đây là thiết kế của các thực thể. Rõ ràng, mọi người đều có thể hiểu được thiết kế này và mấu chốt là "đối tượng giá trị".

Đối tượng giá trị: Việc mô tả các đối tượng giá trị trong cuốn “Thiết kế hướng miền” tương đối mù mờ, nhưng chúng ta có thể tóm tắt đại khái thành các đặc điểm sau: phần khai báo đối tượng và các thuộc tính trong đối tượng đều không thay đổi và có thể được tham chiếu và chia sẻ bởi nhiều đối tượng (chứ không phải sao chép), đây là "đối tượng giá trị". Làm thế nào để hiểu những đặc điểm này?

Ví dụ: trong thế giới thực, người dùng có thể có nhiều đơn hàng, vì vậy khi truy vấn đơn hàng, mỗi đơn hàng là một đối tượng đơn hàng và mỗi đối tượng đơn hàng có ID đơn hàng khác nhau. Vì vậy, việc thiết kế đơn đặt hàng là một thực thể. Tuy nhiên, mỗi đơn hàng phải tham chiếu đến một người dùng, trỏ đến một đối tượng người dùng. Vậy ai thực hiện nhiều đơn hàng từ cùng một người dùng trỏ tới? Rõ ràng, người dùng này không thể được sao chép vào nhiều đối tượng, nhưng tất cả các lệnh này đều đề cập đến một đối tượng này. Nói cách khác, đối tượng "người dùng" ở đây là một đối tượng giá trị.

Tuy nhiên, đối tượng giá trị phải là bất biến. Nghĩa là, nếu "người dùng" là một đối tượng giá trị thì người dùng và các thuộc tính liên quan của nó phải là bất biến. Nhưng thực tế là người dùng và thông tin người dùng của họ có thể thay đổi và chúng tôi sẽ thêm, xóa và sửa đổi thông tin người dùng. Đúng vậy, trong thế giới thực, mọi thứ đều thay đổi và không có gì giữ nguyên. Vậy làm thế nào để hiểu được tính bất biến của các đối tượng giá trị?

Trong mô hình miền DDD, ngoài mô hình miền, còn có một thiết kế rất quan trọng gọi là "bối cảnh giới hạn". Mô hình miền mô tả thế giới thực, nhưng thế giới thực là vô hạn Vậy mô hình miền mô tả thế giới thực như thế nào? DDD chia hoạt động kinh doanh của một hệ thống phức tạp thành nhiều bối cảnh bị giới hạn và sau đó thực hiện mô hình hóa miền trong từng bối cảnh bị giới hạn. Theo cách này, mỗi mô hình miền đều có ranh giới riêng và tôi chỉ mô tả hoạt động kinh doanh của mình trong ranh giới này. Kiểu thiết kế này có thể "phân chia và chinh phục" thế giới phức tạp và việc phân tích từng mô hình miền trở nên đơn giản.

Ví dụ: trong trường hợp trên, trước tiên bạn có thể chia việc quản lý người dùng và hồ sơ người dùng của họ thành một ngữ cảnh, được gọi là "bối cảnh người dùng". Trong ngữ cảnh này, người dùng và các thuộc tính của họ có thể thay đổi và cần được thêm, xóa và sửa đổi, do đó thiết kế của đối tượng "người dùng" là một thực thể. Tuy nhiên, trong một "bối cảnh đơn hàng" khác, đơn hàng là một thực thể cần được thêm, xóa hoặc sửa đổi, nhưng "người dùng" và "địa chỉ" được tham chiếu bởi đơn hàng là các đối tượng giá trị. Điều đó có nghĩa là, trong ngữ cảnh đặt hàng, "người dùng" và "địa chỉ" ở chế độ chỉ đọc và chỉ được sử dụng để tham chiếu đối tượng đặt hàng mà không thêm, xóa hoặc sửa đổi chúng. Theo cách này, "người dùng" và "địa chỉ" làm đối tượng giá trị phản ánh tính chất chỉ đọc và bất biến của chúng.

Nếu thiết kế microservice được áp dụng, "cảnh báo người dùng" và "cảnh đặt hàng" sẽ được chia thành các dịch vụ trong mô-đun Người dùng microservice có cơ sở dữ liệu người dùng dữ liệu và microservice set row có đơn cơ sở dữ liệu. Khi microservice đơn hàng muốn truy vấn đơn hàng, nó sẽ lấy đối tượng người dùng liên quan đến đơn hàng bằng cách gọi giao diện của microservice user use. Đây là một khái niệm khái niệm về "giá trị tượng trưng" và việc phát triển thiết kế của họ.

Hoạt động kinh doanh cốt lõi trong bối cảnh là việc bổ sung, xóa và sửa đổi các thực thể, trong khi giá trị đối tượng được nhận liên kết với thực thể và được sử dụng chỉ để tham khảo và truy vấn đặc điểm của các đối tượng. giá trị biểu tượng được đọc chỉ, nhưng có hai dạng hiệu suất trong thực tế dự án:

1) Cần lấy tham chiếu đến các đối tượng trong các dịch vụ khác bằng cách gọi giao diện của các dịch vụ khác. dữ liệu không có trong cơ sở dữ liệu cục bộ của tôi mà chỉ tồn tại trong bộ nhớ và không thể sửa đổi, chỉ được truy vấn;

2) Một số loại thuộc tính từ điển dữ liệu, danh mục, danh mục tương thích, mặc định dữ liệu đã được lưu Ví dụ Ví dụ: thành viên cấp độ, quy tắc tính điểm, phương thức thanh toán, vv

(còn tiếp).

Cuối cùng, bạn đã thực sự hiểu rõ về DDD trong bài viết này chưa? end ở đây. Thêm về DDD, bạn có thực sự hiểu rõ về nó không? tôi hy vọng mong bạn sẽ ủng hộ blog của tôi trong tương lai .