2

In Vaughn Vernon's book Implementing domain driven design and the accompanying sample application I found that he implemented a CQRS approach to the iddd_collaboration bounded context.

He presents the following classes in the application service layer:

  • CalendarApplicationService.java
  • CalendarEntryApplicationService.java
  • CalendarEntryQueryService.java
  • CalendarQueryService.java

I'm interested to know if an application will have a search page that feature numerous drop downs and check boxes with a smart text box to match different search patterns; How will you structure all that search logic?

In a command service or a query service?

Taking a look at the CalendarQueryService.java I can see that it has 2 methods for a huge query, but no logic at all to mix and match any search filters for example.

I've heard that the application layer shouldn't have any business logic, so where will I construct my dynamic query? or maybe just clutter everything in the Query service?

  • The first question to answer is whether your search-tools (especially if they are complex) should be part of the same domain, or whether it needs to have its own separate one. One reason to merge them might be if the same kinds of specification used for searching also be used to accomplish certain business rules. In other words, how heavy-weight is this search feature? – Darien May 22 '14 at 1:06
  • @Darien "should be part of the same domain" Did you mean part of the same bounded context? I don't see why I should separate them into 2 different bounded contexts. Picture a search page for an e-commerce website. A user gets to search for some orders and then gets to call different operations on these orders such as order.refund(), order.cancel(), order.ship(),...etc. – Songo May 22 '14 at 2:21
  • I was thinking more about classes like CalendarEventSpecification, which could be both part of a searching scheme and also part of some business rules. – Darien May 23 '14 at 21:53
1

In CQRS you create different models for commands and queries, so it's fine to create separate model for your query service and do business logic using it.

Anyway, if searching is a big part of your application, then I would create another bounded context for it.

1

In CQRS, queries are not allowed to have any side effects, and thus they cannot change any data. Commands on the other hand must not return any data, but change the state of the application.

With these definitions and your problem domain the question becomes this: What does the search functionality do? If it's purely for finding an order, then it is not changing any application state while doing the search. The resulting view might offer a button or such to perform operations on that found order, and then you transition into the command side of CQRS. On this side what you need to successfully complete the command is retrieved through the domain object and acted upon and then stored back to the data store.

All in all, as the logic of performing a complex search might sound like it's correlated to the business or domain logic, I'd argue that it actually hasn't got anything to do with domain logic. It's just a logical tool to get the info the user needs. Domain logic is the logic that will be applied when you e.g. cancel the order. What does cancelling an order mean is the question that domain logic answers.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.