Re: Responsibilities of ApplicationServices versus DomainServices

Do you mean that it's *always* a good idea to implement your Aggregates
such that they keep track of their own events like in an event-sourced
system, but just let the repositories differ in implementation based on the
choice of event-sourced or state-based systems and publish the events from
there?


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

> **
>
>
> Publish the event from the domain (domain=event only). Transactionally
> save and publish event then. There are a ton of reasons for doing it this
> way.
>
>
> On Monday, May 27, 2013, Wim van Gool wrote:
>
>> **
>>
>>
>> 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.
>>>
>>>
>>
>
> --
> Le doute n'est pas une condition agréable, mais la certitude est absurde.
>
>  
>