Ultimately this leads to this strategy actually ending up the same as strategy number one. (Trust me, the deadline is always looming.)
test concerns on a package level
almost doesn't need an IDE (vi can be enough )
needs vigilant developers
Have one concern per module
Let's define a module as a Maven module. We have a single project containing multiple modules. The single project will provide a component that fulfills multiple functions and integrations.
With this strategy we actually have Maven guarding the bounderies of each module (as long as we don't fiddle freely with the dependencies).
automatic guarding of separation, clean packages
allows an easy big bang integration test
a single codebase for multiple concerns
needs proper integration (is that really a con :-) )
no more Q&D shortcuts before the deadline
Have one concern per component
automatic guarding of separation
isolated development, testing and documenting
re-usable in different scenarios
bottom-up integration testing is needed
multiple codebases where multiple concerns are spanned
Now most of these cons stem from the fact that there are no tools available to help us out. We don't have a toolbox that says: component development integration tools. Thus releasing many components becomes a choir. Testing each commit on a component doesn't reach up the component integration tree, again we need to invtervene manually. And lastly we loose the overview of when many components are involved and we don't like it when we see something that does not fit our brain.