Structure of DDD+ES Solution in Visual Studio
Monday, July 23, 2012 at 17:55Kerry Street has recently raised really interesting question:
Speaking of vocabulary, how do you view and speak about the first "D" in DDD? "Domain" itself can be overloaded.
Yes, indeed, I tend to use domain interchangeably. This can lead to potential confusion. The primary meaning of "domain" is just "some problem space that has to be addressed via modeling and then expression in software".
When I start a project, it usually has a single "Bounded Context", which matches the problem space. Hence, it seems natural to call this BC "Domain" simply because they match in this specific situation. However, as solution grows, new BCs are discovered and added. In the end, this leads to rather ambiguous solution structure:
Now, that I think about it, "Domain.BC" in this case would be better named "Orchestration BC" or at least "Tenants BC". Sorry for the confusion and thanks for brining this issue up. I'll need to correct samples and my own projects to clear this up.
While we are at this topic, image above, displays Visual Studio solution structure for the second version of Lokad Salescast (big data inventory optimization platform). As you can see, there is nothing really peculiar there and it matches pretty closely structure in Lokad.CQRS Sample.
The only non-obvious tidbit is that "Worker" project is both an executable console (using file system for local runs) and a WorkerRole implementation (used for Azure deployments). Like-wise, both web projects would feel natural running locally (using file-based event streams and persistence) and in Windows Azure.
Reader Comments (4)
Ouch! That's a lot of projects. Granted, it's not as many as NServiceBus, but the pain in .NET land I'm feeling right now comes from compile times and JIT startup times on anything over 3-4 projects. Even so, it's nice to see what your structure/layout looks like.
Oh, no. Jonathan, I think, this is is a really small and fast project, given it's capabilities :)
I'll try to write a blog post with a deeper dive into the details and capabilities.
I've been trying to distill a more complete definition of a BC and I'm on the fence about a few aspects. In this example solution it seems that Admin, Client, Core and Data are all distinct BCs. My initial thought would be that the entire solution is a single BC consisting of a few different modules because to me a BC is more of a logical business domain boundary than a technical boundary. What are your thoughts on the differences between a BC and a module and how that relates to a VS solution?
In essence, breaking down a problem domain into distinct bounded contexts depends on level of your immersion into it. For instance, on google maps with the minimal zoom you would see just continents and countries. However, if you dive deeper, you would start seeing lower-level details - smaller rivers, cities etc.
Same is with the DDD - break down into bounded contexts depends on how you see the domain. Initially in Salescast I saw only one Core BC. However, as project evolved Core BC captured so many details, that it was simpler to push some of the related functionality into separate BCs.
So BCs are clearly a business and conceptual boundaries. Some of my modules (projects) map to BCs simply because it is more convenient and just helps to keep these boundaries more visual and explicit.