CODEWITHSUNDEEP
websocketcontrollerdomain-driven-designserver-sent-eventsdomain-events
Connor Burke
Connor Burke

Reputation: 1

In domain driven design, can domain events (which should have no knowledge of infra) push view changes to the client?

I'm building a bookstore point of sale system, and trying to use layer architecture / DDD for the first time. Books are my aggregates, and DDD ensures that my books can only be created in such a way that the business rules around creation are satisfied. However, another business rule is that two book inventory items can't have the same SKU. I've therefore set up domain events, BookCreated or BookSkuUpdated, which ultimately are subscribed to by a domain service that checks for duplicates and marks them if they're found. Eventual consistency, and so far so good.

My question is how to integrate this domain behavior into my web app. When the book is created, the code flows from infra (my controller) to application layer (the create book use case) to domain (book aggregate) then back to application layer and infra so it can be displayed to the client. No problem, ultimately request -> response. However, my domain events are set up with a little callback queue that creates a new code flow which STARTS in the domain, with creation of the domain event, and ultimately results in a subscriber kicking off a new application layer use case (updateDuplicateSku). Because my persistence is a single repo I can save the new duplicateSku warning to the repo, but can't for the life of me figure out how to push that view to the client. Instead of the use case returning to the controller, which has the request and response objects, the use case was kicked off in the domain so doesn't have any knowledge of the client.

In short - is there a good way for domain event callbacks to make eventual consistency changes to the domain and push those changes to a client with server sent events or websockets?

Upvotes: 0

Views: 557

Answers (1)

pgorecki
pgorecki

Reputation: 699

Domain Events allow aggregates to react to a change in another aggregate without coupling them. So using a domain event handler (updateDuplicateSku) to detect duplicates sounds fine.

Next, updateDuplicateSku should publish an integration event (i.e. SKUMarkedAsDuplicate). The purpose of integration events is to propagate committed transactions and to update additional subsystems. In this case, an integration event would be handled by a websocket server, which is in turn responsible for pushing changes back to the client.

All the communication is asynchronous in nature so you cannot use req and res variables from a client API call.

Upvotes: 1

Related Questions