Cập nhật thực thể bên trong tổng hợp

Question

Tôi đã đọc một câu hỏi tương tự trên SO: How update an entity inside Aggregate, nhưng tôi vẫn không chắc chắn cách giao diện người dùng nên tương tác với các thực thể bên trong tổng hợp.

Giả sử tôi có một số User, với một bó là Address es. Người dùng là gốc tổng hợp, trong khi Địa chỉ chỉ tồn tại trong tổng hợp.

Trên web inteface, người dùng có thể chỉnh sửa địa chỉ của mình. Về cơ bản, những gì xảy ra là:

• Người dùng nhìn thấy một danh sách các địa chỉ trên giao diện web của nó
• anh ta nhấp vào một địa chỉ, và được chuyển hướng đến trang này: edit-address?user=1&address=2
• Trên trang này, anh nhận được một hình thức nơi anh ta có thể sửa đổi địa chỉ này.

tôi chúng tôi quyết định bỏ qua các gốc tổng hợp, đây sẽ là đơn giản:

• Chúng tôi sẽ trực tiếp tải các Address với nó Id
• Chúng tôi sẽ cập nhật nó, sau đó lưu nó

Vì chúng tôi muốn thực hiện theo cách DDD, chúng tôi có các giải pháp khác nhau:

1. Hoặc chúng ta hỏi người dùng để có được địa chỉ này bằng cách Id:

   address = user.getAddress(id);
address.setPostCode("12345");
address.setCity("New York");
em.persist(user);

   Vấn đề với phương pháp này là, IMO, rằng gốc tổng hợp vẫn không có quyền kiểm soát nhiều hơn những gì được thực hiện với địa chỉ. Nó chỉ trả về một tham chiếu đến nó, vì vậy nó không khác nhiều so với việc bỏ qua tổng hợp.

2. Hoặc chúng ta báo cho tổng hợp để cập nhật địa chỉ hiện có:

   user.updateAddress(id, "12345", "New York");
em.persist(user);

   Bây giờ tổng hợp có quyền kiểm soát những gì đang thực hiện với địa chỉ này, và có thể mất bất kỳ hành động cần thiết mà đi với việc cập nhật địa chỉ.

3. Hoặc chúng tôi xử lý địa chỉ như một đối tượng giá trị , và chúng tôi không cập nhật Address của chúng tôi, nhưng thay vì xóa và tạo lại:

   user.removeAddress(id);
address = new Address();
address.setPostCode("12345");
address.setCity("New York");
user.addAddress(address);
em.persist(user);

   Giải pháp cuối cùng này có vẻ thanh lịch, nhưng có nghĩa là Địa chỉ không thể là Thực thể. Sau đó, nếu cần phải được coi là một thực thể, ví dụ: vì một đối tượng kinh doanh khác trong tổng hợp có tham chiếu đến nó?

Tôi chắc chắn tôi thiếu một số thứ ở đây để hiểu chính xác khái niệm tổng thể và cách sử dụng trong các ví dụ thực tế, vì vậy, vui lòng cho ý kiến ​​của bạn!

Answer 1

Không, bạn không thiếu bất cứ điều gì - trong hầu hết các trường hợp, lựa chọn tốt nhất sẽ là số 2 (mặc dù tôi muốn gọi là phương pháp changeAddress sau đó updateAdress - cập nhật dường như không-DDD) và đó là bất kể một địa chỉ là đối tượng giá trị hoặc đối tượng. Với Ngôn ngữ phổ biến bạn muốn nói rằng Người dùng đã thay đổi địa chỉ của mình, vì vậy đó chính xác là cách bạn nên mô hình hóa - đó là phương pháp changeAddress để quyết định xem thuộc tính cập nhật (nếu Địa chỉ là đối tượng) hay gán đối tượng hoàn toàn mới nó là VO).

Mẫu mã sau đây giả định kịch bản phổ biến nhất - Địa chỉ như VO:

public void ChangeAddress(AddressParams addressParams) 
    { 
     // here we might include some validation 

     address = new Address(addressParams); 

     // here we might include additional actions related with changing address 
     // for example marking user as required to confirm address before 
     // next billing 
    } 

gì là quan trọng trong mẫu này, là một khi Địa chỉ được tạo ra, nó được coi là hợp lệ - không thể có địa chỉ không hợp lệ đối tượng trong tổng hợp của bạn. Tuy nhiên, hãy nhớ rằng bạn nên theo mẫu này hay không phụ thuộc vào miền thực của bạn - không có đường dẫn nào để theo dõi. Đây là một trong những phổ biến nhất mặc dù. Và có, bạn nên luôn luôn thực hiện các thao tác trên thực thể của mình bằng cách duyệt qua gốc tổng hợp - lý do cho điều này được đưa ra trong nhiều câu trả lời trên SO (ví dụ: trong Basic Aggregate Question) này.

Cho dù điều gì đó là một thực thể hay VO phụ thuộc vào các yêu cầu và miền của bạn. Hầu hết địa chỉ thời gian chỉ là một đối tượng giá trị, vì không có sự khác biệt giữa hai địa chỉ có cùng giá trị và địa chỉ có xu hướng không thay đổi trong suốt cuộc đời của chúng. Nhưng một lần nữa, đó là phần lớn thời gian và phụ thuộc vào miền bạn đang lập mô hình.

Ví dụ khác - đối với hầu hết các tên miền, Money sẽ là đối tượng giá trị - 10 $ là 10 đô la, không có danh tính ngoài số tiền. Tuy nhiên, nếu bạn mô hình hóa một tên miền giao dịch bằng tiền trên một mức hóa đơn, mỗi hóa đơn sẽ có bản sắc riêng của nó (được biểu thị bằng một số duy nhất của một số loại) vì vậy nó sẽ là một Thực thể.