Re: deleting

Maybe the example given isn't the best one, the client administration dept
should not be able to remove a client from its records if the company is
still in the process of doing business (invoices, deliveries etc) with it.
That would not make sense if the client admin is the authoritative source
of the list of clients. If your process however is to always remove a
client from the database as soon as all business transactions with this
entity are completed then that's a different thing which can be modelled
using events.

From a technical perspective, i don't understand the recent wave of
aversion towards XA because it works very well and solves a lot of
potential headaches. It scales quite well for most business applications
that handle "limited" audiences, "limited" meaning
non-twitter-facebook-google or whatever **-social api you would be offering.

Jorg




On Thu, Jul 11, 2013 at 7:57 AM, Tom Eugelink <[email protected]> wrote:

> **
>
>
>
> Suppose a context owns a certain aggregate and another uses it. Now the
> owning context is suppose to remove the aggregate and within its own
> context has no problem doing so. But the other context can agree with the
> removing of the aggrgate. An example would be some client administration
> context and an invoice context. The client may be removed, but as long as
> there are unpaid invoices, or even invoices to be created, the invoice
> context simply can handle a removed client.
>
> The question is; is there any good way to handle the setup without using
> distributed transactions (JMS with JTA/XA) and also without manually
> keeping track of acknowledgements that other contexts need to send before a
> client can be deleted?
>
> Tom
>
>  
>