Re: Responsibilities of ApplicationServices versus DomainServices

So the domain produces events (as in event sourced).

You may or may not save a read model synchronously (say mongodb though
synchronous they're is funny).

The events are then published.

A whole host of issues come up if you try any other way (though the others
seem logical and some actually recommend them). This only applies if you
are raising events btw.

Greg

On Monday, May 27, 2013, Wim van Gool wrote:

> **
>
>
> 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]<javascript:_e({}, 'cvml', '[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.
>>
>>
>  
>


-- 
Le doute n'est pas une condition agréable, mais la certitude est absurde.