Có triển khai DDD bởi Vernon: đối tượng giá trị hay không?

Trên trang 382 của cuốn sách này có một đoạn nói về việc sử dụng các đối tượng giá trị trong tập hợp, dưới gốc (thực thể). Có một ví dụ về Productđiều đó, bên cạnh các giá trị khác, chứa một Set<ProductBacklogItem>- tập hợp các thực thể .

Bây giờ, Vernon cố gắng giải thích tại sao ProductBacklogItemlà một thực thể chứ không phải là một đối tượng giá trị:

Có nhiều lý do tại sao ProductBacklogItem được mô hình hóa dưới dạng Thực thể thay vì Giá trị. Như đã thảo luận trong Giá trị đối tượng (6), do cơ sở dữ liệu sao lưu được sử dụng thông qua Hibernate, nên nó phải mô hình hóa các bộ sưu tập Giá trị dưới dạng thực thể cơ sở dữ liệu. Sắp xếp lại bất kỳ một trong các thành phần có thể khiến một số lượng đáng kể, thậm chí tất cả các phiên bản ProductBacklogItem bị xóa và thay thế. Điều đó sẽ có xu hướng gây ra chi phí đáng kể trong cơ sở hạ tầng. Là một Thực thể, nó cho phép thay đổi thuộc tính đặt hàng trên bất kỳ và tất cả các yếu tố bộ sưu tập thường xuyên như chủ sở hữu sản phẩm yêu cầu. Tuy nhiên, nếu chúng ta chuyển từ sử dụng Hibernate với MySQL sang kho lưu trữ khóa-giá trị, chúng ta có thể dễ dàng thay đổi ProductBacklogItem thành loại Giá trị thay thế. Khi sử dụng kho lưu trữ khóa hoặc giá trị tài liệu,

Tôi không hiểu tại sao triển khai Kho lưu trữ xác định xem một số mô hình sẽ là Đối tượng hoặc Đối tượng Giá trị? Nếu chúng ta đến cửa hàng khóa-giá trị, chúng ta vẫn có thể yêu cầu anh ấy nói về.

Bạn có nghĩ rằng điều này có ý nghĩa?

Lý do là cơ sở dữ liệu SQL lưu trữ các đối tượng theo cách quan hệ - các mục được lưu trữ trong bảng khác với gốc tổng hợp và chúng tham chiếu trở lại gốc tổng hợp bằng ID. Vì vậy, việc sử dụng MySQL yêu cầu mô hình hóa các mục như các thực thể được duy trì trong bảng riêng biệt nơi chúng có id chính (với mức tăng tự động).

Trong các cửa hàng khóa-giá trị, ví dụ. MongoDB người ta có thể lưu trữ toàn bộ bộ sưu tập các mục như là một phần của gốc tổng hợp. Các mục sẽ không trở thành các thực thể riêng biệt (trong bảng trên nó) và do đó có thể được mô hình hóa thành các đối tượng giá trị.

Ví dụ. Blog có Bình luận được lưu trữ dưới dạng bộ sưu tập trong:

{
  _id: 1,
  title: 'Some title',
  body: 'Blog body',
  comments: [{
     person: 'John Smith',
     comment: 'First comment of the blog',
     created_at: new Date()
  },
  {
     person: 'Peter Jackson',
     comment: 'Second comment of the blog',
     created_at: new Date()
  }],
}

Tôi biết câu hỏi này có từ vài năm trước, nhưng tôi đã xử lý một vấn đề mô hình tương tự vào lúc này, và có lẽ nó sẽ hữu ích cho người khác để xem những ý kiến ​​thay thế nào đang tồn tại.

Bạn nói đúng, phần này hơi sai lệch và mâu thuẫn, vì đã dành quá nhiều thời gian cho DDD chỉ ra rằng thiết kế tên miền không nên bị chi phối bởi những lo ngại dai dẳng.

Nếu tôi đoán, điều thực sự được nhắc đến là bản chất bất biến của các Đối tượng Giá trị. Trong ví dụ này, ông nói cụ thể về thứ tự của các mục Backlog. Các đối tượng giá trị là bất biến, do đó, việc thay đổi thứ tự của 1 Mục tồn đọng có thể dẫn đến "số lượng đáng kể, thậm chí là tất cả các phiên bản ProductBacklogItem sẽ bị xóa và thay thế".

Vì vậy, mặc dù về mặt kỹ thuật vẫn được điều khiển bởi cơ sở hạ tầng, cuối cùng để duy trì trật tự trong một giải pháp SQL, Đối tượng Giá trị phải có thể thay đổi và do đó không phải là Đối tượng Giá trị. Vấn đề này không tồn tại trong một giải pháp NoQuery trong đó "Các trường hợp tổng hợp thường được tuần tự hóa dưới dạng một đại diện giá trị cho lưu trữ." Vì vậy, bạn không nên để sự kiên trì điều khiển thiết kế của mình, nhưng để cho phép đặt hàng lại, không có cách nào để không có đối tượng là một Thực thể

Đây là nơi mà vấn đề người mẫu của riêng tôi xuất hiện trong bức tranh. Nếu thứ tự của các vật phẩm là quan trọng, thì tôi đã vật lộn với ý tưởng rằng các vật thể đó phải là Thực thể ... bởi vì nếu thứ tự là quan trọng, thì xác định cũng phải quan trọng. I E. Làm thế nào để bạn đặt hàng lại các mặt hàng nếu mỗi người không có một danh tính cụ thể? Nếu thứ tự không quan trọng, thì bây giờ nó chỉ là một bộ sưu tập / túi giá trị, và vì vậy bây giờ chúng có thể là Đối tượng Giá trị.

Cách tiếp cận mà tôi đã xem xét là thứ tự nên được duy trì bởi một Thực thể, trong trường hợp này là OrderedBackLogItem. Nhưng thực thể này chứa Đối tượng Giá trị ProductBacklogItem và thuộc tính đặt hàng.

Các lựa chọn thay thế khác là cách tiếp cận mà Vernon đã thực hiện (một Thực thể) hoặc chính bộ sưu tập là Đối tượng Giá trị, và do đó, toàn bộ danh sách được sắp xếp bị hủy và tạo lại mỗi lần.

Tôi vẫn có hai suy nghĩ về việc liệu mỗi mục trong danh sách có phải là Thực thể hay không nếu việc đặt hàng lại là quan trọng.