DDD/DI (Unity)/.NET/Thành phần gốc - Dịch vụ tên miền

Question

Tôi có một thiết lập Order/OrderLineItem tiêu chuẩn.

Một số Khoản tiền hoàn lại được tạo trong ngày được duy trì trong ngày, Khoản tiền hoàn lại bao gồm Mã đơn hàng và 1 hoặc nhiều hơn LineItemId. Tôi cần phải hợp nhất những (trong một dịch vụ Windows) vào cuối ngày hoàn trả cho thẻ tín dụng, thẻ quà tặng, thẻ phần thưởng, vv khi thích hợp.

Tôi đã đọc Mark Seemann's book và có thể thấy lợi ích của việc sử dụng Composition Root để làm xáo trộn đồ thị đối tượng.

Chính quá trình hợp nhất là nơi tôi cần làm nhiều nhất.

Điều tôi không hiểu chính xác là nơi mà logic hợp nhất này sẽ kết thúc? Tôi có thể giả định rằng bất kể logic hợp nhất kết thúc ở đâu thì tôi vẫn chỉ sử dụng một cái gì đó giống như Unity trong root composition và thành phần đó sẽ xảy ra rất sớm?

Vui lòng cung cấp thêm thông tin hoặc làm rõ khi thích hợp!

Answer 1

Chính quá trình hợp nhất là nơi tôi cần làm nhiều nhất.

Vì vậy, bạn có nghĩa là quá trình tạo dữ liệu trong hệ thống của bạn là nơi các đối tượng miền nhất sẽ được tạo?

Điều đó có ý nghĩa và phù hợp với hầu hết các ứng dụng.

Điều tôi không hiểu chính xác là nơi logic hợp nhất này sẽ kết thúc ở đâu?

Logic hợp nhất sẽ được cung cấp bởi một hoặc nhiều thành phần dịch vụ, có khả năng sử dụng một hoặc nhiều thành phần repository và một hoặc nhiều thành phần unit of work. Dịch vụ đó sẽ được tạo thành trong thư mục gốc, như mọi kho lưu trữ/đơn vị công việc mà bạn tạo ra.

Dữ liệu tự động hoàn toàn. Bạn không thể cấu trúc ứng dụng của mình để biết sơ đồ bố trí của dữ liệu một cách tĩnh, do đó bạn không thể soạn nó trong thư mục gốc của bạn. Bạn cũng không nên cố gắng.Thay vào đó, mã của bạn có thể sử dụng ORM để xác định hoặc ánh xạ tới lược đồ quan hệ giữa các đối tượng dữ liệu miền của bạn.

Sau đó, bạn có thể sử dụng kho/đơn vị công việc để truy xuất dữ liệu từ bộ nhớ. Bạn cũng sử dụng giao diện người dùng/dịch vụ của mình để tạo dữ liệu mới bằng cách sử dụng new - không có sự xấu hổ trong đó đối với các đối tượng miền thuần túy là dữ liệu và được đảm bảo không có phụ thuộc. Kéo dài dữ liệu mới hoặc sửa đổi vào kho/đơn vị công việc.

Nếu điều này làm cho bạn bị rạn nứt, bạn luôn có thể sử dụng mẫu nhà máy được tiêm từ gốc thành phần để tạo các đối tượng đó. Nhưng nếu bạn đã cấu trúc các đối tượng miền cấp thấp của mình là DTOs, điều này sẽ không mua cho bạn nhiều, nếu có.

Vì vậy, bạn không phải sử dụng Unity để cung cấp mọi thứ, và bạn không phải tạo ra hoàn toàn mọi đối tượng trong hệ thống của bạn trong thư mục gốc. Nhưng bạn nên cố gắng soạn các phần tĩnh của hệ thống của bạn hoặc thậm chí các phần động có thể cấu hình tĩnh của hệ thống của bạn trong thư mục gốc. Bản đồ này rất tốt cho các thùng chứa DI như Unity.

Answer 2

Trong trường hợp các khoản hoàn lại của bạn chỉ là các thùng chứa dữ liệu hoặc các thực thể không có bất kỳ sự phụ thuộc nào vào các dịch vụ, bạn có thể chỉ cần tạo một cá thể bằng cách sử dụng mới.

Nếu chúng có phụ thuộc và phải được tạo bởi thùng chứa IoC của bạn và bạn không thể thực hiện khi khởi động hơn là bạn sẽ muốn sử dụng giao diện nhà máy. Giao diện nhà máy này chứa một phương thức CreateRefund lấy tất cả các tham số cần thiết mà bạn muốn truyền cho cá thể đã tạo. Giao diện này được định nghĩa trong không gian tên/lắp ráp của người tiêu dùng của nó.

Việc triển khai giao diện này phụ thuộc vào vùng chứa IoC. Một số vùng chứa cung cấp chức năng giao diện được triển khai tự động bởi vùng chứa chỉ bằng cách chỉ định nó trong cấu hình. Những người khác như Unity yêu cầu triển khai thủ công. Triển khai này tồn tại trong Root Root như là một phần của cấu hình vùng chứa của bạn. Hãy để thực hiện lấy một thể hiện của thùng chứa và sử dụng nó để tạo ra trường hợp hoàn tiền được yêu cầu.

Bằng cách này, nơi duy nhất bạn truy cập vùng chứa nằm trong Root Root.