Question

I’m working on a fairly large C++ project on Linux. We are trying to come up with criteria for organizing our source file directory structure.

One thought we have is to have the directory structure reflect our architecture choices. For instance, we would have one root level for our domain classes and another for our boundary classes, and one for our domain-agnostic infrastructure classes.

So in a banking application, we might have a directory called src/domain/accounts, src/domain/customerTransactions, src/boundary/customerInputViews, etc. We might then have another directory called src/infra/collections, src/infra/threading, etc.

Also, within that structure, we’d isolate interface classes from implementation classes. We’d do that so clients of interfaces would not be dependent on the directory structure of the implementation classes.

Any thoughts?

Answer 1

Breaking code into independent parts sounds like a good idea. That would allow you to potentially break stuff into separate units (for autotools: you could have convenience libs for organization, and later even separate them complete into shared libs).

Of course the submodules should contain everything needed to build: headers, sources and build infrastructure (maybe only missing a top-level build definition file which gets included). This will make sure that work can be done on small units (but test the whole thing).