I have a bounded context that deals with votes on topics that can be made by a user on a website. I have separated nicely via class libraries, but ultimately the Votes bounded context and the MVC web application are currently compiled to a single set of binaries.

I also have another bounded context called Library (some simple non-DDD code), a Windows Service that indexes text on the file-system, and can also automatically make a vote on a topic when certain criteria is met (the indexing logic deals with regex and state machines, code which is not involved/related to voting bounded context which does use DDD).

The javascript front end client calls an REST API https://api.myapp.com/vote/book/1201012, which in turns calls the application service for votes which in turn calls the ProcessUserVoteCommand.

The Library bounded context currently also calls the same REST API that the javascript front end calls, i.e. https://api.myapp.com/vote/book/5235211 and then just carries on in a loop.

I am instead thinking of sending a message over a message bus to vote on a topic which the Votes context would listen for, but this raises some questions:

Question 1 - If the Library service posts on the event bus, would this be a command or an event?

If the Library service posts on an event bus, would this posted message be called an event TopicVotedOn, or a command VoteOnTopic? I can handle either from the bus so this is more of a formality but:

  1. It doesn't make sense to use a Command, since I am not referencing any particular endpoint and expecting a reply (I'm just posting a message).
  2. It doesn't make sense to use a domain Event, as I do not have an identity of the generating entity (there is no concept of DDD entities in the Library bounded context, only the Windows Service that generated the event).

Is there an alternative message naming scheme that makes more sense for the service to send other than command or event?

Question 2 - Where should the Vote application live

I can make the Votes bounded context 'live' inside the API process by referencing and compiling the Votes code class library in the Web API project.

But with IIS hosted applications do I need to be concerned with application recycling, especially as I would be waiting for events from an external event bus (I believe IIS hates long running threads) and also as applications can be recycled?

Or are Bounded Contexts better ran as physically separate Windows Server processes away from the hosting presentation layer (IIS) - if so how would I communicate between the presentation layer to the back-end Windows Process? WCF, MSMQ? Any other recommendation for .NET friendly queue?

Related posts

Recent Viewed