> Another thing that I do, is have fairly large source files, that aggregate multiple classes/structs/enums/protocols that relate to each other. It drives me nu

> Another thing that I do, is have fairly large source files, that aggregate multiple classes/structs/enums/protocols that relate to each other. It drives me nuts to deal with the typical Java "Each class has its own file -no matter how small" thing. This can go both ways - I've seen plenty of projects where you have to dig through 3k lines of unrelated spaghetti code just to find the bit you need. That turns into a special piece of hell when you have multiple team members working on it. The original motivation for having more small files was driven by these "god objects" and the limitations of version control. CVS, Visual Source Safe and to a lesser extent Subversion were much easier to use together with smaller files. If you're using modern version control (git) then that reason has gone. My personal preference is to split horizontal concerns into their own modules and depend on them; they become the core / support libraries for my team/organisation. For services I try to keep the domain-specific parts close. Tests go in a different module which mirrors the structure. When units start to get big (or become cross-cutting) they get factored into smaller units or other modules. In the end it's all a balance and unless you're under outside constraints (cough SonarCube box-ticking busywork idiocy cough) then you can generally keep it sane.