Erm, no.

Why don't you believe me, man?  What is wrong with you?  Are you a troll?


--- In domaindrivendesign@yahoogroups.com, Greg Young <gregoryyoung1@...> wrote:
>
> It is a central theme that your model •is• your ubiquitous
> language. The whole point is tosolve communications problems. You are
> introducing a level of translation which equates to the telephone game.
>
> Sent from my iPhone
>
> On 2009-11-01, at 18:37, "eben_roux" <eben.roux@...> wrote:
>
> > Well,
> >
> > I am offended since I've read the book twice! :)
> >
> > Anyway, people aren't going to agree on everything and the fact that
> > someone has put ink to paper doesn't make it law. I have a friend
> > who I regard an absolute genius that doesn't have a single kind word
> > about DDD. Me, I like DDD.
> >
> > What you need to remember, Greg, is that I am not saying your model
> > should be separate from your UL. What I am saying is the they feed
> > off of each other.
> >
> > Just the other day a user said: "Well, we call it a factor". Guess
> > what. 'Factor' it became! --- in the model.
> >
> > Cheers,
> > Eben
> >
> > --- In domaindrivendesign@yahoogroups.com, Greg Young
> > <gregoryyoung1@> wrote:
> > >
> > > Not to be offensive in any way but I think you should re-read the
> > book.
> > >
> > > The model is an incarnation of the language, otherwise what's the
> > > point; all the same communications issues exist.
> > >
> > > Sent from my iPhone
> > >
> > > On 2009-11-01, at 17:58, "eben_roux" <eben.roux@> wrote:
> > >
> > > > I think there is a domain model and then there is a ubiquitous
> > > > language. Why would one want to (or need to) discuss lazy-loading
> > > > with a domain expert?
> > > >
> > > > I wouldn't discuss factories or an AR with them. I would be able
> > to
> > > > determine from discussions with them when something *is* an AR
> > > > within a specific use case, or where a behaviour belongs.
> > > >
> > > > It is our job to create the model from what these people tell us
> > and
> > > > even then it may be refined later (as we know from examples in
> > that
> > > > Evans chap's book or from, like, real projects).
> > > >
> > > > So it is an evolving thing, this UL. Our domain model should
> > reflect
> > > > terms and behaviours gleaned from the UL bu I am pretty sure the
> > > > domain will contain more that *just* a source-code version of
> > the UL.
> > > >
> > > > Sent from my home PC.
> > > >
> > > > --- In domaindrivendesign@yahoogroups.com, Greg Young
> > > > <gregoryyoung1@> wrote:
> > > > >
> > > > > What about your domain model being your ubiquitous language?
> > Sure
> > > > use
> > > > > cases are a bit different but what about conversations with
> > domain
> > > > > experts.
> > > > >
> > > > > Sent from my iPhone
> > > > >
> > > > > On 2009-11-01, at 17:37, "eben_roux" <eben.roux@> wrote:
> > > > >
> > > > > > Hey Greg,
> > > > > >
> > > > > > Lazy loading is irrelevant to users or even to a use case.
> > It is
> > > > an
> > > > > > implementation detail that requires weighing up different
> > factors
> > > > > > (something you know).
> > > > > >
> > > > > > A use case either needs certain objects loaded (whenever) or
> > it
> > > > does
> > > > > > not. So relax about the lazy-loading.
> > > > > >
> > > > > > Cheers,
> > > > > > Eben
> > > > > >
> > > > > > --- In domaindrivendesign@yahoogroups.com, Greg Young
> > > > > > <gregoryyoung1@> wrote:
> > > > > > >
> > > > > > > You misunderstood, cqrs does not change your discussions
> > at all.
> > > > > > > Lazyloading does.
> > > > > > >
> > > > > > > Sent from my iPhone
> > > > > > >
> > > > > > > On 2009-11-01, at 17:11, "vvernon_shiftmethod"
> > > > > > > <vvernon@> wrote:
> > > > > > >
> > > > > > > > Right. That would be analogous to what Eben is doing.
> > > > > > > >
> > > > > > > > Vaughn
> > > > > > > >
> > > > > > > > --- In domaindrivendesign@yahoogroups.com, Greg Young
> > > > > > > > <gregoryyoung1@> wrote:
> > > > > > > > >
> > > > > > > > > There are no domain discussions that are cqrs related.
> > > > > > > > >
> > > > > > > > > Sent from my iPhone
> > > > > > > > >
> > > > > > > > > On 2009-11-01, at 16:54, "vvernon_shiftmethod"
> > > > > > > > > <vvernon@> wrote:
> > > > > > > > >
> > > > > > > > > > True, but they also don't need to know about lazy
> > > > loading or
> > > > > > ORMs
> > > > > > > > > > either. There is a watershed between the model they
> > know
> > > > > > about and
> > > > > > > > > > the model that must function. Do domain experts
> > share in
> > > > > > > > discussions
> > > > > > > > > > that are strictly CQRS related?
> > > > > > > > > >
> > > > > > > > > > Vaughn
> > > > > > > > > >
> > > > > > > > > > --- In domaindrivendesign@yahoogroups.com, Greg Young
> > > > > > > > > > <gregoryyoung1@> wrote:
> > > > > > > > > > >
> > > > > > > > > > > Something in the model that domain experts don't
> > need to
> > > > > > know?
> > > > > > > > > > >
> > > > > > > > > > > What ever happenned to the model being the
> > > > representation
> > > > > > of the
> > > > > > > > > > > ubiquitous language?
> > > > > > > > > > >
> > > > > > > > > > > Sent from my iPhone
> > > > > > > > > > >
> > > > > > > > > > > On 2009-11-01, at 16:45, "vvernon_shiftmethod"
> > > > > > > > > > > <vvernon@> wrote:
> > > > > > > > > > >
> > > > > > > > > > > > Greg,
> > > > > > > > > > > >
> > > > > > > > > > > > FWIW, Eben is adopting Udi's style of breaking
> > > > persistence
> > > > > > > > into a
> > > > > > > > > > > > serious of events to get around ORM. I don't
> > really
> > > > like
> > > > > > this
> > > > > > > > > > > > either, but it does allow some to function outside
> > > > the ORM
> > > > > > > > or CQRS
> > > > > > > > > > > > approaches. I would think that as long as all this
> > > > > > activity
> > > > > > > > stays
> > > > > > > > > > > > inside the model it could be acceptable. In other
> > > > words,
> > > > > > it's
> > > > > > > > > > > > implementation and domain experts don't need to
> > know
> > > > it
> > > > > > exits.
> > > > > > > > > > > >
> > > > > > > > > > > > Vaughn
> > > > > > > > > > > >
> > > > > > > > > > > > --- In domaindrivendesign@yahoogroups.com, Greg
> > Young
> > > > > > > > > > > > <gregoryyoung1@> wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > Are you suggesting that this will be in your
> > > > ubiquitous
> > > > > > > > > > language and
> > > > > > > > > > > > > you will discuss lazy loading with domain
> > experts?
> > > > That
> > > > > > > > doesn't
> > > > > > > > > > > > sound
> > > > > > > > > > > > > very productive to me.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Greg
> > > > > > > > > > > > >
> > > > > > > > > > > > > Sent from my iPhone
> > > > > > > > > > > > >
> > > > > > > > > > > > > On 2009-11-01, at 14:54, "eben_roux"
> > <eben.roux@>
> > > > wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > > Hey Greg,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Well, I don't really think it's
> > infrastructure.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > The domain event handler will use a
> > repository to
> > > > > > fetch
> > > > > > > > the
> > > > > > > > > > > > data. I
> > > > > > > > > > > > > > am simply trying to get around the no ORM
> > issue.
> > > > > > People
> > > > > > > > seem
> > > > > > > > > > to
> > > > > > > > > > > > use
> > > > > > > > > > > > > > lazy load quite a bit and this is simply
> > another
> > > > way
> > > > > > to
> > > > > > > > get
> > > > > > > > > > the
> > > > > > > > > > > > > > required collection.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > There are a multitude of ways to do this. Some
> > > > folks
> > > > > > like
> > > > > > > > > > the old
> > > > > > > > > > > > > > 'double-dispatch' by sending in the
> > > > repository ;) ---
> > > > > > > > still
> > > > > > > > > > not
> > > > > > > > > > > > > > infrastructure.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Cheers,
> > > > > > > > > > > > > > Eben
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > --- In domaindrivendesign@yahoogroups.com,
> > Greg
> > > > Young
> > > > > > > > > > > > > > <gregoryyoung1@> wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > This sounds to me of infrastructure concerns
> > > > leaking
> > > > > > > > into
> > > > > > > > > > your
> > > > > > > > > > > > > > domain.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Greg
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Saturday, October 31, 2009, eben_roux
> > > > > > <eben.roux@>
> > > > > > > > wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Hello all,
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > OK, so I don't use an ORM. It always
> > bugged me
> > > > > > that I
> > > > > > > > > > wouldn't
> > > > > > > > > > > > > > always know what happened in the domain
> > without an
> > > > > > ORM.
> > > > > > > > > > Luckily
> > > > > > > > > > > > > > Udi's clever domain events solved *that*
> > problem.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Another thing that has always bugged me
> > is the
> > > > > > > > deferred
> > > > > > > > > > > > > > loading / lazy loading thing. Now I don't like
> > > > lazy
> > > > > > > > loading.
> > > > > > > > > > > > > > However, I've been thinking that them domain
> > > > events
> > > > > > > > could be
> > > > > > > > > > > > used to
> > > > > > > > > > > > > > do *that* then also.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Something like a 'PaymentPlanRequired'
> > event
> > > > can
> > > > > > be
> > > > > > > > > > raised and
> > > > > > > > > > > > > > the 'Loan' and be passed along. The event
> > handler
> > > > > > could
> > > > > > > > > > fetch the
> > > > > > > > > > > > > > payment plan and hand it to the Loan.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Any thoughts? --- maybe this has been
> > > > mentioned or
> > > > > > > > > > discussed
> > > > > > > > > > > > > > elsewhere and I may simply not be aware of it.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Regards,
> > > > > > > > > > > > > > > > Eben
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > --
> > > > > > > > > > > > > > > Les erreurs de grammaire et de syntaxe ont
> > > > > > > > > > ÃÆ'Æ'Æ'ÃÆ'†'ÃÆ'Æ'â€
> > 'ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'â
> > > > €šÃÆ'‚©tÃÆ'Æ'Æ'ÃÆ'†'ÃÆ'Æ'Ã
> > ¢â‚¬ 'ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ÃÆ'Æ'
> > > > > > ‚ÃÆ'‚© incluses
> > > > > > > > > > > > pour m'ass
> > > > > > > > > > > > > > urer
> > > > > > > > > > > > > > > de votre attention
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > >
> >
> >
>

Ah yes.  A heuristic.

What are you on about?

Either you load a snapshot or you don't.

You don't load a "well here is an idea of what I want thingy majig".


--- In domaindrivendesign@yahoogroups.com, Greg Young <gregoryyoung1@...> wrote:
>
> As a heuristic sure..
>
> Event storage as a concept though has 0 impedence mismatch.
>
>
>
> Sent from my iPhone
>
> On 2009-11-01, at 18:39, "eben_roux" <eben.roux@...> wrote:
>
> > Load any snapshots recently?
> >
> > --- In domaindrivendesign@yahoogroups.com, Greg Young
> > <gregoryyoung1@> wrote:
> > >
> > > Agreed, event storage is that simple thing.
> > >
> > > Sent from my iPhone
> > >
> > > On 2009-11-01, at 18:04, "eben_roux" <eben.roux@> wrote:
> > >
> > > > Hi Dan,
> > > >
> > > > Just don't like them --- well, only *really* looked at NHibernate
> > > > and read-up on the EF and used Linq to Sql. And they are slower
> > (OK,
> > > > not much).
> > > >
> > > > It just seems like *soooo* much effort to do the simplest things
> > > > when your own mapping or a couple of lines of code can do the same
> > > > thing.
> > > >
> > > > But deep down I feel that somewhere there is an opportunity for a
> > > > very simple ORM that focuses on the C side of CQRS. NHibernate
> > seems
> > > > like it's grown into a bit of a monster. We need something fresh
> > and
> > > > light weight.
> > > >
> > > > Eben
> > > >
> > > > --- In domaindrivendesign@yahoogroups.com, "danhaywood@"
> > > > <danhaywood@> wrote:
> > > > >
> > > > > --- "eben_roux" <eben.roux@> wrote:
> > > > > >
> > > > > > OK, so I don't use an ORM.
> > > > >
> > > > > Just interested to know, what the reason is that you don't,
> > since
> > > > it sounds like you're hitting use cases where some of an ORM's
> > > > features would be helpful? Maybe you've stated why in a previous
> > post?
> > > > >
> > > > > Dan
> > > > >
> > > >
> > > >
> > >
> >
> >
>

 

Ah yes. A heuristic.

What are you on about?

Either you load a snapshot or you don't.

You don't load a "well here is an idea of what I want thingy majig".

--- In domaindrivendesign@yahoogroups.com, Greg Young <gregoryyoung1@...> wrote:
>
> As a heuristic sure..
>
> Event storage as a concept though has 0 impedence mismatch.
>
>
>
> Sent from my iPhone
>
> On 2009-11-01, at 18:39, "eben_roux" <eben.roux@...> wrote:
>
> > Load any snapshots recently?
> >
> > --- In domaindrivendesign@yahoogroups.com, Greg Young
> > <gregoryyoung1@> wrote:
> > >
> > > Agreed, event storage is that simple thing.
> > >
> > > Sent from my iPhone
> > >
> > > On 2009-11-01, at 18:04, "eben_roux" <eben.roux@> wrote:
> > >
> > > > Hi Dan,
> > > >
> > > > Just don't like them --- well, only *really* looked at NHibernate
> > > > and read-up on the EF and used Linq to Sql. And they are slower
> > (OK,
> > > > not much).
> > > >
> > > > It just seems like *soooo* much effort to do the simplest things
> > > > when your own mapping or a couple of lines of code can do the same
> > > > thing.
> > > >
> > > > But deep down I feel that somewhere there is an opportunity for a
> > > > very simple ORM that focuses on the C side of CQRS. NHibernate
> > seems
> > > > like it's grown into a bit of a monster. We need something fresh
> > and
> > > > light weight.
> > > >
> > > > Eben
> > > >
> > > > --- In domaindrivendesign@yahoogroups.com, "danhaywood@"
> > > > <danhaywood@> wrote:
> > > > >
> > > > > --- "eben_roux" <eben.roux@> wrote:
> > > > > >
> > > > > > OK, so I don't use an ORM.
> > > > >
> > > > > Just interested to know, what the reason is that you don't,
> > since
> > > > it sounds like you're hitting use cases where some of an ORM's
> > > > features would be helpful? Maybe you've stated why in a previous
> > post?
> > > > >
> > > > > Dan
> > > > >
> > > >
> > > >
> > >
> >
> >
>

 

Ah yes. A heuristic.

What are you on about?

Either you load a snapshot or you don't.

You don't load a "well here is an idea of what I want thingy majig".

--- In domaindrivendesign@yahoogroups.com, Greg Young <gregoryyoung1@...> wrote:
>
> As a heuristic sure..
>
> Event storage as a concept though has 0 impedence mismatch.
>
>
>
> Sent from my iPhone
>
> On 2009-11-01, at 18:39, "eben_roux" <eben.roux@...> wrote:
>
> > Load any snapshots recently?
> >
> > --- In domaindrivendesign@yahoogroups.com, Greg Young
> > <gregoryyoung1@> wrote:
> > >
> > > Agreed, event storage is that simple thing.
> > >
> > > Sent from my iPhone
> > >
> > > On 2009-11-01, at 18:04, "eben_roux" <eben.roux@> wrote:
> > >
> > > > Hi Dan,
> > > >
> > > > Just don't like them --- well, only *really* looked at NHibernate
> > > > and read-up on the EF and used Linq to Sql. And they are slower
> > (OK,
> > > > not much).
> > > >
> > > > It just seems like *soooo* much effort to do the simplest things
> > > > when your own mapping or a couple of lines of code can do the same
> > > > thing.
> > > >
> > > > But deep down I feel that somewhere there is an opportunity for a
> > > > very simple ORM that focuses on the C side of CQRS. NHibernate
> > seems
> > > > like it's grown into a bit of a monster. We need something fresh
> > and
> > > > light weight.
> > > >
> > > > Eben
> > > >
> > > > --- In domaindrivendesign@yahoogroups.com, "danhaywood@"
> > > > <danhaywood@> wrote:
> > > > >
> > > > > --- "eben_roux" <eben.roux@> wrote:
> > > > > >
> > > > > > OK, so I don't use an ORM.
> > > > >
> > > > > Just interested to know, what the reason is that you don't,
> > since
> > > > it sounds like you're hitting use cases where some of an ORM's
> > > > features would be helpful? Maybe you've stated why in a previous
> > post?
> > > > >
> > > > > Dan
> > > > >
> > > >
> > > >
> > >
> >
> >
>

Troll much?

--- In domaindrivendesign@yahoogroups.com, Greg Young <gregoryyoung1@...> wrote:
>
>
http://www.google.ca/m/url?cd=1&client=safari&ct=res&ei=CdLtSpDQKce5jAfrwoiOAg&h\
l=en&oe=UTF-8&oi=glossary_definition&q=http%3A%2F%2Fwww.google.ca%2Fsearch%3Fq%3\
Ddefine%253Aheuristic&resnum=1&sa=X&usg=AFQjCNF_jk-Q7evHoi_bYDGboxJPa2-gJw
>
> Sent from my iPhone
>
> On 2009-11-01, at 20:17, "eben_roux" <eben.roux@...> wrote:
>
> > Ah yes. A heuristic.
> >
> > What are you on about?
> >
> > Either you load a snapshot or you don't.
> >
> > You don't load a "well here is an idea of what I want thingy majig".
> >
> > --- In domaindrivendesign@yahoogroups.com, Greg Young
> > <gregoryyoung1@> wrote:
> > >
> > > As a heuristic sure..
> > >
> > > Event storage as a concept though has 0 impedence mismatch.
> > >
> > >
> > >
> > > Sent from my iPhone
> > >
> > > On 2009-11-01, at 18:39, "eben_roux" <eben.roux@> wrote:
> > >
> > > > Load any snapshots recently?
> > > >
> > > > --- In domaindrivendesign@yahoogroups.com, Greg Young
> > > > <gregoryyoung1@> wrote:
> > > > >
> > > > > Agreed, event storage is that simple thing.
> > > > >
> > > > > Sent from my iPhone
> > > > >
> > > > > On 2009-11-01, at 18:04, "eben_roux" <eben.roux@> wrote:
> > > > >
> > > > > > Hi Dan,
> > > > > >
> > > > > > Just don't like them --- well, only *really* looked at
> > NHibernate
> > > > > > and read-up on the EF and used Linq to Sql. And they are
> > slower
> > > > (OK,
> > > > > > not much).
> > > > > >
> > > > > > It just seems like *soooo* much effort to do the simplest
> > things
> > > > > > when your own mapping or a couple of lines of code can do
> > the same
> > > > > > thing.
> > > > > >
> > > > > > But deep down I feel that somewhere there is an opportunity
> > for a
> > > > > > very simple ORM that focuses on the C side of CQRS. NHibernate
> > > > seems
> > > > > > like it's grown into a bit of a monster. We need something
> > fresh
> > > > and
> > > > > > light weight.
> > > > > >
> > > > > > Eben
> > > > > >
> > > > > > --- In domaindrivendesign@yahoogroups.com, "danhaywood@"
> > > > > > <danhaywood@> wrote:
> > > > > > >
> > > > > > > --- "eben_roux" <eben.roux@> wrote:
> > > > > > > >
> > > > > > > > OK, so I don't use an ORM.
> > > > > > >
> > > > > > > Just interested to know, what the reason is that you don't,
> > > > since
> > > > > > it sounds like you're hitting use cases where some of an ORM's
> > > > > > features would be helpful? Maybe you've stated why in a
> > previous
> > > > post?
> > > > > > >
> > > > > > > Dan
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > >
> >
> >
>

And to you.

--- In domaindrivendesign@yahoogroups.com, Greg Young <gregoryyoung1@...> wrote:
>
> Good luck to you mate.
>
> Sent from my iPhone
>
> On 2009-11-01, at 20:17, "eben_roux" <eben.roux@...> wrote:
>
> > Ah yes. A heuristic.
> >
> > What are you on about?
> >
> > Either you load a snapshot or you don't.
> >
> > You don't load a "well here is an idea of what I want thingy majig".
> >
> > --- In domaindrivendesign@yahoogroups.com, Greg Young
> > <gregoryyoung1@> wrote:
> > >
> > > As a heuristic sure..
> > >
> > > Event storage as a concept though has 0 impedence mismatch.
> > >
> > >
> > >
> > > Sent from my iPhone
> > >
> > > On 2009-11-01, at 18:39, "eben_roux" <eben.roux@> wrote:
> > >
> > > > Load any snapshots recently?
> > > >
> > > > --- In domaindrivendesign@yahoogroups.com, Greg Young
> > > > <gregoryyoung1@> wrote:
> > > > >
> > > > > Agreed, event storage is that simple thing.
> > > > >
> > > > > Sent from my iPhone
> > > > >
> > > > > On 2009-11-01, at 18:04, "eben_roux" <eben.roux@> wrote:
> > > > >
> > > > > > Hi Dan,
> > > > > >
> > > > > > Just don't like them --- well, only *really* looked at
> > NHibernate
> > > > > > and read-up on the EF and used Linq to Sql. And they are
> > slower
> > > > (OK,
> > > > > > not much).
> > > > > >
> > > > > > It just seems like *soooo* much effort to do the simplest
> > things
> > > > > > when your own mapping or a couple of lines of code can do
> > the same
> > > > > > thing.
> > > > > >
> > > > > > But deep down I feel that somewhere there is an opportunity
> > for a
> > > > > > very simple ORM that focuses on the C side of CQRS. NHibernate
> > > > seems
> > > > > > like it's grown into a bit of a monster. We need something
> > fresh
> > > > and
> > > > > > light weight.
> > > > > >
> > > > > > Eben
> > > > > >
> > > > > > --- In domaindrivendesign@yahoogroups.com, "danhaywood@"
> > > > > > <danhaywood@> wrote:
> > > > > > >
> > > > > > > --- "eben_roux" <eben.roux@> wrote:
> > > > > > > >
> > > > > > > > OK, so I don't use an ORM.
> > > > > > >
> > > > > > > Just interested to know, what the reason is that you don't,
> > > > since
> > > > > > it sounds like you're hitting use cases where some of an ORM's
> > > > > > features would be helpful? Maybe you've stated why in a
> > previous
> > > > post?
> > > > > > >
> > > > > > > Dan
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > >
> >
> >
>

Udi,

Ok, I misunderstood. I thought that just a week or two ago it was the case.
Perhaps it wasn't you but someone else who misapplied your blog.

Vaughn



--- In domaindrivendesign@yahoogroups.com, "Udi Dahan" <thesoftwaresimplist@...>
wrote:
>
> > FWIW, Eben is adopting Udi's style of breaking persistence into a serious
> of events to get around ORM
>
>
>
> Umm, I've never suggested that style.
>
>
>
> The only thing that I believe could reasonably be attributed to me is
> raising events from the domain model,
>
> when those events aren't defined on the entity objects themselves:
>
>
>
> http://www.udidahan.com/2009/06/14/domain-events-salvation/
>
>
>
> The main goal of these events are to indicate state changes that the domain
> has taken as a result of business rules to anything outside the domain
> model.
>
>
>
> Using this "pattern" in order to get around an ORM was never my intent, nor
> do I recommend it.
>
> In the case where one wishes to persist their domain model to a relational
> DB, I recommend using an ORM.
>
>
>
> Hope that is clear.
>
>
>
> Thanks,
>
>
>
> -- Udi Dahan
>
>
>
> From: domaindrivendesign@yahoogroups.com
> [mailto:domaindrivendesign@yahoogroups.com] On Behalf Of vvernon_shiftmethod
> Sent: Sunday, November 01, 2009 4:46 PM
> To: domaindrivendesign@yahoogroups.com
> Subject: [domaindrivendesign] Re: Domain Events / Fetching Data / No ORM
>
>
>
>
>
> Greg,
>
> FWIW, Eben is adopting Udi's style of breaking persistence into a serious of
> events to get around ORM. I don't really like this either, but it does allow
> some to function outside the ORM or CQRS approaches. I would think that as
> long as all this activity stays inside the model it could be acceptable. In
> other words, it's implementation and domain experts don't need to know it
> exits.
>
> Vaughn
>
> --- In domaindrivendesign@yahoogroups.com
> <mailto:domaindrivendesign%40yahoogroups.com> , Greg Young
> <gregoryyoung1@> wrote:
> >
> > Are you suggesting that this will be in your ubiquitous language and
> > you will discuss lazy loading with domain experts? That doesn't sound
> > very productive to me.
> >
> > Greg
> >
> > Sent from my iPhone
> >
> > On 2009-11-01, at 14:54, "eben_roux" <eben.roux@> wrote:
> >
> > > Hey Greg,
> > >
> > > Well, I don't really think it's infrastructure.
> > >
> > > The domain event handler will use a repository to fetch the data. I
> > > am simply trying to get around the no ORM issue. People seem to use
> > > lazy load quite a bit and this is simply another way to get the
> > > required collection.
> > >
> > > There are a multitude of ways to do this. Some folks like the old
> > > 'double-dispatch' by sending in the repository ;) --- still not
> > > infrastructure.
> > >
> > > Cheers,
> > > Eben
> > >
> > > --- In domaindrivendesign@yahoogroups.com
> <mailto:domaindrivendesign%40yahoogroups.com> , Greg Young
> > > <gregoryyoung1@> wrote:
> > > >
> > > > This sounds to me of infrastructure concerns leaking into your
> > > domain.
> > > >
> > > > Greg
> > > >
> > > > On Saturday, October 31, 2009, eben_roux <eben.roux@> wrote:
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Hello all,
> > > > >
> > > > > OK, so I don't use an ORM. It always bugged me that I wouldn't
> > > always know what happened in the domain without an ORM. Luckily
> > > Udi's clever domain events solved *that* problem.
> > > > >
> > > > > Another thing that has always bugged me is the deferred
> > > loading / lazy loading thing. Now I don't like lazy loading.
> > > However, I've been thinking that them domain events could be used to
> > > do *that* then also.
> > > > >
> > > > > Something like a 'PaymentPlanRequired' event can be raised and
> > > the 'Loan' and be passed along. The event handler could fetch the
> > > payment plan and hand it to the Loan.
> > > > >
> > > > > Any thoughts? --- maybe this has been mentioned or discussed
> > > elsewhere and I may simply not be aware of it.
> > > > >
> > > > > Regards,
> > > > > Eben
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > > --
> > > > Les erreurs de grammaire et de syntaxe ont été incluses pour m'ass
> > > urer
> > > > de votre attention
> > > >
> > >
> > >
> >
>

Hey Nuno,

You know what?  I have been following this group for some time and it is
interesting how some folks react to different ideas.  Now I am a native English
speaker although English is my second language (hence, some errors may creep
in).  You talk a lot of sense.  Now I have found the way Greg, for one, answers
some questions quite laughable.  I, for one, am on a crusade to try to improve
my software and welcome new ideas and I try to implement the stuff so I can get
a feel for it.

But it is frustrating when one is shot down for no apparent reason.  It is fine
to say "Here is my opinion" but when someone says "Here is my opinion.  Your's
sucks.  Here's a dictionary definition, blah, blah" then I tend to move to a
state of ignoring them and *that* is a pity when between all the bullshit (not
talking about you here though) there is actually some smarts.

As Vaughn stated in one of his posts, most folks on this site actually know what
they're doing.  Now some have been coding for longer than others and have,
therefore, made more mistakes, learnt more, or were taught crap like 'Structured
Programming' --- something I did at Technikon for 3 years.  My COBOL was pretty
hot :)

Hey I even wrote my first game on a VIC20 in 1985!

Getting back to this stuff.  I am all for logging.  These events seem to me to
fall into that category.  However, one could rebuild you AR with some cleverness
from these but I *really* think that *that* has an effect on your design.  The
same kind of thing happens when persistence concerns are pulled into the domain.
Yet everyone pops a brain vessel when *that* happens.  Geez, now even using a
repository in a domain event seems to be infrastructure.

Right, so now we write Greg's write once event stream.  Now the event structure
changes because we have a new requirement.  So *actually* it cannot change
because how are we going to replay that original event.  "Ah wait!" I've seen. 
We'll run that historical data through a converter to get it to the new version.
Well that does seem to be fiddling with historical data and I thought that was
not on.

We may even introduce an error during this change and discover it later. 
Another little conversion process and we're back on track.  Now how exactly does
one prove that your data is now still correct.

The changes in structure over time are a given.  Handling it is notoriously
difficult (if you are doing it right, IMO).  Now some frown on snapshots when it
is mentioned yet they seem to mention them also.  The idea would be to keep the
original events but 'retire' them.  We do this with entities so why not with our
code (including events).  It will alsways be there but can no longer be
'replayed'.  Why?  Because it no logner exists in the domain.  A snapshot of the
AR at the time the new event came into being should be made, that should always
be read and the all events after the snapshots can be replayed to get it to the
current state.

But why all this hassle if you are loading a 'snapshot'.  It appears to me that
having all these events is just a way to get away from maybe historical audit
snapshots of the data that changed.  But one may need all of these, anyway.  The
events, or probably more importantly the commands, can be stored as a means of
determing what happened.  But it seems that some folks have now decided this I
the only way to go.  Events / Commands and no ORM / Data Mapping.  Yee-haa!  It
would be *really* simple to have snapshots of an Order (version 1, 2, 3, 4, 5)
and see the changes in the data along with all the relevant commands to see
*why* the data data changed --- all this in a reporting store (a la CQRS). 
However, how to get that data using events?  "Ah wait! We just replay the events
to the point we need them".  Uh, yeah --- in the domain.  Not very reporting
friendly.  Would be nice to have that data ll denormalized for us in a reporting
store already.

And *that* is why I reckon someone like Greg doesn't buy into different ARs for
different use case.  Why? 'coz how you gonna load something if you don't have a
fixed structure.

But, once again, I'm all for different techniques but don't appreciate when
someone comes across so abrasively.

Now I suspect I'll get some juvenile response like: "Uh, here's a link to the
definition of 'oh, oh, yeah!'" or maybe a name-drop like "We're discussing this
with Martin.  We're tight.  Yeah.  Real tight."  Maybe even a "Good luck to you
mate." or maybe a "Je parles Francais.  Je suis l'homme!  Il n'y a personne qui
est comme moi! Ouais!!!" *lol*

Anyway, keep well.

Regards,
Eben

--- In domaindrivendesign@yahoogroups.com, Nuno Lopes <nbplopes@...> wrote:
>
> Hi Greg and Mark,
>
> Thank you both for your patience and for answering some of my
> questions. I'm also patient ...
>
> To whoever cares about answering "how correct is your log?", or "prove
> your log is correct" I'll wrap up and give people some tips about
> doing this in your context. This post is long to wrap up my
> intervention in one post and the I'm off the theme.
>
> > Nuno,
> >
> > Re: log concerns use write once media to prevent editting of the
> > history. The log is additive only anyways.
>
> - Greg
>
> So we are getting to what actually may be useful to prove that an
> audit log is correct. Finely after so much nonsense and answers with
> little to no focus correctness but semantics.
>
> Irrespective of anything a "system is correct if it does what is told/
> expected to do". This is a simple definition for correctness that is
> recognized several disciplines and industries. So proving that an
> computer aided audit log is correct mounts to prove that logging
> system does what we tell it to do.
>
> " The idea is that any time something significant happens you write
> some record indicating what happened and when it happened."
>
> Marting Fowler.
>
> I like the way Martin describes it. So basically an Audit Log is a
> record of a series of events in a time line. A Logging System is one
> that records a series of events in a time line as it is told to! (or
> commanded, what ever).
>
> I specifically asked:
>
> > Correct against what?
>
>
> Without answering this it impossible to prove establish a platform of
> proof that we can work on. I think it is trivial to understand why but
> I guess it was too much to get an answer. But it would be very simple.
>
> Can think of at least two answer:
>
> A) We want to know that is correct it is correct against the logging
> system, For this matter then we need to prove that the logging system
> is correct.
> B) We want to know that is correct against state change occurrences in
> the domain model. For this matter then we need to prove that the
> series of events actually occurred as it is recorded.
>
> To prove B) we need to prove the A) first! There is no other way
> around it and I know what I'm talking about.
>
> So how can we prove A)? How do we prove that a system does what is
> suppose to do? In this case you need to prove that:
>
> 1) The logging system creates entries according to the defined
> structure capturing the timeline (when) and the structure that
> captures what happened. In this case a datetime propery and a
> structure that captures a state change (XML, a struct or whatever).
>
> 2) The logging system records the entry that is told to record. In
> other words if the system is to record X, it read X.
>
> 3) The logging system records entries in sequence in the time line.
> In other words, the next record has always the same date or a date
> after the current record.
>
> 4) No entries  can be changed or deleted after recorded. (data cannot
> be tempered with)
>
> So we need to prove that the system complies with 1) 2) 3) 4). In most
> domains a 01 proof is not required due to the cost of making a
> irrefutable proof ! We usually prove beyond reasonable doubt through a
> testing methodology of choice. In some circles a specific test
> methodology is required etc etc. But basically, well you can use Unit
> Testing if you will, or you can reuse technical components already in
> the market, including for instance a WRITE ONCE MEDIA to assure 4!!!!!
>
> To prove that your logging system works correctly you don't need much
> more then this really.  So show me your profs for  1), 2) 3). Until
> now I was only told about 4).
>
> You can use the above as a template to prove that your logging system
> is correct!!!!
>
> So now let's go to B)! This is were the fun starts. The proof of B)
> varies according to context. There is no general template for it.
>
> > Prove your audit log actually matches what the system thinks the
> > data is. If you can't do this an audit log is meaningless.
>
> - Greg
>
> Again another very strong phrase from Greg. There is not doubt about
> it, the way you express yourself is very convincing. But reality
> check, even if you don't go through the process of proving your audit
> log we all know it is not meaningless. It might not be sufficient in
> context though.
>
> > You seem to be confused...
>
>
> > And yes when building from events you can prove that your audit log
> > is correct, it has to be (your current state is built off the log
> > there is no opportunity for it to be out of sync).
>
> - Greg
>
> > I think you fail to see that when your AR can only change its
> > internal state by an event and you store those events that when you
> > reload the AR by replaying the events that then your audit log and
> > your AR persistence are one and the same. And thus your audit log is
> > correct, there is just no other way around that.
>
>
> - Mark
>
> Some notes about me being confused etc etc.
>
> Let me reiterate. If what the system "thinks" is given by the audit
> log as it is the case there no way, I mean no way that that we can
> prove that the series of events actually occurred towards the current
> state!!!!!!!!!!!!!!! In this situation the audit log could never lie
> since you accept by default that it is the truth!
>
> So you can't use the above as  proof!!!!!!!!!!!
>
> Mark honestly who told you could do that?
>
> So what can we do? You need another system to validate that the state
> change actually occurred as described (event), and the audit log in
> the proof was actually generated by the system where the events
> occurred.
>
> In DDD terms think of an Audit Log System as an Bounded Context  and
> Greg's Event Sourcing System (GESS) as another BC. So what is that
> third system?
>
> Let's accept that the log was generated by GESS for awhile (or
> commanded by a system using GESS). We will come back to this later.
>
> Since it is GESS that tells the Audit Log System what to log, you need
> to prove that it is being truthful about the state change and only
> then you may say that your audit log is correct in B) terms. In other
> words is not making a mistake by telling something that didn't
> actually occurred. But how can GESS make a mistake? Well GESS can't
> but the programmer that coded GESS can! But where? For instance here:
>
> > FireEvent(new Swapped(P1, P2));
>
> Again here you can use various strategies depending how irrefutable
> you want that prove to be. But the common way we do it is by Unit
> Testing. HERE IT IS YOUR THIRD SYSTEM.
>
> Now this is the CENTRAL ASPECT of the thing: Per Mark, unit tests are
> made considering Commands as the input and State Change Events as the
> output much like a function.
>
> So in the end of the day if A) is proven, the audit log is as correct
> as the unit tests prove to be if you use unit test to establish
> correctness.
>
> Break through? Not really. Indeed if you unit test your log entries
> you get the same result. The interesting bit is that Greg tests both
> the domain object (AR) and passing information to the audit log system
> in one Test Case. Some people might like it, some people may frown
> upon this concept. Someone may consider adding state change event
> mechanism to the ubiquitous language something to forbid, but it may
> be ok in some circles.
>
> So next time someone asks "How correct your log is?"  Just say "as far
> as my unit tests are correct" You can never miss.
>
> I almost forgot. We need to prove that the audit log is generated by
> the system in question. Well don't take my word for it, every single
> entry can be digitally signed by the system :)
>
> Another way would be simply have a system that produces these logs
> automatically as suggested. You would need to prove that this system
> is correct though.
>
> Cheers,
>
> Nuno
> PS: The business value of something is always defined by the business
> in context.
>
> Coupling the domain model with the persistence system mechanism and
> justifying it by making it part of the ubiquitous language is smart.
> Yet talking about a evasive persistence mechanism, event processing
> model and so on  ... We could just make this logging process
> transparent much like NHibernate makes persistence transparent and
> decouple the all thing out couldn't we? Someone would actually
> consider the former a bad architecture. But I guess, nowadays
> everything is possible as a case is a case.
>

Hi Vaughn,

It actually was someone else.  I also forget but that person used it to persist
*to* the repository.  I just thought about using it to read.  Something I
haven't actually done yet, although some people seem to have started building a
stake.

Whether it's misapplied I don't know.  When there is no ORM there is no ORM.

Anyway, as much as people try to ignore it I think an ORM *does* impose certain
design decisions on your domain.  I, for one, have been able to do things with
my custom mapping that I, for the life of me, could not get to look the same
when using NHibernate.  Maybe it's because I don't know it well enough but after
spending half a day trying to find the answer I just give up.

Regards,
Eben

--- In domaindrivendesign@yahoogroups.com, "vvernon_shiftmethod" <vvernon@...>
wrote:
>
> Udi,
>
> Ok, I misunderstood. I thought that just a week or two ago it was the case.
Perhaps it wasn't you but someone else who misapplied your blog.
>
> Vaughn
>
>
>
> --- In domaindrivendesign@yahoogroups.com, "Udi Dahan" <thesoftwaresimplist@>
wrote:
> >
> > > FWIW, Eben is adopting Udi's style of breaking persistence into a serious
> > of events to get around ORM
> >
> >
> >
> > Umm, I've never suggested that style.
> >
> >
> >
> > The only thing that I believe could reasonably be attributed to me is
> > raising events from the domain model,
> >
> > when those events aren't defined on the entity objects themselves:
> >
> >
> >
> > http://www.udidahan.com/2009/06/14/domain-events-salvation/
> >
> >
> >
> > The main goal of these events are to indicate state changes that the domain
> > has taken as a result of business rules to anything outside the domain
> > model.
> >
> >
> >
> > Using this "pattern" in order to get around an ORM was never my intent, nor
> > do I recommend it.
> >
> > In the case where one wishes to persist their domain model to a relational
> > DB, I recommend using an ORM.
> >
> >
> >
> > Hope that is clear.
> >
> >
> >
> > Thanks,
> >
> >
> >
> > -- Udi Dahan
> >
> >
> >
> > From: domaindrivendesign@yahoogroups.com
> > [mailto:domaindrivendesign@yahoogroups.com] On Behalf Of vvernon_shiftmethod
> > Sent: Sunday, November 01, 2009 4:46 PM
> > To: domaindrivendesign@yahoogroups.com
> > Subject: [domaindrivendesign] Re: Domain Events / Fetching Data / No ORM
> >
> >
> >
> >
> >
> > Greg,
> >
> > FWIW, Eben is adopting Udi's style of breaking persistence into a serious of
> > events to get around ORM. I don't really like this either, but it does allow
> > some to function outside the ORM or CQRS approaches. I would think that as
> > long as all this activity stays inside the model it could be acceptable. In
> > other words, it's implementation and domain experts don't need to know it
> > exits.
> >
> > Vaughn
> >
> > --- In domaindrivendesign@yahoogroups.com
> > <mailto:domaindrivendesign%40yahoogroups.com> , Greg Young
> > <gregoryyoung1@> wrote:
> > >
> > > Are you suggesting that this will be in your ubiquitous language and
> > > you will discuss lazy loading with domain experts? That doesn't sound
> > > very productive to me.
> > >
> > > Greg
> > >
> > > Sent from my iPhone
> > >
> > > On 2009-11-01, at 14:54, "eben_roux" <eben.roux@> wrote:
> > >
> > > > Hey Greg,
> > > >
> > > > Well, I don't really think it's infrastructure.
> > > >
> > > > The domain event handler will use a repository to fetch the data. I
> > > > am simply trying to get around the no ORM issue. People seem to use
> > > > lazy load quite a bit and this is simply another way to get the
> > > > required collection.
> > > >
> > > > There are a multitude of ways to do this. Some folks like the old
> > > > 'double-dispatch' by sending in the repository ;) --- still not
> > > > infrastructure.
> > > >
> > > > Cheers,
> > > > Eben
> > > >
> > > > --- In domaindrivendesign@yahoogroups.com
> > <mailto:domaindrivendesign%40yahoogroups.com> , Greg Young
> > > > <gregoryyoung1@> wrote:
> > > > >
> > > > > This sounds to me of infrastructure concerns leaking into your
> > > > domain.
> > > > >
> > > > > Greg
> > > > >
> > > > > On Saturday, October 31, 2009, eben_roux <eben.roux@> wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > Hello all,
> > > > > >
> > > > > > OK, so I don't use an ORM. It always bugged me that I wouldn't
> > > > always know what happened in the domain without an ORM. Luckily
> > > > Udi's clever domain events solved *that* problem.
> > > > > >
> > > > > > Another thing that has always bugged me is the deferred
> > > > loading / lazy loading thing. Now I don't like lazy loading.
> > > > However, I've been thinking that them domain events could be used to
> > > > do *that* then also.
> > > > > >
> > > > > > Something like a 'PaymentPlanRequired' event can be raised and
> > > > the 'Loan' and be passed along. The event handler could fetch the
> > > > payment plan and hand it to the Loan.
> > > > > >
> > > > > > Any thoughts? --- maybe this has been mentioned or discussed
> > > > elsewhere and I may simply not be aware of it.
> > > > > >
> > > > > > Regards,
> > > > > > Eben
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > > --
> > > > > Les erreurs de grammaire et de syntaxe ont été incluses pour m'ass
> > > > urer
> > > > > de votre attention
> > > > >
> > > >
> > > >
> > >
> >
>

Hi Eben,
Sounds like the bit you need from an ORM is the lazy loading, and the bit you
don't like from an ORM is the mapping stuff?

How about rolling your own lazy loading, not using events, but just using
proxies in the same way that an ORM does?  We do this in Naked Objects (when
running client/server we have to transparently walk the graph on the client side
where there is no ORM).  I've done it for the Java version using a couple of
bytecode libraries, and I also know my colleagues have implemented something
equivalent for the .NET version.

Here's a sketch of what's needed:
* introduce a generic factory (ours is called DomainObjectContainer) which
provides a newInstance<T>() method.  This is used to do the proxying.
* the proxy should, on the getter, delegate to a generic repository (again, this
is DomainObjectContainer for us), to call DomainObjectContainer.resolve(this,
propertyName)
* any collections you have also need to be resolve themselves automatically.  So
in newInstance() you should replace the original collections with proxies. 
These then work similarly, calling DomainObjectContainer.resolve(this,
collectionName) when first accessed.

Going back to ORM mappings, though, one thing I've thought about is using
"instead of triggers" on views.  This would allow one to create a set of views
that are optimized for an ORM (ie probably highly normalized), and then use the
triggers on the views to map to the underlying tables.  In effect, the views and
triggers are an anti-corruption layer.  Never done it, but think it's definitely
worth a spike.

HTH
Dan
consultant, trainer, author - developing enterprise applications
blog: http://danhaywood.com
books: "Domain Driven Design using Naked Objects",
http://pragprog.com/titles/dhnako


--- "eben_roux" <eben.roux@...> wrote:
>
> Hi Dan,
>
> Just don't like them --- well, only *really* looked at NHibernate and read-up
on the EF and used Linq to Sql.  And they are slower (OK, not much).
>
> It just seems like *soooo* much effort to do the simplest things when your own
mapping or a couple of lines of code can do the same thing.
>
> But deep down I feel that somewhere there is an opportunity for a very simple
ORM that focuses on the C side of CQRS.  NHibernate seems like it's grown into a
bit of a monster.  We need something fresh and light weight.
>
> Eben
>
>
>
> --- In domaindrivendesign@yahoogroups.com, "danhaywood@" <danhaywood@> wrote:
> >
> > --- "eben_roux" <eben.roux@> wrote:
> > >
> > > OK, so I don't use an ORM.
> >
> > Just interested to know, what the reason is that you don't, since it sounds
like you're hitting use cases where some of an ORM's features would be helpful? 
Maybe you've stated why in a previous post?
> >
> > Dan
> >
>

Hi Eben

Try a prefetch strategy. Something like:

Order aOrder = Orders.GetOrderToBill(orderId);
aOrder.MakeBill();

Greg,

Your approach to persistence is smart I grant you that. The fact is
that in the domain when action is performed it expects a product (as
of result) or a notification of irregular circumstances that block the
execution (error). It does not expect be notified by an event -
"action-performed and here is the state change with a few extra info
we thought it might be necessary". You may make anything part of the
ubiquitous language given the right project, the right people and the
necessary motivation.

All I'm saying is that something being part of the ubiquitous language
and so the model does not make it a good design. It has to be
necessary in context otherwise is YAGNI.

Moderation is something necessary to make a good design.

This is my opinion.

Cheers,

Nuno

Hi Dan,

Thanks for the input.

If you go back to around Feb/Mar 2008 I mentioned using proxies for lazy-loading
and got somewhat of a roasting.  But the idea is OK I guess.  Haven't tried the
domain event plan but, as I have said before, I am no fan of lazy-loading.

As for the mapping: should be OK to use views.  one could go with some
automapping plan using conventions.  Only thing is that one may be moving the
hassle to view maintenance.

Don't know.

Regards,
Eben


--- In domaindrivendesign@yahoogroups.com, "danhaywood@..." <danhaywood@...>
wrote:
>
> Hi Eben,
> Sounds like the bit you need from an ORM is the lazy loading, and the bit you
don't like from an ORM is the mapping stuff?
>
> How about rolling your own lazy loading, not using events, but just using
proxies in the same way that an ORM does?  We do this in Naked Objects (when
running client/server we have to transparently walk the graph on the client side
where there is no ORM).  I've done it for the Java version using a couple of
bytecode libraries, and I also know my colleagues have implemented something
equivalent for the .NET version.
>
> Here's a sketch of what's needed:
> * introduce a generic factory (ours is called DomainObjectContainer) which
provides a newInstance<T>() method.  This is used to do the proxying.
> * the proxy should, on the getter, delegate to a generic repository (again,
this is DomainObjectContainer for us), to call
DomainObjectContainer.resolve(this, propertyName)
> * any collections you have also need to be resolve themselves automatically. 
So in newInstance() you should replace the original collections with proxies. 
These then work similarly, calling DomainObjectContainer.resolve(this,
collectionName) when first accessed.
>
> Going back to ORM mappings, though, one thing I've thought about is using
"instead of triggers" on views.  This would allow one to create a set of views
that are optimized for an ORM (ie probably highly normalized), and then use the
triggers on the views to map to the underlying tables.  In effect, the views and
triggers are an anti-corruption layer.  Never done it, but think it's definitely
worth a spike.
>
> HTH
> Dan
> consultant, trainer, author - developing enterprise applications
> blog: http://danhaywood.com
> books: "Domain Driven Design using Naked Objects",
http://pragprog.com/titles/dhnako
>
>
> --- "eben_roux" <eben.roux@> wrote:
> >
> > Hi Dan,
> >
> > Just don't like them --- well, only *really* looked at NHibernate and
read-up on the EF and used Linq to Sql.  And they are slower (OK, not much).
> >
> > It just seems like *soooo* much effort to do the simplest things when your
own mapping or a couple of lines of code can do the same thing.
> >
> > But deep down I feel that somewhere there is an opportunity for a very
simple ORM that focuses on the C side of CQRS.  NHibernate seems like it's grown
into a bit of a monster.  We need something fresh and light weight.
> >
> > Eben
> >
> >
> >
> > --- In domaindrivendesign@yahoogroups.com, "danhaywood@" <danhaywood@>
wrote:
> > >
> > > --- "eben_roux" <eben.roux@> wrote:
> > > >
> > > > OK, so I don't use an ORM.
> > >
> > > Just interested to know, what the reason is that you don't, since it
sounds like you're hitting use cases where some of an ORM's features would be
helpful?  Maybe you've stated why in a previous post?
> > >
> > > Dan
> > >
> >
>

Hey Nuno,

That is typically what I would do :)

What I have been experimenting with is having my UnitOfWork keep a list of
entity types required in the use case.  Then the mappers check to see whether
they need to load related data from the relevant repository.  e.g.:

SomeHandler.Handle(BillOrderCommand command)
{
    using (var uow = uowFactory.Create())
    {
       uow.WillUser<OrderLine>();

       var order = orderRepository.Get(command.OrderId);

       order.MakeBill();
    }
}

then in the OrderMapper:

public Order MapFrom(DataRow row)
{
    var result = new Order(Columns.OrderId.MapFrom(row), etc...);

    if (UnitOfWork.Uses<OrderLine>())
    {
       // make a plan and load them order lines
    }

    return result;
}

Regards,
Eben


--- In domaindrivendesign@yahoogroups.com, Nuno Lopes <nbplopes@...> wrote:
>
> Hi Eben
>
> Try a prefetch strategy. Something like:
>
> Order aOrder = Orders.GetOrderToBill(orderId);
> aOrder.MakeBill();
>
> Greg,
>
> Your approach to persistence is smart I grant you that. The fact is
> that in the domain when action is performed it expects a product (as
> of result) or a notification of irregular circumstances that block the
> execution (error). It does not expect be notified by an event -
> "action-performed and here is the state change with a few extra info
> we thought it might be necessary". You may make anything part of the
> ubiquitous language given the right project, the right people and the
> necessary motivation.
>
> All I'm saying is that something being part of the ubiquitous language
> and so the model does not make it a good design. It has to be
> necessary in context otherwise is YAGNI.
>
> Moderation is something necessary to make a good design.
>
> This is my opinion.
>
> Cheers,
>
> Nuno
>

--- "eben_roux" <eben.roux@...> wrote:
>
>
> As for the mapping: should be OK to use views.  one could go with some
automapping plan using conventions.  Only thing is that one may be moving the
hassle to view maintenance.
>

But at least the DBAs would have full visibility and could help ensure backwards
compatibility if the underlying database tables change for some other reason. 
Could also use RDBMS tools to do the impact analysis (if a table needs to
change, then what are the views/triggers that need modifying).

Cheers

Dan

Hey Mark,

>>>
if you want to split the behaviour into different implementations of your AR
(this seems very weird to me, but this is what I understand for your short snap)
<<<

Not what I want to do.

Say for an AddOrderCommand the Customer is the AR.  Now say in an
ApplyDiscountCommand use case the Order is the AR.

How would I reconstiture my Customer AR?
How would I reconstitute my Order AR?

Cheers,
Eben

--- In domaindrivendesign@yahoogroups.com, Mark Nijhof <Mark.Nijhof@...> wrote:
>
> Not sure how much positive input you are bringing?
>
> If you have different AR's for different contexts then they should be
> persisted individually from each other,  then you could still bring
> both into the correct state using the same event system, just replay the
> events in the other implementation. Then to simplify you would probably want
> to use inheritance to avoid code duplication of this state code.
>
> -Mark
>
>
>
> On Mon, Nov 2, 2009 at 7:22 AM, eben_roux <eben.roux@...> wrote:
>
> >
> >
> > Hey Nuno,
> >
> > You know what? I have been following this group for some time and it is
> > interesting how some folks react to different ideas. Now I am a native
> > English speaker although English is my second language (hence, some errors
> > may creep in). You talk a lot of sense. Now I have found the way Greg, for
> > one, answers some questions quite laughable. I, for one, am on a crusade to
> > try to improve my software and welcome new ideas and I try to implement the
> > stuff so I can get a feel for it.
> >
> > But it is frustrating when one is shot down for no apparent reason. It is
> > fine to say "Here is my opinion" but when someone says "Here is my opinion.
> > Your's sucks. Here's a dictionary definition, blah, blah" then I tend to
> > move to a state of ignoring them and *that* is a pity when between all the
> > bullshit (not talking about you here though) there is actually some smarts.
> >
> > As Vaughn stated in one of his posts, most folks on this site actually know
> > what they're doing. Now some have been coding for longer than others and
> > have, therefore, made more mistakes, learnt more, or were taught crap like
> > 'Structured Programming' --- something I did at Technikon for 3 years. My
> > COBOL was pretty hot :)
> >
> > Hey I even wrote my first game on a VIC20 in 1985!
> >
> > Getting back to this stuff. I am all for logging. These events seem to me
> > to fall into that category. However, one could rebuild you AR with some
> > cleverness from these but I *really* think that *that* has an effect on your
> > design. The same kind of thing happens when persistence concerns are pulled
> > into the domain. Yet everyone pops a brain vessel when *that* happens. Geez,
> > now even using a repository in a domain event seems to be infrastructure.
> >
> > Right, so now we write Greg's write once event stream. Now the event
> > structure changes because we have a new requirement. So *actually* it cannot
> > change because how are we going to replay that original event. "Ah wait!"
> > I've seen. We'll run that historical data through a converter to get it to
> > the new version. Well that does seem to be fiddling with historical data and
> > I thought that was not on.
> >
> > We may even introduce an error during this change and discover it later.
> > Another little conversion process and we're back on track. Now how exactly
> > does one prove that your data is now still correct.
> >
> > The changes in structure over time are a given. Handling it is notoriously
> > difficult (if you are doing it right, IMO). Now some frown on snapshots when
> > it is mentioned yet they seem to mention them also. The idea would be to
> > keep the original events but 'retire' them. We do this with entities so why
> > not with our code (including events). It will alsways be there but can no
> > longer be 'replayed'. Why? Because it no logner exists in the domain. A
> > snapshot of the AR at the time the new event came into being should be made,
> > that should always be read and the all events after the snapshots can be
> > replayed to get it to the current state.
> >
> > But why all this hassle if you are loading a 'snapshot'. It appears to me
> > that having all these events is just a way to get away from maybe historical
> > audit snapshots of the data that changed. But one may need all of these,
> > anyway. The events, or probably more importantly the commands, can be stored
> > as a means of determing what happened. But it seems that some folks have now
> > decided this I the only way to go. Events / Commands and no ORM / Data
> > Mapping. Yee-haa! It would be *really* simple to have snapshots of an Order
> > (version 1, 2, 3, 4, 5) and see the changes in the data along with all the
> > relevant commands to see *why* the data data changed --- all this in a
> > reporting store (a la CQRS). However, how to get that data using events? "Ah
> > wait! We just replay the events to the point we need them". Uh, yeah --- in
> > the domain. Not very reporting friendly. Would be nice to have that data ll
> > denormalized for us in a reporting store already.
> >
> > And *that* is why I reckon someone like Greg doesn't buy into different ARs
> > for different use case. Why? 'coz how you gonna load something if you don't
> > have a fixed structure.
> >
> > But, once again, I'm all for different techniques but don't appreciate when
> > someone comes across so abrasively.
> >
> > Now I suspect I'll get some juvenile response like: "Uh, here's a link to
> > the definition of 'oh, oh, yeah!'" or maybe a name-drop like "We're
> > discussing this with Martin. We're tight. Yeah. Real tight." Maybe even a
> > "Good luck to you mate." or maybe a "Je parles Francais. Je suis l'homme! Il
> > n'y a personne qui est comme moi! Ouais!!!" *lol*
> >
> > Anyway, keep well.
> >
> > Regards,
> > Eben
> >
> >
> > --- In
domaindrivendesign@yahoogroups.com<domaindrivendesign%40yahoogroups.com>,
> > Nuno Lopes <nbplopes@> wrote:
> > >
> > > Hi Greg and Mark,
> > >
> > > Thank you both for your patience and for answering some of my
> > > questions. I'm also patient ...
> > >
> > > To whoever cares about answering "how correct is your log?", or "prove
> > > your log is correct" I'll wrap up and give people some tips about
> > > doing this in your context. This post is long to wrap up my
> > > intervention in one post and the I'm off the theme.
> > >
> > > > Nuno,
> > > >
> > > > Re: log concerns use write once media to prevent editting of the
> > > > history. The log is additive only anyways.
> > >
> > > - Greg
> > >
> > > So we are getting to what actually may be useful to prove that an
> > > audit log is correct. Finely after so much nonsense and answers with
> > > little to no focus correctness but semantics.
> > >
> > > Irrespective of anything a "system is correct if it does what is told/
> > > expected to do". This is a simple definition for correctness that is
> > > recognized several disciplines and industries. So proving that an
> > > computer aided audit log is correct mounts to prove that logging
> > > system does what we tell it to do.
> > >
> > > " The idea is that any time something significant happens you write
> > > some record indicating what happened and when it happened."
> > >
> > > Marting Fowler.
> > >
> > > I like the way Martin describes it. So basically an Audit Log is a
> > > record of a series of events in a time line. A Logging System is one
> > > that records a series of events in a time line as it is told to! (or
> > > commanded, what ever).
> > >
> > > I specifically asked:
> > >
> > > > Correct against what?
> > >
> > >
> > > Without answering this it impossible to prove establish a platform of
> > > proof that we can work on. I think it is trivial to understand why but
> > > I guess it was too much to get an answer. But it would be very simple.
> > >
> > > Can think of at least two answer:
> > >
> > > A) We want to know that is correct it is correct against the logging
> > > system, For this matter then we need to prove that the logging system
> > > is correct.
> > > B) We want to know that is correct against state change occurrences in
> > > the domain model. For this matter then we need to prove that the
> > > series of events actually occurred as it is recorded.
> > >
> > > To prove B) we need to prove the A) first! There is no other way
> > > around it and I know what I'm talking about.
> > >
> > > So how can we prove A)? How do we prove that a system does what is
> > > suppose to do? In this case you need to prove that:
> > >
> > > 1) The logging system creates entries according to the defined
> > > structure capturing the timeline (when) and the structure that
> > > captures what happened. In this case a datetime propery and a
> > > structure that captures a state change (XML, a struct or whatever).
> > >
> > > 2) The logging system records the entry that is told to record. In
> > > other words if the system is to record X, it read X.
> > >
> > > 3) The logging system records entries in sequence in the time line.
> > > In other words, the next record has always the same date or a date
> > > after the current record.
> > >
> > > 4) No entries can be changed or deleted after recorded. (data cannot
> > > be tempered with)
> > >
> > > So we need to prove that the system complies with 1) 2) 3) 4). In most
> > > domains a 01 proof is not required due to the cost of making a
> > > irrefutable proof ! We usually prove beyond reasonable doubt through a
> > > testing methodology of choice. In some circles a specific test
> > > methodology is required etc etc. But basically, well you can use Unit
> > > Testing if you will, or you can reuse technical components already in
> > > the market, including for instance a WRITE ONCE MEDIA to assure 4!!!!!
> > >
> > > To prove that your logging system works correctly you don't need much
> > > more then this really. So show me your profs for 1), 2) 3). Until
> > > now I was only told about 4).
> > >
> > > You can use the above as a template to prove that your logging system
> > > is correct!!!!
> > >
> > > So now let's go to B)! This is were the fun starts. The proof of B)
> > > varies according to context. There is no general template for it.
> > >
> > > > Prove your audit log actually matches what the system thinks the
> > > > data is. If you can't do this an audit log is meaningless.
> > >
> > > - Greg
> > >
> > > Again another very strong phrase from Greg. There is not doubt about
> > > it, the way you express yourself is very convincing. But reality
> > > check, even if you don't go through the process of proving your audit
> > > log we all know it is not meaningless. It might not be sufficient in
> > > context though.
> > >
> > > > You seem to be confused...
> > >
> > >
> > > > And yes when building from events you can prove that your audit log
> > > > is correct, it has to be (your current state is built off the log
> > > > there is no opportunity for it to be out of sync).
> > >
> > > - Greg
> > >
> > > > I think you fail to see that when your AR can only change its
> > > > internal state by an event and you store those events that when you
> > > > reload the AR by replaying the events that then your audit log and
> > > > your AR persistence are one and the same. And thus your audit log is
> > > > correct, there is just no other way around that.
> > >
> > >
> > > - Mark
> > >
> > > Some notes about me being confused etc etc.
> > >
> > > Let me reiterate. If what the system "thinks" is given by the audit
> > > log as it is the case there no way, I mean no way that that we can
> > > prove that the series of events actually occurred towards the current
> > > state!!!!!!!!!!!!!!! In this situation the audit log could never lie
> > > since you accept by default that it is the truth!
> > >
> > > So you can't use the above as proof!!!!!!!!!!!
> > >
> > > Mark honestly who told you could do that?
> > >
> > > So what can we do? You need another system to validate that the state
> > > change actually occurred as described (event), and the audit log in
> > > the proof was actually generated by the system where the events
> > > occurred.
> > >
> > > In DDD terms think of an Audit Log System as an Bounded Context and
> > > Greg's Event Sourcing System (GESS) as another BC. So what is that
> > > third system?
> > >
> > > Let's accept that the log was generated by GESS for awhile (or
> > > commanded by a system using GESS). We will come back to this later.
> > >
> > > Since it is GESS that tells the Audit Log System what to log, you need
> > > to prove that it is being truthful about the state change and only
> > > then you may say that your audit log is correct in B) terms. In other
> > > words is not making a mistake by telling something that didn't
> > > actually occurred. But how can GESS make a mistake? Well GESS can't
> > > but the programmer that coded GESS can! But where? For instance here:
> > >
> > > > FireEvent(new Swapped(P1, P2));
> > >
> > > Again here you can use various strategies depending how irrefutable
> > > you want that prove to be. But the common way we do it is by Unit
> > > Testing. HERE IT IS YOUR THIRD SYSTEM.
> > >
> > > Now this is the CENTRAL ASPECT of the thing: Per Mark, unit tests are
> > > made considering Commands as the input and State Change Events as the
> > > output much like a function.
> > >
> > > So in the end of the day if A) is proven, the audit log is as correct
> > > as the unit tests prove to be if you use unit test to establish
> > > correctness.
> > >
> > > Break through? Not really. Indeed if you unit test your log entries
> > > you get the same result. The interesting bit is that Greg tests both
> > > the domain object (AR) and passing information to the audit log system
> > > in one Test Case. Some people might like it, some people may frown
> > > upon this concept. Someone may consider adding state change event
> > > mechanism to the ubiquitous language something to forbid, but it may
> > > be ok in some circles.
> > >
> > > So next time someone asks "How correct your log is?" Just say "as far
> > > as my unit tests are correct" You can never miss.
> > >
> > > I almost forgot. We need to prove that the audit log is generated by
> > > the system in question. Well don't take my word for it, every single
> > > entry can be digitally signed by the system :)
> > >
> > > Another way would be simply have a system that produces these logs
> > > automatically as suggested. You would need to prove that this system
> > > is correct though.
> > >
> > > Cheers,
> > >
> > > Nuno
> > > PS: The business value of something is always defined by the business
> > > in context.
> > >
> > > Coupling the domain model with the persistence system mechanism and
> > > justifying it by making it part of the ubiquitous language is smart.
> > > Yet talking about a evasive persistence mechanism, event processing
> > > model and so on ... We could just make this logging process
> > > transparent much like NHibernate makes persistence transparent and
> > > decouple the all thing out couldn't we? Someone would actually
> > > consider the former a bad architecture. But I guess, nowadays
> > > everything is possible as a case is a case.
> > >
> >
> >
> >
>

I've totally bought into the advantages of separating your command and
read queries to enable you to scale out reads (amongst other things).

However, I'm still weighing up options on the command side of things.
As we're always loading the aggregate root it doesn't feel like we
*need* a relational database.

The options as I see it are

1. Usual ORM (nHibernate) for persistance... still feeling a fair
amount of friction here, but it works.
2. Store domain events (aka Greg Young)... I like the fact you can
dump the ORM entirely, but not sure I can see all the possible
implications in the architecture further down the line yet.
3. Object database (db4o etc)

The one I know least about is #3 - what are people's experiences with
this? Are there other options I'm missing?

Thanks

James

Hey Mark,

Thanks for that. Now:

-> Loads the correct Customer using the AR Id from the command.
-> Loads the correct Order using the AR Id from the command.

So are you loading a record here? Ah, looked at your example code (nice work by
the way) --- so you serialize the snapshot.

You would then deserialize the snapshot and apply the events to get the latest
state.  OK.  Is that correct?

Eben


--- In domaindrivendesign@yahoogroups.com, Mark Nijhof <Mark.Nijhof@...> wrote:
>
> Ahh ok, well you would of course have the different AR types, not everything
> is in one type.
>
> Well these two command have their own command handler which knows which AR
> to load, normally a command handler only deals with one AR, but I could see
> multiple command handlers acting on one command if that is needed.
>
> AddOrderCommand
> -> AddOrderCommandHandler
> -> Loads the correct Customer using the AR Id from the command.
> -> Then the handler executes Customer.AddOrder(basic parameters) returns
> Order
> -> Save the Customer
> -> Save the new Order
>
> ApplyDiscountCommand
> -> ApplyDiscountCommandHandler
> -> Loads the correct Order using the AR Id from the command.
> -> Order.ApplyDiscount()
> -> Save the Order
>
> The repository gets the type you need and the AR Id to load the AR from the
> events. Take a look at my example as how I have implemented this. I
> understand you can also push the commands into the AR to have them execute
> in there, but then you would still need an Handler to actually load the
> correct AR. But this approach I am going to look at as well.
>
> -Mark
>
>
>

 

Hey Nuno,

You know what? I have been following this group for some time and it is interesting how some folks react to different ideas. Now I am a native English speaker although English is my second language (hence, some errors may creep in). You talk a lot of sense. Now I have found the way Greg, for one, answers some questions quite laughable. I, for one, am on a crusade to try to improve my software and welcome new ideas and I try to implement the stuff so I can get a feel for it.

But it is frustrating when one is shot down for no apparent reason. It is fine to say "Here is my opinion" but when someone says "Here is my opinion. Your's sucks. Here's a dictionary definition, blah, blah" then I tend to move to a state of ignoring them and *that* is a pity when between all the bullshit (not talking about you here though) there is actually some smarts.

As Vaughn stated in one of his posts, most folks on this site actually know what they're doing. Now some have been coding for longer than others and have, therefore, made more mistakes, learnt more, or were taught crap like 'Structured Programming' --- something I did at Technikon for 3 years. My COBOL was pretty hot :)

Hey I even wrote my first game on a VIC20 in 1985!

Getting back to this stuff. I am all for logging. These events seem to me to fall into that category. However, one could rebuild you AR with some cleverness from these but I *really* think that *that* has an effect on your design. The same kind of thing happens when persistence concerns are pulled into the domain. Yet everyone pops a brain vessel when *that* happens. Geez, now even using a repository in a domain event seems to be infrastructure.

Right, so now we write Greg's write once event stream. Now the event structure changes because we have a new requirement. So *actually* it cannot change because how are we going to replay that original event. "Ah wait!" I've seen. We'll run that historical data through a converter to get it to the new version. Well that does seem to be fiddling with historical data and I thought that was not on.

We may even introduce an error during this change and discover it later. Another little conversion process and we're back on track. Now how exactly does one prove that your data is now still correct.

The changes in structure over time are a given. Handling it is notoriously difficult (if you are doing it right, IMO). Now some frown on snapshots when it is mentioned yet they seem to mention them also. The idea would be to keep the original events but 'retire' them. We do this with entities so why not with our code (including events). It will alsways be there but can no longer be 'replayed'. Why? Because it no logner exists in the domain. A snapshot of the AR at the time the new event came into being should be made, that should always be read and the all events after the snapshots can be replayed to get it to the current state.

But why all this hassle if you are loading a 'snapshot'. It appears to me that having all these events is just a way to get away from maybe historical audit snapshots of the data that changed. But one may need all of these, anyway. The events, or probably more importantly the commands, can be stored as a means of determing what happened. But it seems that some folks have now decided this I the only way to go. Events / Commands and no ORM / Data Mapping. Yee-haa! It would be *really* simple to have snapshots of an Order (version 1, 2, 3, 4, 5) and see the changes in the data along with all the relevant commands to see *why* the data data changed --- all this in a reporting store (a la CQRS). However, how to get that data using events? "Ah wait! We just replay the events to the point we need them". Uh, yeah --- in the domain. Not very reporting friendly. Would be nice to have that data ll denormalized for us in a reporting store already.

And *that* is why I reckon someone like Greg doesn't buy into different ARs for different use case. Why? 'coz how you gonna load something if you don't have a fixed structure.

But, once again, I'm all for different techniques but don't appreciate when someone comes across so abrasively.

Now I suspect I'll get some juvenile response like: "Uh, here's a link to the definition of 'oh, oh, yeah!'" or maybe a name-drop like "We're discussing this with Martin. We're tight. Yeah. Real tight." Maybe even a "Good luck to you mate." or maybe a "Je parles Francais. Je suis l'homme! Il n'y a personne qui est comme moi! Ouais!!!" *lol*

Anyway, keep well.

Regards,
Eben

--- In domaindrivendesign@yahoogroups.com, Nuno Lopes <nbplopes@...> wrote:
>
> Hi Greg and Mark,
>
> Thank you both for your patience and for answering some of my
> questions. I'm also patient ...
>
> To whoever cares about answering "how correct is your log?", or "prove
> your log is correct" I'll wrap up and give people some tips about
> doing this in your context. This post is long to wrap up my
> intervention in one post and the I'm off the theme.
>
> > Nuno,
> >
> > Re: log concerns use write once media to prevent editting of the
> > history. The log is additive only anyways.
>
> - Greg
>
> So we are getting to what actually may be useful to prove that an
> audit log is correct. Finely after so much nonsense and answers with
> little to no focus correctness but semantics.
>
> Irrespective of anything a "system is correct if it does what is told/
> expected to do". This is a simple definition for correctness that is
> recognized several disciplines and industries. So proving that an
> computer aided audit log is correct mounts to prove that logging
> system does what we tell it to do.
>
> " The idea is that any time something significant happens you write
> some record indicating what happened and when it happened."
>
> Marting Fowler.
>
> I like the way Martin describes it. So basically an Audit Log is a
> record of a series of events in a time line. A Logging System is one
> that records a series of events in a time line as it is told to! (or
> commanded, what ever).
>
> I specifically asked:
>
> > Correct against what?
>
>
> Without answering this it impossible to prove establish a platform of
> proof that we can work on. I think it is trivial to understand why but
> I guess it was too much to get an answer. But it would be very simple.
>
> Can think of at least two answer:
>
> A) We want to know that is correct it is correct against the logging
> system, For this matter then we need to prove that the logging system
> is correct.
> B) We want to know that is correct against state change occurrences in
> the domain model. For this matter then we need to prove that the
> series of events actually occurred as it is recorded.
>
> To prove B) we need to prove the A) first! There is no other way
> around it and I know what I'm talking about.
>
> So how can we prove A)? How do we prove that a system does what is
> suppose to do? In this case you need to prove that:
>
> 1) The logging system creates entries according to the defined
> structure capturing the timeline (when) and the structure that
> captures what happened. In this case a datetime propery and a
> structure that captures a state change (XML, a struct or whatever).
>
> 2) The logging system records the entry that is told to record. In
> other words if the system is to record X, it read X.
>
> 3) The logging system records entries in sequence in the time line.
> In other words, the next record has always the same date or a date
> after the current record.
>
> 4) No entries can be changed or deleted after recorded. (data cannot
> be tempered with)
>
> So we need to prove that the system complies with 1) 2) 3) 4). In most
> domains a 01 proof is not required due to the cost of making a
> irrefutable proof ! We usually prove beyond reasonable doubt through a
> testing methodology of choice. In some circles a specific test
> methodology is required etc etc. But basically, well you can use Unit
> Testing if you will, or you can reuse technical components already in
> the market, including for instance a WRITE ONCE MEDIA to assure 4!!!!!
>
> To prove that your logging system works correctly you don't need much
> more then this really. So show me your profs for 1), 2) 3). Until
> now I was only told about 4).
>
> You can use the above as a template to prove that your logging system
> is correct!!!!
>
> So now let's go to B)! This is were the fun starts. The proof of B)
> varies according to context. There is no general template for it.
>
> > Prove your audit log actually matches what the system thinks the
> > data is. If you can't do this an audit log is meaningless.
>
> - Greg
>
> Again another very strong phrase from Greg. There is not doubt about
> it, the way you express yourself is very convincing. But reality
> check, even if you don't go through the process of proving your audit
> log we all know it is not meaningless. It might not be sufficient in
> context though.
>
> > You seem to be confused...
>
>
> > And yes when building from events you can prove that your audit log
> > is correct, it has to be (your current state is built off the log
> > there is no opportunity for it to be out of sync).
>
> - Greg
>
> > I think you fail to see that when your AR can only change its
> > internal state by an event and you store those events that when you
> > reload the AR by replaying the events that then your audit log and
> > your AR persistence are one and the same. And thus your audit log is
> > correct, there is just no other way around that.
>
>
> - Mark
>
> Some notes about me being confused etc etc.
>
> Let me reiterate. If what the system "thinks" is given by the audit
> log as it is the case there no way, I mean no way that that we can
> prove that the series of events actually occurred towards the current
> state!!!!!!!!!!!!!!! In this situation the audit log could never lie
> since you accept by default that it is the truth!
>
> So you can't use the above as proof!!!!!!!!!!!
>
> Mark honestly who told you could do that?
>
> So what can we do? You need another system to validate that the state
> change actually occurred as described (event), and the audit log in
> the proof was actually generated by the system where the events
> occurred.
>
> In DDD terms think of an Audit Log System as an Bounded Context and
> Greg's Event Sourcing System (GESS) as another BC. So what is that
> third system?
>
> Let's accept that the log was generated by GESS for awhile (or
> commanded by a system using GESS). We will come back to this later.
>
> Since it is GESS that tells the Audit Log System what to log, you need
> to prove that it is being truthful about the state change and only
> then you may say that your audit log is correct in B) terms. In other
> words is not making a mistake by telling something that didn't
> actually occurred. But how can GESS make a mistake? Well GESS can't
> but the programmer that coded GESS can! But where? For instance here:
>
> > FireEvent(new Swapped(P1, P2));
>
> Again here you can use various strategies depending how irrefutable
> you want that prove to be. But the common way we do it is by Unit
> Testing. HERE IT IS YOUR THIRD SYSTEM.
>
> Now this is the CENTRAL ASPECT of the thing: Per Mark, unit tests are
> made considering Commands as the input and State Change Events as the
> output much like a function.
>
> So in the end of the day if A) is proven, the audit log is as correct
> as the unit tests prove to be if you use unit test to establish
> correctness.
>
> Break through? Not really. Indeed if you unit test your log entries
> you get the same result. The interesting bit is that Greg tests both
> the domain object (AR) and passing information to the audit log system
> in one Test Case. Some people might like it, some people may frown
> upon this concept. Someone may consider adding state change event
> mechanism to the ubiquitous language something to forbid, but it may
> be ok in some circles.
>
> So next time someone asks "How correct your log is?" Just say "as far
> as my unit tests are correct" You can never miss.
>
> I almost forgot. We need to prove that the audit log is generated by
> the system in question. Well don't take my word for it, every single
> entry can be digitally signed by the system :)
>
> Another way would be simply have a system that produces these logs
> automatically as suggested. You would need to prove that this system
> is correct though.
>
> Cheers,
>
> Nuno
> PS: The business value of something is always defined by the business
> in context.
>
> Coupling the domain model with the persistence system mechanism and
> justifying it by making it part of the ubiquitous language is smart.
> Yet talking about a evasive persistence mechanism, event processing
> model and so on ... We could just make this logging process
> transparent much like NHibernate makes persistence transparent and
> decouple the all thing out couldn't we? Someone would actually
> consider the former a bad architecture. But I guess, nowadays
> everything is possible as a case is a case.
>

 

Hey Nuno,

You know what? I have been following this group for some time and it is interesting how some folks react to different ideas. Now I am a native English speaker although English is my second language (hence, some errors may creep in). You talk a lot of sense. Now I have found the way Greg, for one, answers some questions quite laughable. I, for one, am on a crusade to try to improve my software and welcome new ideas and I try to implement the stuff so I can get a feel for it.

But it is frustrating when one is shot down for no apparent reason. It is fine to say "Here is my opinion" but when someone says "Here is my opinion. Your's sucks. Here's a dictionary definition, blah, blah" then I tend to move to a state of ignoring them and *that* is a pity when between all the bullshit (not talking about you here though) there is actually some smarts.

As Vaughn stated in one of his posts, most folks on this site actually know what they're doing. Now some have been coding for longer than others and have, therefore, made more mistakes, learnt more, or were taught crap like 'Structured Programming' --- something I did at Technikon for 3 years. My COBOL was pretty hot :)

Hey I even wrote my first game on a VIC20 in 1985!

Getting back to this stuff. I am all for logging. These events seem to me to fall into that category. However, one could rebuild you AR with some cleverness from these but I *really* think that *that* has an effect on your design. The same kind of thing happens when persistence concerns are pulled into the domain. Yet everyone pops a brain vessel when *that* happens. Geez, now even using a repository in a domain event seems to be infrastructure.

Right, so now we write Greg's write once event stream. Now the event structure changes because we have a new requirement. So *actually* it cannot change because how are we going to replay that original event. "Ah wait!" I've seen. We'll run that historical data through a converter to get it to the new version. Well that does seem to be fiddling with historical data and I thought that was not on.

We may even introduce an error during this change and discover it later. Another little conversion process and we're back on track. Now how exactly does one prove that your data is now still correct.

The changes in structure over time are a given. Handling it is notoriously difficult (if you are doing it right, IMO). Now some frown on snapshots when it is mentioned yet they seem to mention them also. The idea would be to keep the original events but 'retire' them. We do this with entities so why not with our code (including events). It will alsways be there but can no longer be 'replayed'. Why? Because it no logner exists in the domain. A snapshot of the AR at the time the new event came into being should be made, that should always be read and the all events after the snapshots can be replayed to get it to the current state.

But why all this hassle if you are loading a 'snapshot'. It appears to me that having all these events is just a way to get away from maybe historical audit snapshots of the data that changed. But one may need all of these, anyway. The events, or probably more importantly the commands, can be stored as a means of determing what happened. But it seems that some folks have now decided this I the only way to go. Events / Commands and no ORM / Data Mapping. Yee-haa! It would be *really* simple to have snapshots of an Order (version 1, 2, 3, 4, 5) and see the changes in the data along with all the relevant commands to see *why* the data data changed --- all this in a reporting store (a la CQRS). However, how to get that data using events? "Ah wait! We just replay the events to the point we need them". Uh, yeah --- in the domain. Not very reporting friendly. Would be nice to have that data ll denormalized for us in a reporting store already.

And *that* is why I reckon someone like Greg doesn't buy into different ARs for different use case. Why? 'coz how you gonna load something if you don't have a fixed structure.

But, once again, I'm all for different techniques but don't appreciate when someone comes across so abrasively.

Now I suspect I'll get some juvenile response like: "Uh, here's a link to the definition of 'oh, oh, yeah!'" or maybe a name-drop like "We're discussing this with Martin. We're tight. Yeah. Real tight." Maybe even a "Good luck to you mate." or maybe a "Je parles Francais. Je suis l'homme! Il n'y a personne qui est comme moi! Ouais!!!" *lol*

Anyway, keep well.

Regards,
Eben

--- In domaindrivendesign@yahoogroups.com, Nuno Lopes <nbplopes@...> wrote:
>
> Hi Greg and Mark,
>
> Thank you both for your patience and for answering some of my
> questions. I'm also patient ...
>
> To whoever cares about answering "how correct is your log?", or "prove
> your log is correct" I'll wrap up and give people some tips about
> doing this in your context. This post is long to wrap up my
> intervention in one post and the I'm off the theme.
>
> > Nuno,
> >
> > Re: log concerns use write once media to prevent editting of the
> > history. The log is additive only anyways.
>
> - Greg
>
> So we are getting to what actually may be useful to prove that an
> audit log is correct. Finely after so much nonsense and answers with
> little to no focus correctness but semantics.
>
> Irrespective of anything a "system is correct if it does what is told/
> expected to do". This is a simple definition for correctness that is
> recognized several disciplines and industries. So proving that an
> computer aided audit log is correct mounts to prove that logging
> system does what we tell it to do.
>
> " The idea is that any time something significant happens you write
> some record indicating what happened and when it happened."
>
> Marting Fowler.
>
> I like the way Martin describes it. So basically an Audit Log is a
> record of a series of events in a time line. A Logging System is one
> that records a series of events in a time line as it is told to! (or
> commanded, what ever).
>
> I specifically asked:
>
> > Correct against what?
>
>
> Without answering this it impossible to prove establish a platform of
> proof that we can work on. I think it is trivial to understand why but
> I guess it was too much to get an answer. But it would be very simple.
>
> Can think of at least two answer:
>
> A) We want to know that is correct it is correct against the logging
> system, For this matter then we need to prove that the logging system
> is correct.
> B) We want to know that is correct against state change occurrences in
> the domain model. For this matter then we need to prove that the
> series of events actually occurred as it is recorded.
>
> To prove B) we need to prove the A) first! There is no other way
> around it and I know what I'm talking about.
>
> So how can we prove A)? How do we prove that a system does what is
> suppose to do? In this case you need to prove that:
>
> 1) The logging system creates entries according to the defined
> structure capturing the timeline (when) and the structure that
> captures what happened. In this case a datetime propery and a
> structure that captures a state change (XML, a struct or whatever).
>
> 2) The logging system records the entry that is told to record. In
> other words if the system is to record X, it read X.
>
> 3) The logging system records entries in sequence in the time line.
> In other words, the next record has always the same date or a date
> after the current record.
>
> 4) No entries can be changed or deleted after recorded. (data cannot
> be tempered with)
>
> So we need to prove that the system complies with 1) 2) 3) 4). In most
> domains a 01 proof is not required due to the cost of making a
> irrefutable proof ! We usually prove beyond reasonable doubt through a
> testing methodology of choice. In some circles a specific test
> methodology is required etc etc. But basically, well you can use Unit
> Testing if you will, or you can reuse technical components already in
> the market, including for instance a WRITE ONCE MEDIA to assure 4!!!!!
>
> To prove that your logging system works correctly you don't need much
> more then this really. So show me your profs for 1), 2) 3). Until
> now I was only told about 4).
>
> You can use the above as a template to prove that your logging system
> is correct!!!!
>
> So now let's go to B)! This is were the fun starts. The proof of B)
> varies according to context. There is no general template for it.
>
> > Prove your audit log actually matches what the system thinks the
> > data is. If you can't do this an audit log is meaningless.
>
> - Greg
>
> Again another very strong phrase from Greg. There is not doubt about
> it, the way you express yourself is very convincing. But reality
> check, even if you don't go through the process of proving your audit
> log we all know it is not meaningless. It might not be sufficient in
> context though.
>
> > You seem to be confused...
>
>
> > And yes when building from events you can prove that your audit log
> > is correct, it has to be (your current state is built off the log
> > there is no opportunity for it to be out of sync).
>
> - Greg
>
> > I think you fail to see that when your AR can only change its
> > internal state by an event and you store those events that when you
> > reload the AR by replaying the events that then your audit log and
> > your AR persistence are one and the same. And thus your audit log is
> > correct, there is just no other way around that.
>
>
> - Mark
>
> Some notes about me being confused etc etc.
>
> Let me reiterate. If what the system "thinks" is given by the audit
> log as it is the case there no way, I mean no way that that we can
> prove that the series of events actually occurred towards the current
> state!!!!!!!!!!!!!!! In this situation the audit log could never lie
> since you accept by default that it is the truth!
>
> So you can't use the above as proof!!!!!!!!!!!
>
> Mark honestly who told you could do that?
>
> So what can we do? You need another system to validate that the state
> change actually occurred as described (event), and the audit log in
> the proof was actually generated by the system where the events
> occurred.
>
> In DDD terms think of an Audit Log System as an Bounded Context and
> Greg's Event Sourcing System (GESS) as another BC. So what is that
> third system?
>
> Let's accept that the log was generated by GESS for awhile (or
> commanded by a system using GESS). We will come back to this later.
>
> Since it is GESS that tells the Audit Log System what to log, you need
> to prove that it is being truthful about the state change and only
> then you may say that your audit log is correct in B) terms. In other
> words is not making a mistake by telling something that didn't
> actually occurred. But how can GESS make a mistake? Well GESS can't
> but the programmer that coded GESS can! But where? For instance here:
>
> > FireEvent(new Swapped(P1, P2));
>
> Again here you can use various strategies depending how irrefutable
> you want that prove to be. But the common way we do it is by Unit
> Testing. HERE IT IS YOUR THIRD SYSTEM.
>
> Now this is the CENTRAL ASPECT of the thing: Per Mark, unit tests are
> made considering Commands as the input and State Change Events as the
> output much like a function.
>
> So in the end of the day if A) is proven, the audit log is as correct
> as the unit tests prove to be if you use unit test to establish
> correctness.
>
> Break through? Not really. Indeed if you unit test your log entries
> you get the same result. The interesting bit is that Greg tests both
> the domain object (AR) and passing information to the audit log system
> in one Test Case. Some people might like it, some people may frown
> upon this concept. Someone may consider adding state change event
> mechanism to the ubiquitous language something to forbid, but it may
> be ok in some circles.
>
> So next time someone asks "How correct your log is?" Just say "as far
> as my unit tests are correct" You can never miss.
>
> I almost forgot. We need to prove that the audit log is generated by
> the system in question. Well don't take my word for it, every single
> entry can be digitally signed by the system :)
>
> Another way would be simply have a system that produces these logs
> automatically as suggested. You would need to prove that this system
> is correct though.
>
> Cheers,
>
> Nuno
> PS: The business value of something is always defined by the business
> in context.
>
> Coupling the domain model with the persistence system mechanism and
> justifying it by making it part of the ubiquitous language is smart.
> Yet talking about a evasive persistence mechanism, event processing
> model and so on ... We could just make this logging process
> transparent much like NHibernate makes persistence transparent and
> decouple the all thing out couldn't we? Someone would actually
> consider the former a bad architecture. But I guess, nowadays
> everything is possible as a case is a case.
>

 

The business value associated with CEP is not a new idea.

I understand you mean Complex Event Processing ??

bhp

On Sat, Oct 31, 2009 at 3:21 PM, Greg Young <gregoryyoung1@gmail.com> wrote:

 

You can enable logging in SQL of course if you do you lose information.

More often than not the same data can change in multiple ways, which way the data changed is often more valuable than knowing that the data changed. I like to use volume on orders in the stock market as an example of this... They can change because a trader updated their order, because the system updated their order or because they traded some amount of volume. If you are looking for liquidity you don't care which of these caused the change (you only care about the current volume) but there is immense business value when looking from other perspectives. 

There is business value in the event log as you can retroactively look back on the data in new and different ways as opposed to needing to start tracking a new concept. I like to give the example of an online retailer. My business unit comes to me and says 'we think there is value in knowing how often items were removed from people's shopping carts (or even better removed then added again). With an event log I can easily write a report which is a new perspective of my old data and provide it immediately, without the event log I can only report from here forward. Because everything that has happened is in the log (it has to be) I can always go back and view that information in new and interesting ways. 

When working with snapshots you are losing information and more scarily hoping to predict how the business will want to work with it's data in the future. 

The business value associated with CEP is not a new idea.

Greg

Sent from my iPhone

On 2009-10-31, at 2:14, Nuno Lopes <nbplopes@gmail.com> wrote:

 

Wait Mark. 

"audit log and your AR persistence are one and the same."

So that is your measure of correctness? Good. 

I think you fail to recognize that: 

1) There a bunch IFs in your on passage description and each of them can go wrong at any time. There is a particular one that is a big if. The fact that the events exactly characterize the state change to its full extent.

2) You gave one measure of correctness for an audit log that fits the intent. There are others depending on the audit objectives.

3) That a correct audit log in those terms is not difficult to achieve provided the proper interpreter.

Like any peace of machinery it works well when everything complies with the requirements. So to assure that everything runs smoothly you use unit tests as you already pointed out.

Mark if you find this strategy persisting and rebuilding ARs  useful for you work, good. I will not convince you otherwise.

I'm not yet convinced. I'm usually easy to convince but call it instinct on this one. I let you earlier adopters to provided more feedback along the next years. Some drawback reports will for certain appear. It look like the domain design comes to meet the needs of the persistence mechanism rather then the persistence comes to meet the needs of the overall system, not to mention other non functional needs like productivity etc.

Furthermore I would like to see some studies around the throughput stress these  systems bring to the network in terms of messages moving around in such granular ARs as they seam to be but that is another story.

Nuno

PS: You can actually build an automatic logging system for state changes in a database and produce a correct log, some of them can actually do that for you for free. Just switch on the SQL Server Trace, record everything and reapply the transactions. This for a fraction of the price depending on the objectives !!!!!!