CQRS + PHP：事件发生时在何处放置逻辑

Question

Currently I'm building an PHP application with the ideas of CQRS, ES and DDD. Let's consider this an survey application with 5 questions. A participant can respond to the survey by answering the 5 questions.

The 5 questions can be queried from the read side in the right order. But, a question can have conditions. For example, don't show question 2 when B is answered to question 1. With the answer 1B, the next question(s) to ask will be: 3, 4 and 5.

The client can fire the command AnswerQuestion, a handler will process that command and a event QuestionAnswered is fired. Based on that event an event handler will update the read side and the client can query for the next question to ask. When there are no further questions the ask, the participation will be completed for the participant (and can take participate with a new participation).

The logic in the survey will decide which questions to ask, and which not, based on the given answer, this is pure domain logic. I'm struggling where to place / apply this logic. Also where to decided when a participation is completed. I think the most likely answer will be: let the survey AR determine the next question based on the given answers from the participation. Or, share the logic in a service, let the read side query the questions and given answers and apply the shared logic to that.

Can you help me further? Thanks in advance!

Answer 1

As I understand, you have a couple of domain concepts here (forgive the terminology, speak to a domain expert to refine them):

• Question (question being asked) Relationship (between a question)
• Survey (AR, consists of multiple Questions, and contains the
• Relationship mapping)
• Submitted Survey

You also have events for when questions are answered.

In terms of placing logic I would do the following:

The application service would scaffold all of the required parts for the presentation layer (lets assume this would be via a Web API call).

On the application service I would hydrate the entire requested Survey (fetch from repository by survey name) and pass it down to the client.

The client would handle the mapping of relationships and perhaps display the current available questions depending on the current selection via Angular or Knockout.

If you didn't want to store the state on the client, I would instead get a list of all available options depending on the current selection (you would request this new list of available options each time a change happens on your client).

When to decide a survey is complete:

You may have some state on the client that knows when this is done (it would know when all available questions have been answered).

When processing on the server you would need to validate this by building your domain object and confirming the survey is complete, and if so storing the submitted survey.

A couple of points:

I don't really see how Event Sourcing or CQRS is solving a problem here, or is this for learning purposes?

You may want to make it simpler by forgetting the read model for now, and just hydrating the Survey from a repository (how you do this, whether by event store, ORM, or read model doesn't really matter) - read models are used to build views that the client needs as querying event streams means replaying all events (geteventstore.com has something called projections which can build these views on the fly).

Event Sourcing can be immensely powerful to gain insight for the business, I can think in this example storing the selected questions as a sequence of events you could get an idea of how quickly people respond, how many times they change their mind etc.