On Mon, Oct 25, 2010 at 4:44 PM, Rickard Öberg <[email protected]> wrote:
> On 2010-10-25 16.29, Paul Merlin wrote:
>>> * Eventstore - API and backend for storing events for EventSourcing.
>>> Currently based on JDBM, which works, but is not optimal perhaps
>>
>> Do you mean it's not an EntityStore ? Could there be a SPI to implement
>> several
>> backends ?
>
> It's a completely different thing, and yes, an SPI+impl would be best. There
> are some interesting possibilities here, including some very low-fi
> implementations.
What do you mean by "low-fi implementations"? So instead of simply;
@Immutable
public interface DomainEvent extends Entity
{}
you also want to pave the way for some more interesting aspects;
- DomainEvents stacked up and fired at full completion of UoW?
- Therefor not partOf, but a resultOf a UoW. Outside the transaction,
can't fail, bla bla bla?
In this context, I today saw a Greg Young presentation where he asked
the audience of "Who uses a UnitOfWork with Repositories?", then some
vague comment about "should not" but not clearly defining why? Or
perhaps I misunderstood him... Do you know what he might be referring
to ?
The rest of the stuff in the original post looks good, and I agree with it.
One comment; "logs should be placed" --> Doesn't that suggest that
SLF4J needs a backend that is in line with that too? (Not to mention
my pet peeve that all Logging is fundamentally wrong, but I got no
strength left to argue about it, since it is too ingrained in our
minds.)
Time to create some JIRA issues.
Cheers
--
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java
I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
