Re: Responsibilities of ApplicationServices versus DomainServices

Greg, I immediately assume you're right, but what about non-event sourced
state-based storage where you want to work with domain-events but still
have an ORM or simple key/value aggregate-store in place?


On Mon, May 27, 2013 at 1:47 PM, Greg Young <[email protected]> wrote:

> **
>
>
> In most systems that are event sourced saving the events equates to
> publishing. You rarely if ever want to raise events as you discuss it's a
> ton of hidden complexity.
>
>
> On Monday, May 27, 2013, Wim van Gool wrote:
>
>> **
>>
>>
>> Jorg, I think that's quite typical and I let ApplicationServices use the
>> repositories directly for adding and deleting aggregates too - but this
>> means that the Application Service is also responsible for raising the
>> Aggregate-X-Added-Events and Aggregate-X-Removed-Events, which I think is
>> OK, but I can imagine some people feel this is a domain-concerns (raising
>> Domain Events, that is).
>>
>>
>> On Mon, May 27, 2013 at 1:05 PM, Jorg Heymans <[email protected]>wrote:
>>
>>> **
>>>
>>>
>>> *Remaining questions*:
>>>
>>>> - Which service would you use to implement adding/removing aggregates
>>>> and raise the appropriate DomainEvent?
>>>>
>>>
>>> In our case applicationService.removeAggregate(id) delegates to
>>> aggregateRepository.remove(id), why would you need a service in between ?
>>>
>>> Jorg
>>>
>>>
>>
>
> --
> Le doute n'est pas une condition agréable, mais la certitude est absurde.
>
>  
>