maybe you could use some kind of Proxy pattern and just have the view display a placeholder, a bit like data management (Flex/LCDS) or FilePromises (AIR 2) do ?

I tried it on some pretty small code where the domain object was able to persist itself. Asynchronosly of course. The thing I ended up doing was that the repository method save had an optional parameter where I could inject a function which should be called after the repository had done it’s bit. The various views could then inject handler-functions for when the domain-object was persisted.

Not the prettiest of sights, but it worked well enough

@EECOLOR: Having a thread model in the Flash player would certainly be useful for such scenarios. I wonder if the player team has been thinking about adding threading support.

Yes, it is possible, but results in locking up your system aswell. The Flash player tends to do things as fast as it can. Until we have some kind of a thread model and are able to do infinit loops without crashing the player we will not be able to turn async. into symc.

Greetz Erik

If, as I’m assuming, dealing with a repository is all about requesting the persistence of changes to domain objects or requesting the objects themselves, can’t we use a Responder pattern and binding just as with classic service calls? The view doesn’t need to know anything more, it just uses binding to keep up to date with changes to objects.

Again, I’m not familiar with all the requirements of DDD, so I may be missing something fundamental.