Thực hành tốt nhất để tuần tự hóa các tập hợp DDD

Theo logic miền DDD không nên bị ô nhiễm với các mối quan tâm kỹ thuật như tuần tự hóa, ánh xạ quan hệ đối tượng, v.v.

Vậy làm thế nào để bạn tuần tự hóa hoặc ánh xạ trạng thái của tập hợp mà không hiển thị công khai thông qua getters và setters? Tôi đã thấy rất nhiều ví dụ cho việc triển khai kho lưu trữ, nhưng thực tế tất cả chúng đều dựa vào các bộ truy cập công cộng trên các thực thể và các đối tượng giá trị để ánh xạ.

Chúng ta có thể sử dụng sự phản chiếu để tránh những người truy cập công cộng, nhưng IMO những đối tượng miền này vẫn hoàn toàn phụ thuộc vào mối quan tâm tuần tự hóa. Ví dụ: bạn không thể đổi tên hoặc xóa trường riêng mà không điều chỉnh cấu hình tuần tự hóa / ánh xạ. Vì vậy, bạn phải xem xét việc tuần tự hóa nơi bạn nên tập trung vào logic miền.

Vì vậy, những thỏa hiệp tốt nhất để làm theo ở đây là gì? Sống với người truy cập công cộng, nhưng tránh sử dụng chúng cho bất cứ điều gì khác ngoài mã bản đồ? Hay tôi chỉ bỏ lỡ một cái gì đó rõ ràng?

Tôi rõ ràng quan tâm đến việc tuần tự hóa trạng thái của các đối tượng miền DDD (tập hợp bao gồm các thực thể và các đối tượng giá trị). Đây KHÔNG phải là về tuần tự hóa trong các kịch bản kịch bản nói chung hoặc chuyển mã trong đó các dịch vụ phi trạng thái hoạt động trên các đối tượng chứa dữ liệu đơn giản.

Các loại đối tượng

Đối với mục đích thảo luận của chúng tôi, hãy tách các đối tượng của chúng tôi thành ba loại khác nhau:

Logic miền kinh doanh

Đây là những đối tượng có được công việc được thực hiện. Họ chuyển tiền từ tài khoản kiểm tra này sang tài khoản khác, thực hiện các đơn đặt hàng và tất cả các hành động khác mà chúng tôi mong đợi phần mềm kinh doanh sẽ thực hiện.

Các đối tượng logic miền thông thường không yêu cầu bộ truy cập (getters và setters). Thay vào đó, bạn tạo đối tượng bằng cách trao các phụ thuộc của nó thông qua một hàm tạo, và sau đó thao tác với đối tượng thông qua các phương thức (nói, đừng hỏi).

Đối tượng truyền dữ liệu

Đối tượng truyền dữ liệu là trạng thái tinh khiết; chúng không chứa bất kỳ logic kinh doanh nào. Họ sẽ luôn có người truy cập. Họ có thể có hoặc không có setters, tùy thuộc vào việc bạn có viết chúng theo cách không thay đổi hay không . Bạn sẽ đặt các trường của mình trong hàm tạo và các giá trị của chúng sẽ không thay đổi trong suốt vòng đời của đối tượng hoặc các bộ truy cập của bạn sẽ được đọc / ghi. Trong thực tế, các đối tượng này thường có thể thay đổi, để người dùng có thể chỉnh sửa chúng.

Xem các đối tượng Model

Xem các đối tượng Mô hình chứa biểu diễn dữ liệu có thể hiển thị / có thể chỉnh sửa. Chúng có thể chứa logic nghiệp vụ, thường được giới hạn để xác thực dữ liệu. Một ví dụ về đối tượng Mô hình xem có thể là InvoiceViewModel, chứa đối tượng Khách hàng, đối tượng Tiêu đề hóa đơn và Mục hàng hóa đơn. Xem các đối tượng Model luôn chứa các bộ truy cập.

Vì vậy, loại đối tượng duy nhất sẽ "thuần túy" theo nghĩa là nó không chứa các bộ truy cập trường sẽ là đối tượng Logic miền. Việc tuần tự hóa một đối tượng như vậy sẽ lưu "trạng thái tính toán" hiện tại của nó để có thể truy xuất nó sau này để xử lý hoàn tất. Mô hình Xem và DTO có thể được tuần tự hóa tự do, nhưng trên thực tế, dữ liệu của họ thường được lưu vào cơ sở dữ liệu.

Nối tiếp, phụ thuộc và khớp nối

Mặc dù sự thật là tuần tự hóa tạo ra sự phụ thuộc, theo nghĩa là bạn phải giải tuần tự hóa thành một đối tượng tương thích, nhưng không nhất thiết phải tuân theo việc bạn phải thay đổi cấu hình tuần tự hóa. Cơ chế tuần tự hóa tốt là mục đích chung; họ không quan tâm nếu bạn thay đổi tên của một tài sản hoặc thành viên, miễn là nó vẫn có thể ánh xạ các giá trị cho các thành viên. Trong thực tế, điều này chỉ có nghĩa là bạn phải tuần tự hóa lại thể hiện đối tượng để làm cho biểu diễn tuần tự hóa (xml, json, bất cứ thứ gì) tương thích với đối tượng mới của bạn; không cần thay đổi cấu hình cho serializer.

Đúng là các đối tượng không nên quan tâm đến cách chúng được nối tiếp. Bạn đã mô tả một cách những mối quan tâm như vậy có thể được tách rời khỏi các lớp miền: sự phản chiếu. Nhưng trình tuần tự hóa nên được quan tâm về cách nó tuần tự hóa và giải tuần tự hóa các đối tượng; Rốt cuộc, đó là chức năng của nó. Cách bạn giữ cho các đối tượng của bạn tách rời khỏi quy trình tuần tự hóa của bạn là làm cho việc tuần tự hóa thành một chức năng có mục đích chung , có thể hoạt động trên tất cả các loại đối tượng.

Một trong những điều mọi người bị nhầm lẫn là việc tách rời phải xảy ra theo cả hai hướng. Nó không; nó chỉ phải làm việc theo một hướng. Trong thực tế, bạn không bao giờ có thể tách rời hoàn toàn; luôn luôn có một số khớp nối. Mục tiêu của khớp nối lỏng lẻo là làm cho việc bảo trì mã dễ dàng hơn, không phải loại bỏ tất cả các phụ thuộc.

Mục đích cơ bản của việc tuần tự hóa là để đảm bảo rằng dữ liệu được tạo ra bởi một hệ thống có thể được tiêu thụ bởi một hoặc nhiều hệ thống tương thích.

Cách tiếp cận đơn giản và mạnh mẽ nhất để tuần tự hóa là dịch dữ liệu sang định dạng bất khả tri loại duy trì cấu trúc theo định dạng đơn giản và dễ tiêu thụ. Ví dụ, các định dạng tuần tự hóa phổ biến nhất (ví dụ JSON, XML) sử dụng định dạng dựa trên văn bản được xác định rõ. Văn bản là đơn giản để sản xuất, truyền tải và tiêu thụ.

Có 2 lý do tại sao sử dụng một trong những định dạng này có thể không lý tưởng.

1. Hiệu quả

   Có một chi phí cố hữu liên quan đến việc dịch tất cả các dữ liệu thành tương đương dựa trên văn bản của họ. Các kiểu dữ liệu sẽ không tồn tại nếu văn bản là cách hiệu quả nhất để thể hiện tất cả các dạng dữ liệu khác nhau. Ngoài ra, cấu trúc của các định dạng này không lý tưởng để truy xuất các tập hợp con dữ liệu không đồng bộ hoặc theo từng phần.

   Chẳng hạn, XML và JSON cho rằng dữ liệu đang được sử dụng sẽ được ghi và đọc từ đầu đến cuối. Để xử lý các tập dữ liệu rất lớn nơi bộ nhớ khan hiếm, hệ thống tiêu thụ dữ liệu có thể yêu cầu khả năng xử lý dữ liệu theo từng phần. Trong trường hợp đó, việc thực hiện tuần tự hóa / giải tuần tự mục đích đặc biệt có thể được yêu cầu để xử lý dữ liệu.

2. Độ chính xác

   Việc truyền được yêu cầu để tuần tự hóa / giải tuần tự hóa dữ liệu từ loại dự định sang loại không biết dữ liệu dẫn đến mất độ chính xác.

Người ta có thể lập luận rằng việc tạo ra một biểu diễn nhị phân của các đối tượng và dữ liệu rõ ràng là giải pháp chính xác và hiệu quả nhất. Hạn chế lớn là việc triển khai tất cả các hệ thống vừa tiêu thụ vừa sản xuất dữ liệu cần phải tương thích. Đó là một hạn chế đơn giản trong lý thuyết nhưng đó là một cơn ác mộng để duy trì trong thực tế khi các hệ thống sản xuất có xu hướng thay đổi / phát triển theo thời gian.

Với những gì đã nói. Việc tách rời tuần tự hóa / giải tuần tự hóa từ các chi tiết cụ thể theo miền có ý nghĩa như một quy tắc chung vì các định dạng mục đích chung mạnh mẽ hơn, được hỗ trợ tốt hơn trên các hệ thống khác nhau và yêu cầu sử dụng ít chi phí bảo trì.