| Newsgroups |
gmane.comp.programming.domain-driven-design |
| Message-ID |
<CAKqMafwuS29E1h+oE3Csf8Y2F3JrdRxDHS50cqJ_mLNzRobSZA@mail.gmail.com> |
By the way, the query-side has by definition nothing to do with 'business
logic'. Business logic is what relates to code that alters the business
data based on certain actions and business rules. That is something what
you design your Domain Model for. The Query-Side does not contain business
logic - no matter how complex some queries may get. So you don't have to
worry about guidelines telling you where to put that query-logic.
Having said that, when applying DDD, it's a general guideline to implement
all business logic in your Domain Layer / Domain Model, and change only one
aggregate per transaction. This design keeps the Application Layer very
thin and straightforward. There are exceptions to this rule though:
sometimes you just cannot avoid having some coordination logic (thus
business logic) in your Application Layer, possibly hitting two aggregates
in one transaction.
On Fri, May 30, 2014 at 7:46 AM, Wim van Gool <[email protected]> wrote:
> If you apply DDD with CQRS, which l always recommend, then this means that
> you will apply DDD only for the command-side of your application. As far as
> I see it, you are then free to design and implement the query-side as you
> like. So, if you have a page with lots of search filters, just construct a
> QueryRequest-message that contains all those filters (presumable with a lot
> of optional fields) and implement a method/service in your back-end that
> handles this query and returns the appropriate QueryResponse.
>
> Conceptually, the service(s) that handle your queries can be thought of
> being part of the same Api-layer where the commands arrive, but physically
> you can separate them completely if you want to.
>
> Where exactly the SQL is implemented is also entirely up to you. Vernon
> has chosen to put the SQL into the application-code (the QueryService), but
> you may also just call a stored procedure or something.
>
> Does this answer your question?
>
>
> On Fri, May 30, 2014 at 1:01 AM, [email protected]
> [domaindrivendesign] <[email protected]> wrote:
>
>>
>>
>> Any ideas anyone?
>>
>>
>
>