| Newsgroups |
gmane.comp.programming.domain-driven-design |
| Message-ID |
<CAKhPsH8y5Ous=Hjj4jo0z34kuJAJM84C+hGyTzgmBeLOmdtGhw@mail.gmail.com> |
I'd strongly recommend using expressions for search, they can be
implemented generically, meaning that you don't have to implement
potentially 100s of "QueryFilter" objects and can provide more powerful
capabilities to the end user..
--
Ryan
On 30 May 2014 07:51, Wim van Gool [email protected] [domaindrivendesign]
<[email protected]> wrote:
>
>
> 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?
>>>
>>
>>
>
>
>
>