Cách xử lý các lệnh Thêm / Tạo * trong kiến ​​trúc Tìm nguồn sự kiện CQRS +

Tôi muốn triển khai ứng dụng đầu tiên của mình bằng cách sử dụng mẫu CQRS cùng với Tìm kiếm sự kiện. Tôi đang tự hỏi làm thế nào để tạo ra rễ tổng hợp nên được xử lý đúng. Giả sử ai đó gửi lệnh CreatItem. Làm thế nào nó nên được xử lý? Nơi lưu trữ sự kiện ItemCreated? Là sự kiện đầu tiên của một mặt hàng mới? Hoặc tôi nên có một số loại thực thể ItemList tổng hợp tất cả các mục và danh sách sự kiện của nó chỉ bao gồm các sự kiện ItemCreated?

Udi Dahan đề nghị không tạo ra các gốc tổng hợp và luôn luôn sử dụng thay vào đó một số phương pháp tìm nạp. Nhưng làm thế nào tôi có thể tìm nạp một cái gì đó mới và chắc chắn không có bất kỳ ID nào được chỉ định. Tôi hiểu ý tưởng đằng sau và khá hợp lý khi nghĩ rằng một đối tượng mới là một đối tượng có trạng thái bao gồm các sự kiện bằng không trả lời về nó. Nhưng tôi nên sử dụng nó như thế nào? Tôi nên có một phương thức riêng biệt trong Kho lưu trữ của mình như thế nào getNewItem()hoặc thay vào đó làm cho get(id)phương thức của tôi chấp nhận Optional<ItemId>?

Chỉnh sửa: Sau một thời gian đào tôi thấy việc triển khai thực sự thú vị các mẫu đã nói ở trên bằng cách sử dụng các diễn viên. Tác giả thay vì tạo tập hợp, lấy nó từ một loại kho lưu trữ với UUID mới được tạo. Hạn chế của phương pháp này là ông cho phép trạng thái không nhất quán tạm thời. Tôi cũng tự hỏi làm thế nào tôi có thể thực hiện deletephương pháp với cách tiếp cận như vậy. Đơn giản chỉ cần thêm sự kiện đã xóa vào danh sách sự kiện của tổng hợp?

Ý tưởng trong bài viết của Udi, khi tôi tập hợp, là không có loại vật phẩm nào xuất hiện trong không khí mỏng. Luôn luôn có một cái gì đó, hoặc cụ thể hơn là một số hoạt động tên miền, khiến cho mục được tạo. Giống như ví dụ của Udi về một người dùng thực sự được sinh ra từ một khách truy cập đăng ký vào trang web. Tại thời điểm đó và tại bối cảnh giới hạn đó, Khách truy cập là gốc tổng hợp, được truy xuất bằng địa chỉ IP của anh ta. Khách truy cập này sau đó tạo ra "mục" mới, một người dùng tại thời điểm này, thông qua một hoạt động tên miền được gọi là Đăng ký . Tương tự với bước trước, đó là một bối cảnh bị ràng buộc khác: Giới thiệu là AR, được lấy ra bởi URL và có một hoạt động tên miền được gọi là BvedVisitorWithIp , nơi khách truy cập được sinh ra.

Udi cũng viết rất hay về việc xóa: http://www.udidahan.com/2009/09/01/dont-delete-just-dont/ . Ý tưởng chính là, bạn không xóa bất cứ điều gì, bao giờ. Luôn có một hoạt động tên miền phía sau, mà chúng tôi muốn nắm bắt. Giống như một đơn đặt hàng bị hủy, thay vì bị xóa. Đọc nó, nó là một bài viết rất tốt.

Điểm chính ở đây trên cả hai tài khoản, thực hiện DDD và đặc biệt là Tìm kiếm sự kiện, là bạn không bao giờ nên thực hiện các thao tác CRUD thẳng. Nếu bạn thấy mình trong một tình huống mà bạn thực sự cần phải chèn, cập nhật hoặc xóa một số dữ liệu và thực sự không có hoạt động miền nào đằng sau nó, thì có lẽ DDD và Tìm nguồn sự kiện không phù hợp với bối cảnh bị ràng buộc đó . Bạn có thể tự do kết hợp hai điều này theo ý muốn miễn là một bối cảnh giới hạn duy nhất tuân thủ một nguyên tắc. Bằng cách này, bối cảnh giới hạn theo kiểu CRUD có thể tạo ra một số hàng trong cơ sở dữ liệu, trở thành một thực thể và gốc Tổng hợp trong một bối cảnh bị ràng buộc khác, nơi bạn có thể truy xuất AR và không phải tạo ra nó.