What if you have an event that say sends an e-mail. App shuts down. App starts up and recreates its state by replaying events. When it gets to the event that results in an e-mail being sent out, then it will get sent out for a second time.
I can think of several ways around this but they all seem leaky. In the sense that it means the app will have to start checking whether it is "live" or just "replaying/projecting". This would mean that the domain model is at least slightly aware of its persistence mechanism which doesn't seem right.
On Wed, Aug 1, 2012 at 1:21 AM, Nathan Evans <nbev...@gmail.com> wrote:
> What if you have an event that say sends an e-mail. App shuts down. App
> starts up and recreates its state by replaying events. When it gets to the
> event that results in an e-mail being sent out, then it will get sent out
> for a second time.
> I can think of several ways around this but they all seem leaky. In the
> sense that it means the app will have to start checking whether it is "live"
> or just "replaying/projecting". This would mean that the domain model is at
> least slightly aware of its persistence mechanism which doesn't seem right.
> Any ideas? :)
-- Le doute n'est pas une condition agréable, mais la certitude est absurde.
Yeah I realise that, otherwise you'll get the problem of duplicate e-mails being sent out, duplicate web service calls, etc etc.
So what is the elegant solution?
Maybe this is more of a DDD question than anything. Is it simply that the domain model should purely be focused upon managing its own state and logic, rather than performing behaviours outside of its concern?
On Wednesday, August 1, 2012 9:29:32 AM UTC+1, Greg Young wrote:
> Projections should never do behaviours.
> On Wed, Aug 1, 2012 at 1:21 AM, Nathan Evans wrote: > > What if you have an event that say sends an e-mail. App shuts down. App > > starts up and recreates its state by replaying events. When it gets to > the > > event that results in an e-mail being sent out, then it will get sent > out > > for a second time.
> > I can think of several ways around this but they all seem leaky. In the > > sense that it means the app will have to start checking whether it is > "live" > > or just "replaying/projecting". This would mean that the domain model is > at > > least slightly aware of its persistence mechanism which doesn't seem > right.
> > Any ideas? :)
> -- > Le doute n'est pas une condition agréable, mais la certitude est absurde.
Your email service should be resilient to duplicate messages for one. But
you have a bigger issue. You don't do anything except set state when
hydrating.
On Aug 1, 2012 2:03 AM, "Nathan Evans" <nbev...@gmail.com> wrote:
> Yeah I realise that, otherwise you'll get the problem of duplicate e-mails
> being sent out, duplicate web service calls, etc etc.
> So what is the elegant solution?
> Maybe this is more of a DDD question than anything. Is it simply that the
> domain model should purely be focused upon managing its own state and
> logic, rather than performing behaviours outside of its concern?
> Thanks.
> On Wednesday, August 1, 2012 9:29:32 AM UTC+1, Greg Young wrote:
>> Projections should never do behaviours.
>> On Wed, Aug 1, 2012 at 1:21 AM, Nathan Evans wrote:
>> > What if you have an event that say sends an e-mail. App shuts down. App
>> > starts up and recreates its state by replaying events. When it gets to
>> the
>> > event that results in an e-mail being sent out, then it will get sent
>> out
>> > for a second time.
>> > I can think of several ways around this but they all seem leaky. In the
>> > sense that it means the app will have to start checking whether it is
>> "live"
>> > or just "replaying/projecting". This would mean that the domain model
>> is at
>> > least slightly aware of its persistence mechanism which doesn't seem
>> right.
>> > Any ideas? :)
>> --
>> Le doute n'est pas une condition agréable, mais la certitude est absurde.
On Wed, Aug 1, 2012 at 5:03 AM, Nathan Evans <nbev...@gmail.com> wrote:
> Yeah I realise that, otherwise you'll get the problem of duplicate e-mails
> being sent out, duplicate web service calls, etc etc.
> So what is the elegant solution?
> Maybe this is more of a DDD question than anything. Is it simply that the
> domain model should purely be focused upon managing its own state and logic,
> rather than performing behaviours outside of its concern?
> Thanks.
> On Wednesday, August 1, 2012 9:29:32 AM UTC+1, Greg Young wrote:
>> Projections should never do behaviours.
>> On Wed, Aug 1, 2012 at 1:21 AM, Nathan Evans wrote:
>> > What if you have an event that say sends an e-mail. App shuts down. App
>> > starts up and recreates its state by replaying events. When it gets to
>> > the
>> > event that results in an e-mail being sent out, then it will get sent
>> > out
>> > for a second time.
>> > I can think of several ways around this but they all seem leaky. In the
>> > sense that it means the app will have to start checking whether it is
>> > "live"
>> > or just "replaying/projecting". This would mean that the domain model is
>> > at
>> > least slightly aware of its persistence mechanism which doesn't seem
>> > right.
>> > Any ideas? :)
>> --
>> 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.
It's purely a theoretical question. This isn't an actual project I'm working on.
So I guess the answer is either one of the following:
1. Don't ever actually send that e-mail from a domain event. Do it somewhere else, such as the layer where the domain event was raised in the first place.
2. Continue sending that e-mail from a domain event. But wrap it in a condition like: if (projecting == false) { /* send e-mail */ }
On Wednesday, August 1, 2012 10:05:56 AM UTC+1, Adam Dymitruk wrote:
> Your email service should be resilient to duplicate messages for one. But > you have a bigger issue. You don't do anything except set state when > hydrating.
> On Aug 1, 2012 2:03 AM, "Nathan Evans" wrote:
>> Yeah I realise that, otherwise you'll get the problem of duplicate >> e-mails being sent out, duplicate web service calls, etc etc.
>> So what is the elegant solution?
>> Maybe this is more of a DDD question than anything. Is it simply that the >> domain model should purely be focused upon managing its own state and >> logic, rather than performing behaviours outside of its concern?
>> Thanks.
>> On Wednesday, August 1, 2012 9:29:32 AM UTC+1, Greg Young wrote:
>>> Projections should never do behaviours.
>>> On Wed, Aug 1, 2012 at 1:21 AM, Nathan Evans wrote: >>> > What if you have an event that say sends an e-mail. App shuts down. >>> App >>> > starts up and recreates its state by replaying events. When it gets to >>> the >>> > event that results in an e-mail being sent out, then it will get sent >>> out >>> > for a second time.
>>> > I can think of several ways around this but they all seem leaky. In >>> the >>> > sense that it means the app will have to start checking whether it is >>> "live" >>> > or just "replaying/projecting". This would mean that the domain model >>> is at >>> > least slightly aware of its persistence mechanism which doesn't seem >>> right.
>>> > Any ideas? :)
>>> -- >>> Le doute n'est pas une condition agréable, mais la certitude est >>> absurde.
> It's purely a theoretical question. This isn't an actual project I'm
> working on.
> So I guess the answer is either one of the following:
> 1. Don't ever actually send that e-mail from a domain event. Do it
> somewhere else, such as the layer where the domain event was raised in the
> first place.
> 2. Continue sending that e-mail from a domain event. But wrap it in a
> condition like: if (projecting == false) { /* send e-mail */ }
> Which is it? :)
> On Wednesday, August 1, 2012 10:05:56 AM UTC+1, Adam Dymitruk wrote:
>> Your email service should be resilient to duplicate messages for one. But
>> you have a bigger issue. You don't do anything except set state when
>> hydrating.
>> On Aug 1, 2012 2:03 AM, "Nathan Evans" wrote:
>>> Yeah I realise that, otherwise you'll get the problem of duplicate
>>> e-mails being sent out, duplicate web service calls, etc etc.
>>> So what is the elegant solution?
>>> Maybe this is more of a DDD question than anything. Is it simply that
>>> the domain model should purely be focused upon managing its own state and
>>> logic, rather than performing behaviours outside of its concern?
>>> Thanks.
>>> On Wednesday, August 1, 2012 9:29:32 AM UTC+1, Greg Young wrote:
>>>> Projections should never do behaviours.
>>>> On Wed, Aug 1, 2012 at 1:21 AM, Nathan Evans wrote:
>>>> > What if you have an event that say sends an e-mail. App shuts down.
>>>> App
>>>> > starts up and recreates its state by replaying events. When it gets
>>>> to the
>>>> > event that results in an e-mail being sent out, then it will get sent
>>>> out
>>>> > for a second time.
>>>> > I can think of several ways around this but they all seem leaky. In
>>>> the
>>>> > sense that it means the app will have to start checking whether it is
>>>> "live"
>>>> > or just "replaying/projecting". This would mean that the domain model
>>>> is at
>>>> > least slightly aware of its persistence mechanism which doesn't seem
>>>> right.
>>>> > Any ideas? :)
>>>> --
>>>> Le doute n'est pas une condition agréable, mais la certitude est
>>>> absurde.
On Wednesday, August 1, 2012 10:31:19 AM UTC+1, Adam Dymitruk wrote:
> The answer is not one of these.
> On Aug 1, 2012 2:16 AM, "Nathan Evans" wrote:
>> It's purely a theoretical question. This isn't an actual project I'm >> working on.
>> So I guess the answer is either one of the following:
>> 1. Don't ever actually send that e-mail from a domain event. Do it >> somewhere else, such as the layer where the domain event was raised in the >> first place.
>> 2. Continue sending that e-mail from a domain event. But wrap it in a >> condition like: if (projecting == false) { /* send e-mail */ }
>> Which is it? :)
>> On Wednesday, August 1, 2012 10:05:56 AM UTC+1, Adam Dymitruk wrote:
>>> Your email service should be resilient to duplicate messages for one. >>> But you have a bigger issue. You don't do anything except set state when >>> hydrating.
>>> On Aug 1, 2012 2:03 AM, "Nathan Evans" wrote:
>>>> Yeah I realise that, otherwise you'll get the problem of duplicate >>>> e-mails being sent out, duplicate web service calls, etc etc.
>>>> So what is the elegant solution?
>>>> Maybe this is more of a DDD question than anything. Is it simply that >>>> the domain model should purely be focused upon managing its own state and >>>> logic, rather than performing behaviours outside of its concern?
>>>> Thanks.
>>>> On Wednesday, August 1, 2012 9:29:32 AM UTC+1, Greg Young wrote:
>>>>> Projections should never do behaviours.
>>>>> On Wed, Aug 1, 2012 at 1:21 AM, Nathan Evans wrote: >>>>> > What if you have an event that say sends an e-mail. App shuts down. >>>>> App >>>>> > starts up and recreates its state by replaying events. When it gets >>>>> to the >>>>> > event that results in an e-mail being sent out, then it will get >>>>> sent out >>>>> > for a second time.
>>>>> > I can think of several ways around this but they all seem leaky. In >>>>> the >>>>> > sense that it means the app will have to start checking whether it >>>>> is "live" >>>>> > or just "replaying/projecting". This would mean that the domain >>>>> model is at >>>>> > least slightly aware of its persistence mechanism which doesn't seem >>>>> right.
>>>>> > Any ideas? :)
>>>>> -- >>>>> Le doute n'est pas une condition agréable, mais la certitude est >>>>> absurde.
Yes n infrastructure service can be used for this...
A question to ask yourself though. If its temporarily failing should
we reject the transaction? There are times when the answer to this
question is a yes but more often than not its a no. If I can't send an
email right now to confirm your order should I not accept your order?
> This was what I was thinking all along really but just wanted to be sure.
> Perhaps I was having a blonde moment, sure. But I'm only on day 3 of
> recovery from having my brain implosion when I first learnt of Event
> Sourcing :)
> On Wednesday, August 1, 2012 10:31:19 AM UTC+1, Adam Dymitruk wrote:
>> The answer is not one of these.
>> On Aug 1, 2012 2:16 AM, "Nathan Evans" wrote:
>>> It's purely a theoretical question. This isn't an actual project I'm
>>> working on.
>>> So I guess the answer is either one of the following:
>>> 1. Don't ever actually send that e-mail from a domain event. Do it
>>> somewhere else, such as the layer where the domain event was raised in the
>>> first place.
>>> 2. Continue sending that e-mail from a domain event. But wrap it in a
>>> condition like: if (projecting == false) { /* send e-mail */ }
>>> Which is it? :)
>>> On Wednesday, August 1, 2012 10:05:56 AM UTC+1, Adam Dymitruk wrote:
>>>> Your email service should be resilient to duplicate messages for one.
>>>> But you have a bigger issue. You don't do anything except set state when
>>>> hydrating.
>>>> On Aug 1, 2012 2:03 AM, "Nathan Evans" wrote:
>>>>> Yeah I realise that, otherwise you'll get the problem of duplicate
>>>>> e-mails being sent out, duplicate web service calls, etc etc.
>>>>> So what is the elegant solution?
>>>>> Maybe this is more of a DDD question than anything. Is it simply that
>>>>> the domain model should purely be focused upon managing its own state and
>>>>> logic, rather than performing behaviours outside of its concern?
>>>>> Thanks.
>>>>> On Wednesday, August 1, 2012 9:29:32 AM UTC+1, Greg Young wrote:
>>>>>> Projections should never do behaviours.
>>>>>> On Wed, Aug 1, 2012 at 1:21 AM, Nathan Evans wrote:
>>>>>> > What if you have an event that say sends an e-mail. App shuts down.
>>>>>> > App
>>>>>> > starts up and recreates its state by replaying events. When it gets
>>>>>> > to the
>>>>>> > event that results in an e-mail being sent out, then it will get
>>>>>> > sent out
>>>>>> > for a second time.
>>>>>> > I can think of several ways around this but they all seem leaky. In
>>>>>> > the
>>>>>> > sense that it means the app will have to start checking whether it
>>>>>> > is "live"
>>>>>> > or just "replaying/projecting". This would mean that the domain
>>>>>> > model is at
>>>>>> > least slightly aware of its persistence mechanism which doesn't seem
>>>>>> > right.
>>>>>> > Any ideas? :)
>>>>>> --
>>>>>> 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.
That's an implementation detail more than anything, surely? And one that is normally resolved with a service bus, or at least by queuing up the e-mail somewhere.
On Wednesday, August 1, 2012 11:12:18 AM UTC+1, Greg Young wrote:
> Yes n infrastructure service can be used for this...
> A question to ask yourself though. If its temporarily failing should > we reject the transaction? There are times when the answer to this > question is a yes but more often than not its a no. If I can't send an > email right now to confirm your order should I not accept your order?
> Greg
> On Wed, Aug 1, 2012 at 6:05 AM, Nathan Evans wrote: > > Seems I was right though:
> > This was what I was thinking all along really but just wanted to be > sure.
> > Perhaps I was having a blonde moment, sure. But I'm only on day 3 of > > recovery from having my brain implosion when I first learnt of Event > > Sourcing :)
> > On Wednesday, August 1, 2012 10:31:19 AM UTC+1, Adam Dymitruk wrote:
> >> The answer is not one of these.
> >> On Aug 1, 2012 2:16 AM, "Nathan Evans" wrote:
> >>> It's purely a theoretical question. This isn't an actual project I'm > >>> working on.
> >>> So I guess the answer is either one of the following:
> >>> 1. Don't ever actually send that e-mail from a domain event. Do it > >>> somewhere else, such as the layer where the domain event was raised in > the > >>> first place.
> >>> 2. Continue sending that e-mail from a domain event. But wrap it in a > >>> condition like: if (projecting == false) { /* send e-mail */ }
> >>> Which is it? :)
> >>> On Wednesday, August 1, 2012 10:05:56 AM UTC+1, Adam Dymitruk wrote:
> >>>> Your email service should be resilient to duplicate messages for one. > >>>> But you have a bigger issue. You don't do anything except set state > when > >>>> hydrating.
> >>>> On Aug 1, 2012 2:03 AM, "Nathan Evans" wrote:
> >>>>> Yeah I realise that, otherwise you'll get the problem of duplicate > >>>>> e-mails being sent out, duplicate web service calls, etc etc.
> >>>>> So what is the elegant solution?
> >>>>> Maybe this is more of a DDD question than anything. Is it simply > that > >>>>> the domain model should purely be focused upon managing its own > state and > >>>>> logic, rather than performing behaviours outside of its concern?
> >>>>> Thanks.
> >>>>> On Wednesday, August 1, 2012 9:29:32 AM UTC+1, Greg Young wrote:
> >>>>>> Projections should never do behaviours.
> >>>>>> On Wed, Aug 1, 2012 at 1:21 AM, Nathan Evans wrote: > >>>>>> > What if you have an event that say sends an e-mail. App shuts > down. > >>>>>> > App > >>>>>> > starts up and recreates its state by replaying events. When it > gets > >>>>>> > to the > >>>>>> > event that results in an e-mail being sent out, then it will get > >>>>>> > sent out > >>>>>> > for a second time.
> >>>>>> > I can think of several ways around this but they all seem leaky. > In > >>>>>> > the > >>>>>> > sense that it means the app will have to start checking whether > it > >>>>>> > is "live" > >>>>>> > or just "replaying/projecting". This would mean that the domain > >>>>>> > model is at > >>>>>> > least slightly aware of its persistence mechanism which doesn't > seem > >>>>>> > right.
> >>>>>> > Any ideas? :)
> >>>>>> -- > >>>>>> 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.
I am giving a generalized answer (its not always just email). What
about charging a credit card, writing a transaction to the accounting
system, or telling inventory to move the item to shipping ....
There are loads of cases where you don't want it done as part of the
transaction for the command but prefer to do it from an event (but not
in a projection). This is where long running workflows (process
managers/sagas/whatever you want to call them) come in.
On Wed, Aug 1, 2012 at 6:27 AM, Nathan Evans <nbev...@gmail.com> wrote:
> That's an implementation detail more than anything, surely? And one that is
> normally resolved with a service bus, or at least by queuing up the e-mail
> somewhere.
> On Wednesday, August 1, 2012 11:12:18 AM UTC+1, Greg Young wrote:
>> Yes n infrastructure service can be used for this...
>> A question to ask yourself though. If its temporarily failing should
>> we reject the transaction? There are times when the answer to this
>> question is a yes but more often than not its a no. If I can't send an
>> email right now to confirm your order should I not accept your order?
>> Greg
>> On Wed, Aug 1, 2012 at 6:05 AM, Nathan Evans wrote:
>> > Seems I was right though:
>> > This was what I was thinking all along really but just wanted to be
>> > sure.
>> > Perhaps I was having a blonde moment, sure. But I'm only on day 3 of
>> > recovery from having my brain implosion when I first learnt of Event
>> > Sourcing :)
>> > On Wednesday, August 1, 2012 10:31:19 AM UTC+1, Adam Dymitruk wrote:
>> >> The answer is not one of these.
>> >> On Aug 1, 2012 2:16 AM, "Nathan Evans" wrote:
>> >>> It's purely a theoretical question. This isn't an actual project I'm
>> >>> working on.
>> >>> So I guess the answer is either one of the following:
>> >>> 1. Don't ever actually send that e-mail from a domain event. Do it
>> >>> somewhere else, such as the layer where the domain event was raised in
>> >>> the
>> >>> first place.
>> >>> 2. Continue sending that e-mail from a domain event. But wrap it in a
>> >>> condition like: if (projecting == false) { /* send e-mail */ }
>> >>> Which is it? :)
>> >>> On Wednesday, August 1, 2012 10:05:56 AM UTC+1, Adam Dymitruk wrote:
>> >>>> Your email service should be resilient to duplicate messages for one.
>> >>>> But you have a bigger issue. You don't do anything except set state
>> >>>> when
>> >>>> hydrating.
>> >>>> On Aug 1, 2012 2:03 AM, "Nathan Evans" wrote:
>> >>>>> Yeah I realise that, otherwise you'll get the problem of duplicate
>> >>>>> e-mails being sent out, duplicate web service calls, etc etc.
>> >>>>> So what is the elegant solution?
>> >>>>> Maybe this is more of a DDD question than anything. Is it simply
>> >>>>> that
>> >>>>> the domain model should purely be focused upon managing its own
>> >>>>> state and
>> >>>>> logic, rather than performing behaviours outside of its concern?
>> >>>>> Thanks.
>> >>>>> On Wednesday, August 1, 2012 9:29:32 AM UTC+1, Greg Young wrote:
>> >>>>>> Projections should never do behaviours.
>> >>>>>> On Wed, Aug 1, 2012 at 1:21 AM, Nathan Evans wrote:
>> >>>>>> > What if you have an event that say sends an e-mail. App shuts
>> >>>>>> > down.
>> >>>>>> > App
>> >>>>>> > starts up and recreates its state by replaying events. When it
>> >>>>>> > gets
>> >>>>>> > to the
>> >>>>>> > event that results in an e-mail being sent out, then it will get
>> >>>>>> > sent out
>> >>>>>> > for a second time.
>> >>>>>> > I can think of several ways around this but they all seem leaky.
>> >>>>>> > In
>> >>>>>> > the
>> >>>>>> > sense that it means the app will have to start checking whether
>> >>>>>> > it
>> >>>>>> > is "live"
>> >>>>>> > or just "replaying/projecting". This would mean that the domain
>> >>>>>> > model is at
>> >>>>>> > least slightly aware of its persistence mechanism which doesn't
>> >>>>>> > seem
>> >>>>>> > right.
>> >>>>>> > Any ideas? :)
>> >>>>>> --
>> >>>>>> 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.
How can it be done in an event but not in a projection? That was my original wonder. It sounds like you are saying that this, in certain cases, is a totally valid design? So what is the best pattern for having that event exist, but making it act like a "null event" whenever it is replayed via projection?
On Wednesday, August 1, 2012 11:43:27 AM UTC+1, Greg Young wrote:
> I am giving a generalized answer (its not always just email). What > about charging a credit card, writing a transaction to the accounting > system, or telling inventory to move the item to shipping ....
> There are loads of cases where you don't want it done as part of the > transaction for the command but prefer to do it from an event (but not > in a projection). This is where long running workflows (process > managers/sagas/whatever you want to call them) come in.
> Greg
> On Wed, Aug 1, 2012 at 6:27 AM, Nathan Evans wrote: > > That's an implementation detail more than anything, surely? And one that > is > > normally resolved with a service bus, or at least by queuing up the > e-mail > > somewhere.
> > On Wednesday, August 1, 2012 11:12:18 AM UTC+1, Greg Young wrote:
> >> Yes n infrastructure service can be used for this...
> >> A question to ask yourself though. If its temporarily failing should > >> we reject the transaction? There are times when the answer to this > >> question is a yes but more often than not its a no. If I can't send an > >> email right now to confirm your order should I not accept your order?
> >> Greg
> >> On Wed, Aug 1, 2012 at 6:05 AM, Nathan Evans wrote: > >> > Seems I was right though:
> >> > This was what I was thinking all along really but just wanted to be > >> > sure.
> >> > Perhaps I was having a blonde moment, sure. But I'm only on day 3 of > >> > recovery from having my brain implosion when I first learnt of Event > >> > Sourcing :)
> >> > On Wednesday, August 1, 2012 10:31:19 AM UTC+1, Adam Dymitruk wrote:
> >> >> The answer is not one of these.
> >> >> On Aug 1, 2012 2:16 AM, "Nathan Evans" wrote:
> >> >>> It's purely a theoretical question. This isn't an actual project > I'm > >> >>> working on.
> >> >>> So I guess the answer is either one of the following:
> >> >>> 1. Don't ever actually send that e-mail from a domain event. Do it > >> >>> somewhere else, such as the layer where the domain event was raised > in > >> >>> the > >> >>> first place.
> >> >>> 2. Continue sending that e-mail from a domain event. But wrap it in > a > >> >>> condition like: if (projecting == false) { /* send e-mail */ }
> >> >>> Which is it? :)
> >> >>> On Wednesday, August 1, 2012 10:05:56 AM UTC+1, Adam Dymitruk > wrote:
> >> >>>> Your email service should be resilient to duplicate messages for > one. > >> >>>> But you have a bigger issue. You don't do anything except set > state > >> >>>> when > >> >>>> hydrating.
> >> >>>> On Aug 1, 2012 2:03 AM, "Nathan Evans" wrote:
> >> >>>>> Yeah I realise that, otherwise you'll get the problem of > duplicate > >> >>>>> e-mails being sent out, duplicate web service calls, etc etc.
> >> >>>>> So what is the elegant solution?
> >> >>>>> Maybe this is more of a DDD question than anything. Is it simply > >> >>>>> that > >> >>>>> the domain model should purely be focused upon managing its own > >> >>>>> state and > >> >>>>> logic, rather than performing behaviours outside of its concern?
> >> >>>>> Thanks.
> >> >>>>> On Wednesday, August 1, 2012 9:29:32 AM UTC+1, Greg Young wrote:
> >> >>>>>> Projections should never do behaviours.
> >> >>>>>> On Wed, Aug 1, 2012 at 1:21 AM, Nathan Evans wrote: > >> >>>>>> > What if you have an event that say sends an e-mail. App shuts > >> >>>>>> > down. > >> >>>>>> > App > >> >>>>>> > starts up and recreates its state by replaying events. When it > >> >>>>>> > gets > >> >>>>>> > to the > >> >>>>>> > event that results in an e-mail being sent out, then it will > get > >> >>>>>> > sent out > >> >>>>>> > for a second time.
> >> >>>>>> > I can think of several ways around this but they all seem > leaky. > >> >>>>>> > In > >> >>>>>> > the > >> >>>>>> > sense that it means the app will have to start checking > whether > >> >>>>>> > it > >> >>>>>> > is "live" > >> >>>>>> > or just "replaying/projecting". This would mean that the > domain > >> >>>>>> > model is at > >> >>>>>> > least slightly aware of its persistence mechanism which > doesn't > >> >>>>>> > seem > >> >>>>>> > right.
> >> >>>>>> > Any ideas? :)
> >> >>>>>> -- > >> >>>>>> 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.
"There are loads of cases where you don't want it done as part of the
transaction for the command but prefer to do it from an event (but not
in a projection). This is where long running workflows (process
managers/sagas/whatever you want to call them) come in."
On Wed, Aug 1, 2012 at 3:52 AM, Nathan Evans <nbev...@gmail.com> wrote:
> How can it be done in an event but not in a projection? That was my original
> wonder. It sounds like you are saying that this, in certain cases, is a
> totally valid design? So what is the best pattern for having that event
> exist, but making it act like a "null event" whenever it is replayed via
> projection?
> On Wednesday, August 1, 2012 11:43:27 AM UTC+1, Greg Young wrote:
>> I am giving a generalized answer (its not always just email). What
>> about charging a credit card, writing a transaction to the accounting
>> system, or telling inventory to move the item to shipping ....
>> There are loads of cases where you don't want it done as part of the
>> transaction for the command but prefer to do it from an event (but not
>> in a projection). This is where long running workflows (process
>> managers/sagas/whatever you want to call them) come in.
>> Greg
>> On Wed, Aug 1, 2012 at 6:27 AM, Nathan Evans wrote:
>> > That's an implementation detail more than anything, surely? And one that
>> > is
>> > normally resolved with a service bus, or at least by queuing up the
>> > e-mail
>> > somewhere.
>> > On Wednesday, August 1, 2012 11:12:18 AM UTC+1, Greg Young wrote:
>> >> Yes n infrastructure service can be used for this...
>> >> A question to ask yourself though. If its temporarily failing should
>> >> we reject the transaction? There are times when the answer to this
>> >> question is a yes but more often than not its a no. If I can't send an
>> >> email right now to confirm your order should I not accept your order?
>> >> Greg
>> >> On Wed, Aug 1, 2012 at 6:05 AM, Nathan Evans wrote:
>> >> > Seems I was right though:
>> >> > This was what I was thinking all along really but just wanted to be
>> >> > sure.
>> >> > Perhaps I was having a blonde moment, sure. But I'm only on day 3 of
>> >> > recovery from having my brain implosion when I first learnt of Event
>> >> > Sourcing :)
>> >> > On Wednesday, August 1, 2012 10:31:19 AM UTC+1, Adam Dymitruk wrote:
>> >> >> The answer is not one of these.
>> >> >> On Aug 1, 2012 2:16 AM, "Nathan Evans" wrote:
>> >> >>> It's purely a theoretical question. This isn't an actual project
>> >> >>> I'm
>> >> >>> working on.
>> >> >>> So I guess the answer is either one of the following:
>> >> >>> 1. Don't ever actually send that e-mail from a domain event. Do it
>> >> >>> somewhere else, such as the layer where the domain event was raised
>> >> >>> in
>> >> >>> the
>> >> >>> first place.
>> >> >>> 2. Continue sending that e-mail from a domain event. But wrap it in
>> >> >>> a
>> >> >>> condition like: if (projecting == false) { /* send e-mail */ }
>> >> >>> Which is it? :)
>> >> >>> On Wednesday, August 1, 2012 10:05:56 AM UTC+1, Adam Dymitruk
>> >> >>> wrote:
>> >> >>>> Your email service should be resilient to duplicate messages for
>> >> >>>> one.
>> >> >>>> But you have a bigger issue. You don't do anything except set
>> >> >>>> state
>> >> >>>> when
>> >> >>>> hydrating.
>> >> >>>> On Aug 1, 2012 2:03 AM, "Nathan Evans" wrote:
>> >> >>>>> Yeah I realise that, otherwise you'll get the problem of
>> >> >>>>> duplicate
>> >> >>>>> e-mails being sent out, duplicate web service calls, etc etc.
>> >> >>>>> So what is the elegant solution?
>> >> >>>>> Maybe this is more of a DDD question than anything. Is it simply
>> >> >>>>> that
>> >> >>>>> the domain model should purely be focused upon managing its own
>> >> >>>>> state and
>> >> >>>>> logic, rather than performing behaviours outside of its concern?
>> >> >>>>> Thanks.
>> >> >>>>> On Wednesday, August 1, 2012 9:29:32 AM UTC+1, Greg Young wrote:
>> >> >>>>>> Projections should never do behaviours.
>> >> >>>>>> On Wed, Aug 1, 2012 at 1:21 AM, Nathan Evans wrote:
>> >> >>>>>> > What if you have an event that say sends an e-mail. App shuts
>> >> >>>>>> > down.
>> >> >>>>>> > App
>> >> >>>>>> > starts up and recreates its state by replaying events. When it
>> >> >>>>>> > gets
>> >> >>>>>> > to the
>> >> >>>>>> > event that results in an e-mail being sent out, then it will
>> >> >>>>>> > get
>> >> >>>>>> > sent out
>> >> >>>>>> > for a second time.
>> >> >>>>>> > I can think of several ways around this but they all seem
>> >> >>>>>> > leaky.
>> >> >>>>>> > In
>> >> >>>>>> > the
>> >> >>>>>> > sense that it means the app will have to start checking
>> >> >>>>>> > whether
>> >> >>>>>> > it
>> >> >>>>>> > is "live"
>> >> >>>>>> > or just "replaying/projecting". This would mean that the
>> >> >>>>>> > domain
>> >> >>>>>> > model is at
>> >> >>>>>> > least slightly aware of its persistence mechanism which
>> >> >>>>>> > doesn't
>> >> >>>>>> > seem
>> >> >>>>>> > right.
>> >> >>>>>> > Any ideas? :)
>> >> >>>>>> --
>> >> >>>>>> 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.
-- Le doute n'est pas une condition agréable, mais la certitude est absurde.
On Wed, Aug 1, 2012 at 12:52 PM, Nathan Evans <nbev...@gmail.com> wrote:
> How can it be done in an event but not in a projection? That was my
> original wonder. It sounds like you are saying that this, in certain cases,
> is a totally valid design? So what is the best pattern for having that
> event exist, but making it act like a "null event" whenever it is replayed
> via projection?
> On Wednesday, August 1, 2012 11:43:27 AM UTC+1, Greg Young wrote:
>> I am giving a generalized answer (its not always just email). What
>> about charging a credit card, writing a transaction to the accounting
>> system, or telling inventory to move the item to shipping ....
>> There are loads of cases where you don't want it done as part of the
>> transaction for the command but prefer to do it from an event (but not
>> in a projection). This is where long running workflows (process
>> managers/sagas/whatever you want to call them) come in.
>> Greg
>> On Wed, Aug 1, 2012 at 6:27 AM, Nathan Evans wrote:
>> > That's an implementation detail more than anything, surely? And one
>> that is
>> > normally resolved with a service bus, or at least by queuing up the
>> e-mail
>> > somewhere.
>> > On Wednesday, August 1, 2012 11:12:18 AM UTC+1, Greg Young wrote:
>> >> Yes n infrastructure service can be used for this...
>> >> A question to ask yourself though. If its temporarily failing should
>> >> we reject the transaction? There are times when the answer to this
>> >> question is a yes but more often than not its a no. If I can't send an
>> >> email right now to confirm your order should I not accept your order?
>> >> Greg
>> >> On Wed, Aug 1, 2012 at 6:05 AM, Nathan Evans wrote:
>> >> > Seems I was right though:
>> >> > This was what I was thinking all along really but just wanted to be
>> >> > sure.
>> >> > Perhaps I was having a blonde moment, sure. But I'm only on day 3 of
>> >> > recovery from having my brain implosion when I first learnt of Event
>> >> > Sourcing :)
>> >> > On Wednesday, August 1, 2012 10:31:19 AM UTC+1, Adam Dymitruk wrote:
>> >> >> The answer is not one of these.
>> >> >> On Aug 1, 2012 2:16 AM, "Nathan Evans" wrote:
>> >> >>> It's purely a theoretical question. This isn't an actual project
>> I'm
>> >> >>> working on.
>> >> >>> So I guess the answer is either one of the following:
>> >> >>> 1. Don't ever actually send that e-mail from a domain event. Do it
>> >> >>> somewhere else, such as the layer where the domain event was
>> raised in
>> >> >>> the
>> >> >>> first place.
>> >> >>> 2. Continue sending that e-mail from a domain event. But wrap it
>> in a
>> >> >>> condition like: if (projecting == false) { /* send e-mail */ }
>> >> >>> Which is it? :)
>> >> >>> On Wednesday, August 1, 2012 10:05:56 AM UTC+1, Adam Dymitruk
>> wrote:
>> >> >>>> Your email service should be resilient to duplicate messages for
>> one.
>> >> >>>> But you have a bigger issue. You don't do anything except set
>> state
>> >> >>>> when
>> >> >>>> hydrating.
>> >> >>>> On Aug 1, 2012 2:03 AM, "Nathan Evans" wrote:
>> >> >>>>> Yeah I realise that, otherwise you'll get the problem of
>> duplicate
>> >> >>>>> e-mails being sent out, duplicate web service calls, etc etc.
>> >> >>>>> So what is the elegant solution?
>> >> >>>>> Maybe this is more of a DDD question than anything. Is it simply
>> >> >>>>> that
>> >> >>>>> the domain model should purely be focused upon managing its own
>> >> >>>>> state and
>> >> >>>>> logic, rather than performing behaviours outside of its concern?
>> >> >>>>> Thanks.
>> >> >>>>> On Wednesday, August 1, 2012 9:29:32 AM UTC+1, Greg Young wrote:
>> >> >>>>>> Projections should never do behaviours.
>> >> >>>>>> On Wed, Aug 1, 2012 at 1:21 AM, Nathan Evans wrote:
>> >> >>>>>> > What if you have an event that say sends an e-mail. App shuts
>> >> >>>>>> > down.
>> >> >>>>>> > App
>> >> >>>>>> > starts up and recreates its state by replaying events. When
>> it
>> >> >>>>>> > gets
>> >> >>>>>> > to the
>> >> >>>>>> > event that results in an e-mail being sent out, then it will
>> get
>> >> >>>>>> > sent out
>> >> >>>>>> > for a second time.
>> >> >>>>>> > I can think of several ways around this but they all seem
>> leaky.
>> >> >>>>>> > In
>> >> >>>>>> > the
>> >> >>>>>> > sense that it means the app will have to start checking
>> whether
>> >> >>>>>> > it
>> >> >>>>>> > is "live"
>> >> >>>>>> > or just "replaying/projecting". This would mean that the
>> domain
>> >> >>>>>> > model is at
>> >> >>>>>> > least slightly aware of its persistence mechanism which
>> doesn't
>> >> >>>>>> > seem
>> >> >>>>>> > right.
>> >> >>>>>> > Any ideas? :)
>> >> >>>>>> --
>> >> >>>>>> 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.
