DDD và các đối tượng giá trị. Các đối tượng giá trị có thể thay đổi là một ứng cử viên tốt cho Non Aggr. Thực thể gốc?

Đây là một vấn đề nhỏ

Có một thực thể, với một đối tượng giá trị. Không thành vấn đề. Tôi thay thế một đối tượng giá trị cho một đối tượng mới, sau đó nhibernate chèn giá trị mới và mồ côi đối tượng cũ, sau đó xóa nó. Ok, đó là một vấn đề.

Bảo hiểm là thực thể của tôi trong miền của tôi. Anh ta có một bộ sưu tập Địa chỉ (đối tượng giá trị). Một trong những địa chỉ là MailingAddress. Khi chúng tôi muốn cập nhật địa chỉ gửi thư, giả sử mã zip bị sai, theo học thuyết của ông Evans, chúng tôi phải thay thế đối tượng cũ cho một địa chỉ mới vì nó không thay đổi (một đối tượng giá trị phải không?).

Nhưng chúng tôi không muốn xóa hàng này, vì PK của địa chỉ đó là FK trong bảng MailingHistory. Vì vậy, theo học thuyết của ông Evans, chúng tôi gặp khá nhiều khó khăn ở đây. Trừ khi tôi thực hiện địa chỉ của mình Thực thể, vì vậy tôi không phải "thay thế" nó, và chỉ cần cập nhật thành viên mã zip của nó, như những ngày tốt đẹp cũ.

Bạn sẽ đề nghị gì cho tôi trong trường hợp này? Theo cách tôi thấy, ValueObjects chỉ hữu ích khi bạn muốn gói gọn một nhóm các cột của bảng cơ sở dữ liệu (thành phần trong nhibernate). Mọi thứ có id liên tục trong cơ sở dữ liệu, tốt hơn hết là biến nó thành một Thực thể (không nhất thiết phải là một gốc tổng hợp) để bạn có thể cập nhật các thành viên của nó mà không cần tạo lại toàn bộ biểu đồ đối tượng, đặc biệt nếu đó là một đối tượng được lồng sâu.

Bạn có đồng ý không? Được ông Evans cho phép có một đối tượng giá trị có thể thay đổi? Hoặc là một đối tượng giá trị có thể thay đổi là một ứng cử viên cho một Thực thể?

Cảm ơn

Mọi thứ có danh tính phải là một Thực thể và mọi thứ không có danh tính là một giá trị đơn giản, do đó là một đối tượng giá trị.

Để trích dẫn Martin Fowler (lần lượt nói về Eric Evans)

• Thực thể: Các đối tượng có bản sắc riêng biệt chạy qua thời gian và các biểu diễn khác nhau. Bạn cũng nghe thấy những thứ gọi là "đối tượng tham chiếu".
• Đối tượng giá trị: Các đối tượng quan trọng chỉ có sự kết hợp các thuộc tính của chúng.

Lý do biến địa chỉ của bạn thành Đối tượng Giá trị:

Nếu địa chỉ của bạn có thể thay đổi, cuối cùng bạn sẽ làm hỏng lịch sử gửi thư của mình. Ví dụ: nếu bạn đang vận chuyển các mặt hàng cho khách hàng, bạn không thể chắc chắn địa chỉ nào bạn thực sự đã gửi một thứ gì đó trong quá khứ nếu địa chỉ mà bảng MailingHistory của bạn đề cập đã bị thay đổi.

Mục nhập MailingHistory Chúng tôi đã chuyển A764 đến địa chỉ 657 có nghĩa là Chúng tôi đã chuyển bài viết A764 đến Boston ngày hôm qua và chúng tôi đã chuyển bài viết A764 đến New York vào ngày mai.

Nếu địa chỉ gửi thư phải được thay đổi, không cần phải xóa địa chỉ cũ. Giữ nó và đánh dấu nó là không hoạt động , và cái mới là hoạt động .

Tất nhiên bạn có thể coi địa chỉ của mình là một Thực thể, nhưng chỉ khi cập nhật, nó sẽ không thay đổi địa điểm thực tế mà địa chỉ đang đề cập, do đó chỉ cho phép sửa lỗi chính tả.

Nếu bạn chắc chắn rằng bạn có thể đảm bảo rằng, hơn là sử dụng một Thực thể sẽ có thể.

Nhưng giải pháp tốt nhất IMHO là không giới thiệu một địa chỉ Thực thể trong lịch sử gửi thư của bạn, mà là lưu địa chỉ cụ thể trực tiếp trong bảng lịch sử gửi thư của bạn (về cơ bản sao chép dữ liệu của địa chỉ).

Bằng cách này, bạn luôn biết nơi bạn gửi đồ đạc của mình (hoặc bất cứ thứ gì bạn đang gửi thư) và vì bạn sẽ sử dụng một Thực thể có thể thay đổi, bảng địa chỉ của bạn sẽ không bị lộn xộn.

Tôi đã làm việc với / trên một số hệ thống ERP và gần như tất cả chúng đều sử dụng phương pháp này.

Bạn sẽ có một số dự phòng trong cơ sở dữ liệu của mình, nhưng đó là cách thực tế nhất IMHO.

Tôi thấy 2 điều:

1. Thay đổi mã Zip có ảnh hưởng đến hồ sơ lịch sử không? Tôi nghĩ rằng sẽ là hợp lý khi bản ghi lịch sử trỏ đến địa chỉ cũ, không thay đổi, vì vậy bạn biết bạn gửi nó đến địa chỉ sai.

2. Khoảnh khắc MailingHistory có FK trên địa chỉ địa chỉ dừng lại là một đối tượng giá trị và trở thành thực thể. Các đối tượng giá trị không có danh tính, cho phép các thực thể khác tham chiếu danh tính này. Bạn có thể có địa chỉ trong một bảng với các bảng khác trỏ đến nó, nhưng chỉ có tác dụng là tiết kiệm không gian. Từ quan điểm tên miền, nếu hai thực thể có cùng loại đối tượng giá trị tham chiếu, thì chúng không chia sẻ bất kỳ loại thông tin nào.

IMO đối tượng địa chỉ là một thực thể trong miền của bạn. Nó được chia sẻ bởi nhiều thực thể, có bản sắc riêng và là duy nhất trên toàn hệ thống.

Evans nói:

Một đối tượng được xác định chủ yếu bởi danh tính của nó được gọi là một thực thể.