CQRS cross aggregate interaction + private state

If entities only have private state, how do you deal with interaction between aggregates?

e.g.

product = GetProduct(123);
order.AddProduct(product,3);

Lets for the sake of the argument that addproduct can not occur if product is marked as obsolete.

How would you deal with that?
What's the idea behind completely private state?
Why shouldn't order be able to read properties on product?

------------------------------------

Re: CQRS cross aggregate interaction + private state

Re: CQRS cross aggregate interaction + private state

Ah, ofcourse, it's how the old MUD games works 

player.Eat(apple);
apple.CanBeEaten(player);

I knew this, just wanted to see if your all awake *jk*

--- In domaindrivendesign <at> yahoogroups.com, Nuno Lopes <nbplopes@...> wrote:
*

>
> Maybe I can help:
> 
> class Product : IOrderableItem
> 	....
> 	void TestAddOrder(Order order, double qty)
> 	{
> 		if (this.IsObsolete())
> 			throw new BusinessException("An obsolete product cannot be ordered")
> 	}
> 
> 	void Order (Order o, double qty) {
> 		o.AddItem(this, this.REF, this.Description, this.Price, qty) 
> 	}
> 	.....
> 
> class Order 
> {
> 	void AddItem(IOrderableItem i, string REF, string description, double price, double qty)
> 	{
> 		...
> 		i.TestAddOrder(this, qty)
> 		......
> 		this.DoAddItem(new OrderLine(REF, description, price, qty));
> 	}
> }
> 
> Hope it helps.
> 
> Nuno
> 
> 
> On Feb 9, 2010, at 12:38 PM, rogeralsing wrote:
> 
> > If entities only have private state, how do you deal with interaction between aggregates?
> > 
> > e.g.
> > 
> > product = GetProduct(123);
> > order.AddProduct(product,3);
> > 
> > Lets for the sake of the argument that addproduct can not occur if product is marked as obsolete.
> > 
> > How would you deal with that?
> > What's the idea behind completely private state?
> > Why shouldn't order be able to read properties on product?
> > 
> >
>

------------------------------------

Re: CQRS cross aggregate interaction + private state

Hi Roger, 

You can find all those called "collaboration patterns" in the great book StreamLined Object Modeling. I
know it thanks to Nuno.
You can download the patterns chapter for free on the net.

Cheers.

--- In domaindrivendesign <at> yahoogroups.com, "rogeralsing" <roger.alsing@...> wrote:
*

>
> Ah, ofcourse, it's how the old MUD games works 
> 
> player.Eat(apple);
> apple.CanBeEaten(player);
> 
> I knew this, just wanted to see if your all awake *jk*
> 
> --- In domaindrivendesign <at> yahoogroups.com, Nuno Lopes <nbplopes@> wrote:
> >
> > Maybe I can help:
> > 
> > class Product : IOrderableItem
> > 	....
> > 	void TestAddOrder(Order order, double qty)
> > 	{
> > 		if (this.IsObsolete())
> > 			throw new BusinessException("An obsolete product cannot be ordered")
> > 	}
> > 
> > 	void Order (Order o, double qty) {
> > 		o.AddItem(this, this.REF, this.Description, this.Price, qty) 
> > 	}
> > 	.....
> > 
> > class Order 
> > {
> > 	void AddItem(IOrderableItem i, string REF, string description, double price, double qty)
> > 	{
> > 		...
> > 		i.TestAddOrder(this, qty)
> > 		......
> > 		this.DoAddItem(new OrderLine(REF, description, price, qty));
> > 	}
> > }
> > 
> > Hope it helps.
> > 
> > Nuno
> > 
> > 
> > On Feb 9, 2010, at 12:38 PM, rogeralsing wrote:
> > 
> > > If entities only have private state, how do you deal with interaction between aggregates?
> > > 
> > > e.g.
> > > 
> > > product = GetProduct(123);
> > > order.AddProduct(product,3);
> > > 
> > > Lets for the sake of the argument that addproduct can not occur if product is marked as obsolete.
> > > 
> > > How would you deal with that?
> > > What's the idea behind completely private state?
> > > Why shouldn't order be able to read properties on product?
> > > 
> > >
> >
>

------------------------------------

Re: CQRS cross aggregate interaction + private state

Thanks,

The information was just stuck in my BC of game development, not in the BC of DDD.
They are syncronized now, it was just a matter of eventually consistent 

--- In domaindrivendesign <at> yahoogroups.com, "sebaszipp" <sebaszipp@...> wrote:
>
> 
> Hi Roger, 
> 
> You can find all those called "collaboration patterns" in the great book StreamLined Object Modeling. I
know it thanks to Nuno.
> You can download the patterns chapter for free on the net.
> 
> Cheers.
> 
> --- In domaindrivendesign <at> yahoogroups.com, "rogeralsing" <roger.alsing@> wrote:
> >
> > Ah, ofcourse, it's how the old MUD games works 
> > 
> > player.Eat(apple);
> > apple.CanBeEaten(player);
> > 
> > I knew this, just wanted to see if your all awake *jk*
> > 
> > --- In domaindrivendesign <at> yahoogroups.com, Nuno Lopes <nbplopes@> wrote:
> > >
> > > Maybe I can help:
> > > 
> > > class Product : IOrderableItem
> > > 	....
> > > 	void TestAddOrder(Order order, double qty)
> > > 	{
> > > 		if (this.IsObsolete())
> > > 			throw new BusinessException("An obsolete product cannot be ordered")
> > > 	}
> > > 
> > > 	void Order (Order o, double qty) {
> > > 		o.AddItem(this, this.REF, this.Description, this.Price, qty) 
> > > 	}
> > > 	.....
> > > 
> > > class Order 
> > > {
> > > 	void AddItem(IOrderableItem i, string REF, string description, double price, double qty)
> > > 	{
> > > 		...
> > > 		i.TestAddOrder(this, qty)
> > > 		......
> > > 		this.DoAddItem(new OrderLine(REF, description, price, qty));
> > > 	}
> > > }
> > > 
> > > Hope it helps.
> > > 
> > > Nuno
> > > 
> > > 
> > > On Feb 9, 2010, at 12:38 PM, rogeralsing wrote:
> > > 
> > > > If entities only have private state, how do you deal with interaction between aggregates?
> > > > 
> > > > e.g.
> > > > 
> > > > product = GetProduct(123);
> > > > order.AddProduct(product,3);
> > > > 
> > > > Lets for the sake of the argument that addproduct can not occur if product is marked as obsolete.
> > > > 
> > > > How would you deal with that?
> > > > What's the idea behind completely private state?
> > > > Why shouldn't order be able to read properties on product?
> > > > 
> > > >
> > >
> >
>

------------------------------------

Re: Re: CQRS cross aggregate interaction + private state

Yeah, this is the ABC of collaboration -:)

Nuno

------------------------------------

EventSourcing and evolving behavior

Have anyone dealt with a scenario where the rules and behavior of an entity changes over time and combined
that with eventsourcing?

e.g. before 2010-01-01 there may be one set of rules, and another after that point.

And if you revert state of the entity, you might have to revert the behavior also.

I guess this is simply a case where you can keep old behavior in the entity and apply some "if data > xxx then ..."

Just wanted to hear if anyone have done this and how it turned out.

------------------------------------

Re: EventSourcing and evolving behavior

Re: EventSourcing and evolving behavior

Re: EventSourcing and evolving behavior

The events should contain the result of business rules.

When you replay events, you just get the result of those old computations from passed events. No need to
change the logic.

Let's say that before 2010-01-01 there was a logic tax calculation.
The entity threw events containing taxes computed using this logic.

After 2010-01-01, the logic change, but when an event thrown before that date is replaid, you just get the
tax value, no new calculation occures.

This is one of the benefits of storing events instead of commands.

cheers,

jeremie / thinkbeforecoding

--- In domaindrivendesign <at> yahoogroups.com, Nuno Lopes <nbplopes@...> wrote:
*

>
> Most often sum you don't revert state. You perform business transactions
> that put it back in the state you  need it to be.
> 
> On Tue, Feb 9, 2010 at 10:50 AM, Nuno Lopes <nbplopes@...> wrote:
> 
> > > And if you revert state of the entity, you might have to revert the
> > behavior also.
> >
> > This is not a challenge specific to this pattern but software in general.
> > Usually the domain resolves it in an elegant and simple way.
> >
> > Cheers,
> >
> > Nuno
> >
> >
>

------------------------------------

Re: EventSourcing and evolving behavior

Well if you call any operation on that entity after it got its old state back, it would perform that operation
using the current logic ontop of the old state... which would be incorrect.

--- In domaindrivendesign <at> yahoogroups.com, Jérémie <Jeremie.Chassaing@...> wrote:
>
> The events should contain the result of business rules.
> 
> When you replay events, you just get the result of those old computations from passed events. No need to
change the logic.
> 
> Let's say that before 2010-01-01 there was a logic tax calculation.
> The entity threw events containing taxes computed using this logic.
> 
> After 2010-01-01, the logic change, but when an event thrown before that date is replaid, you just get the
tax value, no new calculation occures.
> 
> This is one of the benefits of storing events instead of commands.
> 
> cheers,
> 
> jeremie / thinkbeforecoding
> 
> 
> --- In domaindrivendesign <at> yahoogroups.com, Nuno Lopes <nbplopes@> wrote:
> >
> > Most often sum you don't revert state. You perform business transactions
> > that put it back in the state you  need it to be.
> > 
> > On Tue, Feb 9, 2010 at 10:50 AM, Nuno Lopes <nbplopes@> wrote:
> > 
> > > > And if you revert state of the entity, you might have to revert the
> > > behavior also.
> > >
> > > This is not a challenge specific to this pattern but software in general.
> > > Usually the domain resolves it in an elegant and simple way.
> > >
> > > Cheers,
> > >
> > > Nuno
> > >
> > >
> >
>

------------------------------------