On 2010-10-25 23.01, Niclas Hedhman wrote:
What do you mean by "low-fi implementations"?
Event storage as text files with event in JSON-format per line. Very
low-fi. Easy to deliver as Atom feeds, easy to archive (gzip), easy to
browse manually.
@Immutable
public interface DomainEvent extends Entity
{}
In Streamflow our DomainEvent looks like this:
public interface DomainEvent
extends ValueComposite, Identity
{
// Dummy event to be used when calling event methods from commands
public static DomainEvent CREATE = new DomainEventDummy();
// Usecase
Property<String> usecase();
// Name of method/event
Property<String> name();
// Id of the entity that generated the event
Property<String> entity();
// When the event occurred
Property<Date> on();
// Who performed the event
@Optional
Property<String> by();
// Method parameters as JSON
Property<String> parameters();
// Type of the entity being invoked
Property<String> entityType();
// Version of the application
Property<String> version();
// Dummy event class
class DomainEventDummy
implements DomainEvent
{
// Dummy-impl omitted
}
}
So far this seems to cover all our needs.
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?
When domain model handles commands in a UoW they create events that are
gathered in a list in the UoW. Upon complete that list is written to the
eventstore.
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 ?
His point is that you only need a UoW if you are modifying several
aggregates with one command, which you "shouldn't". Which is correct if
you have a fully distributed/shared solution, but also brings a whole
lot of other complexity since you NEED eventsourcing to synchronize
aggregates physically living on different machines but which care about
the same event.
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.)
True. We have a LogService in Streamflow that adds appenders based on
the FileConfiguration server. I suppose a reasonably generic version of
that could be included as library.
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
