I have a saying I use to justify architectural decisions: "it is easier to keep things separate than to separate them later" --JimLogan

----

Separation is surely a crucial device in computer architecture and this advice is a good contribution to architectural process. (See FourLayerArchitecture, SeparationOfConcerns.) However, the intellectual challenge is more often that of choosing the dimension of separation when there are many possibilities. Here the architect builder has to settle for slight separation, a small crack that can be worked with a wedge should more separation prove useful. The EmergentComponentMethod is a good example of this technique applied to JavaBeans. Likewise, each chapter of MartinFowler's AnalysisPatterns book progresses through a sequence of separations (though you must buy his later refactoring book to find out how to move between them).

----

I am growing to think that SeparationIsAnIllusion. Things are generally intertwined. It is usually a compromise when you group things one way or another. (I said this somewhere else in more detail, but forgot where.) EverythingIsRelative

Sounds similar to what I have always said, "NarrowTheInterface."
----
Related
* SeparateCodingAndTesting
* SeparateTestClasses
* SeparateTestFiles
* SeparateDomainFromPresentation
* SeparateMeaningFromPresentation
* SeparateInterfacesFromImplementation
* SeparateSequencerFromApplication
* SeparateIoFromCalculation
* SeparateTheWhatFromTheHow 
* SeparateThreadsFromContent
* SeparateThrowAndCatch
* SeparateTransactionProcessingFromArchival