Structure of DDD+ES Solution in Visual Studio

Kerry 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.

Published: July 23, 2012.

🤗 Check out my newsletter! It is about building products with ChatGPT and LLMs: latest news, technical insights and my journey. Check out it out