Reputation: 141
Recently I'm struggling with implementing the 'init' logic of my DDD application.
I have services that should be initialized with the specific values, to put more of a struggle, let's say i would like in future to initialize some aggregates when the application is started up first time.
If i understand properly in CQRS with DDD concepts i could issue a command each time the application starts up, and in the command handler i would just check for invariant whether the thing was already initialized, basically when there is some persisted state registered, i would just discard this command, and act like nothing happened.
The biggest problem is that I'm unsure as where should i put this kind of startup/init behavior, it seems like it should reside in the infrastructure layer.
Many thanks :)
Upvotes: 0
Views: 533
Reputation: 3270
I don't know enough about Axon, but the problem itself is a generic one, and what follows is a generic solution.
The pattern you are looking for is Composition Root
.
A Composition Root is a (preferably) unique location in an application where modules are composed together.
It is an entry point in your app where the "composition of the object graphs" takes place. Object graphs are simply a group(s) of objects, with or without relationships between them.
Typically, in Java and .NET, you would use a dependency injection container to perform this composition. But the exact mechanism is not important; it could be using a container or could be done manually using pure DI with a central object.
Such a central object would parse/store configuration, initialize domain objects on request, initialize or store external infrastructure connections, and would be the primary entry point for a higher initializing mechanism like an application server.
The Composition Root is an application infrastructure component.
Which means only applications should have Composition Roots. Libraries and frameworks shouldn't. Also, while constructing object graphs, the composition root typically refers to configurations and injects the correct external dependencies into objects.
compose
the object graph as close as possible to the application's entry point.
This means that all your application code relies solely on Constructor Injection or Domain Lookup (or other injection patterns), and is never composed ad-hoc. Only at the entry point of the application is the entire object graph be composed.
Depending on your application, this entry point could be:
run
methods or startup hooks provided by Application servers (in languages like Ruby and Python)IControllerFactory
, in ASP.NET MVC applications Application.OnStartup
method in WPF applicationsServiceHostFactory
in WCFReading material:
Upvotes: 2
Reputation: 7275
I think I'd personally have a command dedicated to this 'first application start up'. You would then have a Command Handling Component who's sole purpose it is to decide whether it's the first start up of your application.
If yes, then you issue subsequent commands to initiate some other operations. If no, you'd ignore the command altogether, maybe log that the initialization was decided against. To drive this decision, you will need to have this state somewhere of course. How/where this is stored is up to you, although in general I'd state you should use the best tool for the problem. An Initialization-Aggregate for example would not be the right place, as that would introduce something along the lines of a System-Aggregate. I'd rather have a very simple dedicated query model for the task at hand, but that's my hunch given the question context.
Lastly, I think the infra-layer would be fine to put this in. It should be part of your start-up phase. After that you could essentially drop this command handler entirely if you'd feel like it.
That's my two cents to the situation, hope this helps @PolishCivil!
Upvotes: 2