Why InjectorHelper?

[Roland Kofler]

Hello, let me clear up my mind.
Every aggregate should publish all its domain-events.
Therefore everey aggregate needs the DomainEventPublisher.
Why is it that you try to control the injection of it manually with
InjectorHelper?

To be frank, I want to implement a full event store from the
begining,
so maybe I miss an argument with your traditonal JPA based
persistence...

Thanks,
Roland

[Sławomir Sobótka]

Hello

At this stage (milestone 1) we have not introduced Event Sourcing.
In this sample events are used in order to:
- communicate between bounded contexts in totally decoupled way...
- according to previous: ...way that promotes plugins
- to delegate time-consuming and not consistency-critical operations
to asynchronous time space
- to update read models

Therefore current design does not look like classical ES aggregate
that contains list of events (changes in aggregate)
At this approach events communicate important situations, not all
changes that were done inside.

So just t to sume up:
- we have segregation of the responsibility by commands and queries
(write model based on jpa, read model: all possible solutions)
- do do not have event sourcing persistence style

[Roland Kofler]

Ok and this is the reason for InjectorHelper?
Thanks.

On Jan 25, 5:20 pm, Sławomir Sobótka <sso...@gmail.com> wrote:
> Hello
>
> At this stage (milestone 1) we have not introduced Event Sourcing.
> In this sample events are used in order to:
> - communicate between bounded contexts in totally decoupled way...
> - according to previous: ...way that promotes plugins
> - to delegate time-consuming and not consistency-critical operations
> to asynchronous time space
> - to update read models
>
> Therefore current design does not look like classical ES aggregate
> that contains list of events (changes in aggregate)
> At this approach events communicate important situations, not all
> changes that were done inside.
>
> So just t to sume up:
> - we have segregation of the responsibility by commands and queries
> (write model based on jpa, read model: all possible solutions)
> - do do not have event sourcing persistence style
>

[Sławomir Sobótka]

We want every Aggregate to have access to EventsEngine - aggregate
publish event whenever it wants to.

So how could Aggregate talk to EventsEngie...
one option is talking to the Singletin - bad idea because of impact on
testability
therefore we inject it into the Aggregate.

We inject it manually inside Factory and Repository. Logic of
injecting is common, so we moved it to the InjectorHelper.
But as mentioned in wiki: this is just a general sample. We wanted to
present it explicitly with no magic tricks so that everyone (from
outside of the java world) could grasp idea quickly.

In Spring You can inject dependencies into objects that are not
managed by Spring - just use @Configurable annotation.
It's simple form the syntax point of view but need to understand tons
of Spring magic. So we decided to not doing this. Proficient Java
developers use @Configurable anyway:)

2012/1/25 Roland Kofler <roland...@gmail.com>: