Trong thiết kế hướng miền, làm cách nào để chuyển đổi bảng cơ sở dữ liệu với khóa chính thành Đối tượng giá trị?

Giả sử có một lược đồ cơ sở dữ liệu được định nghĩa như thế này:

Person.mail_address_key ----- Address.address_key
Person.billing_address_key ----- Address.address_key

A Personcó một địa chỉ gửi thư và một địa chỉ thanh toán. Là một kỹ thuật không chuẩn hóa, chúng tôi tạo một Addressbảng riêng biệt . Hầu hết thời gian mail_address_keyvà billing_address_keycủa một đơn Personsẽ có cùng một giá trị (nghĩa là: khóa địa chỉ gửi thư và thanh toán của họ sẽ giống nhau).

Trong cơ sở dữ liệu của tôi , Addresscó một danh tính (khóa địa chỉ). Nhưng, trong mô hình miền của tôi , tôi không thấy một lý do thuyết phục nào Addressđể trở thành một Thực thể, tôi muốn nó trở thành Đối tượng Giá trị.

1. Trong DDD, đây có phải là một lựa chọn không? Hay các Đối tượng Giá trị thường là một nhóm các cột (trái ngược với bảng)? Tôi chơi trò bênh vực của quỷ ở đây, vì tôi không nghĩ rằng cơ sở dữ liệu nên ra lệnh cấu trúc mô hình miền, nhưng chỉ cần đảm bảo.
2. Nếu vậy, địa chỉ / khi / làm thế nào để mất địa chỉ cơ sở dữ liệu của nó để nó có thể được sử dụng làm Đối tượng Giá trị trong Lớp Miền? Hoặc, tôi có nên giữ định danh cơ sở dữ liệu trong Đối tượng giá trị không?
3. Khi mô hình cần được duy trì trong cơ sở dữ liệu, quá trình là gì? Tôi có phải trải qua quá trình a) Tìm địa chỉ theo các trường này không, b) nếu nó không tồn tại, hãy tạo địa chỉ mới c) nếu có, cập nhật các trường?

Trong DDD, đây có phải là một lựa chọn không? Hay các Đối tượng Giá trị thường là một nhóm các cột (trái ngược với bảng)? Tôi chơi trò bênh vực của quỷ ở đây, vì tôi không nghĩ rằng cơ sở dữ liệu nên ra lệnh cấu trúc mô hình miền, nhưng chỉ cần đảm bảo.

Cơ sở dữ liệu không nên ra lệnh cấu trúc mô hình miền để bạn chính xác về điều đó. Các đối tượng giá trị có thể được lưu trữ trong cơ sở dữ liệu dưới dạng cột hoặc bảng tùy thuộc vào loại dữ liệu mà đối tượng giá trị được cho là mang theo.

Nếu vậy, địa chỉ / khi / làm thế nào để mất địa chỉ cơ sở dữ liệu của nó để nó có thể được sử dụng làm Đối tượng Giá trị trong Lớp Miền? Hoặc, tôi có nên giữ định danh cơ sở dữ liệu trong Đối tượng giá trị không?

Mã miền của bạn không nên bị đánh đố với các thuộc tính dành cho các mối quan tâm khác như sự kiên trì vì chúng phải hoàn toàn không biết gì. Bạn nên thực sự tập trung vào gốc tổng hợp của bạn. Bạn phải có một số cách để xác định gốc tổng hợp của bạn khi bạn lưu nó trở lại cơ sở dữ liệu, vì vậy, tại thời điểm đó, bạn chỉ cần kiểm tra bản ghi bảng Person (Tôi giả sử Person là gốc tổng hợp của bạn) và xem liệu có một giá trị trong trường MailingAddressID hoặc BillingAddressID. Tại thời điểm đó, bạn có thể quyết định có tạo địa chỉ mới hay không và thay đổi các liên kết để trỏ đến địa chỉ mới hoặc ghi đè lên các địa chỉ đã được liên kết.

Khi mô hình cần được duy trì trong cơ sở dữ liệu, quá trình là gì? Tôi có phải trải qua quá trình a) Tìm địa chỉ theo các trường này không, b) nếu nó không tồn tại, hãy tạo địa chỉ mới c) nếu có, cập nhật các trường?

Như tôi đã giải thích phần nào trong câu trả lời ở trên, bạn nên hydrat hóa và khử hydrat đồ thị đối tượng của bạn dựa trên gốc tổng hợp của bạn. Do đó, khi kho lưu trữ của bạn lấy gốc tổng hợp của bạn từ cơ sở dữ liệu, nó cũng sẽ hydrat hóa tất cả các thực thể và đối tượng giá trị cần thiết dưới gốc tổng hợp của bạn được liên kết với gốc tổng hợp của bạn trong cơ sở dữ liệu. Điều tương tự cũng đúng khi bạn đi lưu gốc tổng hợp trở lại cơ sở dữ liệu. Kho lưu trữ của bạn sẽ có thể xử lý toàn bộ biểu đồ đối tượng của bạn dưới gốc tổng hợp.

DDD hoàn toàn không thực thi lược đồ DB. Đối tượng giá trị có thể được triển khai dưới dạng một nhóm các cột, thực thể db (giải pháp thứ ba của bạn) hoặc đơn giản là ở dạng không chuẩn hóa nếu bạn có thể sử dụng cơ sở dữ liệu hướng tài liệu chẳng hạn. Nó phụ thuộc vào các trường hợp khác nhau, lựa chọn tốt nhất để đi cùng.

Hãy nhớ rằng DB chỉ là một công cụ để duy trì trạng thái tên miền của bạn. Nó không nên ép buộc bất kỳ quyết định thiết kế. Nếu vì một lý do nào đó, bạn phải sử dụng danh tính cho đại diện của đối tượng giá trị trong DB, hãy làm như vậy, nhưng đừng rò rỉ chi tiết triển khai này vào chính miền. Tạo một trình bao bọc / mở rộng các lớp miền / bất cứ điều gì khung của bạn cho phép và thêm ID vào lớp cơ sở hạ tầng hoàn toàn riêng biệt, cho phép ứng dụng / khung duy trì trạng thái.

Tôi không thấy bất kỳ yêu cầu đặc biệt nào của DDD trong trường hợp này, bạn có thể mô hình hóa địa chỉ gửi thư và thanh toán dưới dạng tài sản của người đó và vẫn lưu trữ chúng trong một bảng riêng biệt, ví dụ:

Person
+ MailingAddress : Address
+ BillingAddress : Address

hoặc là

Person
+ MailingAddressID
+ MailingAddress : Address
+ BillingAddressID
+ BillingAddress : Address