Domain Model Project Structure
Myself and two colleagues had a very interesting discussion about the structure of our domain projects. Originally we had this sort of folder structure within our domain projects:
This wasn't awful but it also wasn't perfect, after a bit of work we decided to restructure like this:
Its difficult not to prefer this folder structure as it keeps things that are related together in the folder structure and emphasizes key abstractions/classes (such as Customer here).
Unfortunately we've had to create "Component Parts" folders that, we plan, will contain any classes that are not key aggregate roots. The top level "Component Parts" folder has very reusable classes, but the one within "Customer" is for classes that relate just to the "Customer" aggregate(s).
This idea of a "component part" may seem odd but it does help show that whilst CustomerIdentifier is important it is not in any way as key as Customer.
The discussion also emphasized that it is impossible to get a project structure that we are completely happy with, trying to impose a single hierarchy on a domain model is just so difficult to do cleanly.
Its also worth noting that the small size of this example means it is not a good example, but we have already started giving this folder structure a go and so will hopefully find out just how well it works.
You're absolutely right about the impossibility of finding a project structure that you can be completely happy with. I often think that it would be great to be able to organize these things in a similar matter as we do on a white board.
ReplyDeleteYeah that would be great, some way of setting up virtualized views on your projects/solution is something that I'd certainly be interested in.
ReplyDeleteTo set up a virtualized views of your project you could use a class diagram, but I would love to see some hierarchical grouping by namespaces added to this visulization and the ability to do this across projects in your solutions.
ReplyDelete