Small review
Julien
Here are a few humble thoughts after reading your documents.
About A Stereotypical Architecture :
I think this chapter should focus a bit more on the functionnal
aspects of the architecture unless it’s already done in a previous
chapter. You discuss it at the end of the Domain Driven Design
section :
“A stereotypical example of this would be when changing the sex of an
employee you must after go edit their health insurance information.
This is far worse than the creation of an anemic model, this is the
creation of a glorified excel spreadsheet.”
I think this example should be a bit more elaborated even if it’s
redundant with what DDD really is. For instance, your example shows
that this architecture doesn’t provide a simple way to enable
communication between different services. Why not use the insurance
scenario as a guide line for the chapter and provide a few use cases
where the architecture is “a glorified excel spreadsheet” ?
About Events as a Storage Mechanism
“This was especially true in high performance, mission critical, and/
or highly secure systems. In fact if we look at the inner workings of
a RDBMS we will find that most RDBMSs themselves not actually work by
managing current state!”
We’re not all familiar with that kind of systems and/or with RDBMSs.
Why not explain very briefly the concept of a transaction log?
There’s actually quite a bit of your definition going on in the “Other
Definitions and Discussions” section. IMHO, references to SOM and
Fowler should be secondary to understanding the Domain Event concept.
I think the definition should stand on its own . However, I had the
impression that Fowler and SOM were central to your document.
Accounting is the example that everybody knows for modeling data as a
stream of events, which is good because it will talk to most of us.
However, it’s also what makes the example weak because many people
implemented such systems with the stereotypical architecture we’re
trying to avoid. IMHO, the business value of the event log should be
discussed just after accounting and before the technical aspects such
as scalability or ORMs to balance this problem. By the way, I think it
might be interesting to desmonstrate the problems of correctly
configuring eager/lazy loading within the stereotypical architecture
with a sample code. Udi dahan has some nice slides about that.
Generally speaking, I also noticed that sometimes you drop hints of
things to come such as “Snapshots can be taken asynchronously by a
process monitoring the Event Store” or “the use of the mememto pattern
can be highly advantageous”. In this 2 examples, I found it was a bit
weird to have these facts written without more explanations about why
you would want to do that. I wonder if it might not be better to
remove them and simply focus on the current topic until they can be
duely explained.
This was just some tiny ideas to provide feedback but overall, it was
great ! I’m waiting for more !
Cheers,
Julien
Rinat Abdullin
Check out Fojhin sample for the Memento pattern around DDDD and CQRS
(http://elegantcode.com/2009/11/20/cqrs-the-domain-events/)
As for the async snapshots - that's just the async worker process,
running in the background and appending new records to the snapshots
table (for the objects that have long event history, or, for example,
take too much time to load). This is rather straightforward.
Best regards,
Rinat Abdullin
Julien
Greg's document.
My point was that they are mentioned in some places but discussed a
few pages later which might be confusing for someone discovering DDDD
(I think that most people here have read quite a lot about the topic
already. What is obvious for us won't be for everybody).