Query Dbs

I don’t want (for this particular case) eventual consistency for my query databases, I prefer saving to all of them at once.

Programming this on the ProductCommands will be too cumbersome, not to mention it will not be an extensible solution, and we are very liklely to change the databases very often. This is work for a Composite.

private IWriter<Product> NewProductWriter() =>
new WriterEventCommittingDecorator<Product>(
new CompositeWriter<Product>(
new InitialStateWriter<Product>(/*...*/),
new CurrentStateWriter<Product>(/*...*/),
new ProductSearchDbWriter(/*...*/),
new ProductReportsDbWriter(/*...*/)
),
new StandardEventStorage(/*...*/)
);

I have also replaced the magic DocumentStoreWriter<T> by the actual writers that will take care of the job.

I am getting close…

One of my use cases is a standalone import that will take lots (hundreds of thousands) of products and save them all, one time each. It’s a batch text book use case. Another decorator will do the trick.

Once more…asynchronous. I will use TPL’s Dataflow for building this one.

private IWriter<Product> NewProductWriter() =>
new WriterEventCommittingDecorator<Product>(
new WriterBatchDecorator<Product>(
new CompositeWriter<Product>(
new InitialStateWriter<Product>(/*...*/),
new CurrentStateWriter<Product>(/*...*/),
new ProductSearchDbWriter(/*...*/),
new ProductReportsDbWriter(/*...*/)
),
BatchSize
),
new StandardEventStorage(/*...*/)
);

I have put the batch inside the event committing decorator because I want the events to be committed as soon as possible. I could use a similar decorator for the event storage. For the actual user interactive solution we might just leave outside the batch, which is just having a different composition root there.

Next thing could be adding some explanatory variables to avoid dizziness.

The logger has been placed inside the batch, so entities getting into the batch will not be logged, instead, only those getting out of it. Different setups can serve different purposes. We might want several loggers around, in many places.

Outro

With a set of very small components it was easy to compose an application with desired behavior. Each component has a very simple and well defined responsibility. Once in place the whole application can be tweeked to improved performance and traceability. It’s simpler to tweek just one place than many (shotgun surgery). That one place is the composition root. Many new behaviors can be implemented in form of reusable decorators.