Otherwise, these concerns would end up scattered across many modules and tangled with one another in your platform. 

Sorry I was a little slow following up but there is an overlap between your comments here and a follow-up to the findbugs post I wanted to write. It’s there now and I think you’ll find it interesting.

The nub is that there are architectural components and there are physical components (like packages). These may have a one-to-one correspondence but this is not essential. It follows that tangled packages are a smell but tangled architecture is … well more than that. In the extreme case, it equates to no architecture at all (just a bunch of classes).

Chunks of the piece are a bit tool-centric to get the views of the architectural components (Structure101 transformations), but the issues are, as ever, generic.

Cheers, Ian

Definitely agreed, I also think of a package as a proper module. One of my major references in Software Engineering is Ivar Jacobson, who stated that software development processes should iteratively and incrementally refine software artifacts (or models if you like). According to this statement, the Use Case model, Analysis Model, and Design Model are gradually and parallelly evolved by the architect. Software modularity must be thought of from the beginning, as a cross-model concern.

Specifically about the Analysis Model, high level classes may be grouped together in packages, when modularity becomes totally evident for the first time. Therefore, the architect should focus mainly on dependencies among packages, and package boundaries. The modularity criteria and principles take place here as well.

However, during the Design Model drafting, when technology-specific concerns pop up, a compiled language may empower the architect to place one logical package scattered in more than one (physical) component, with no architectural drawback. If this is the scenario in place, then dependencies among components are the ones that matter the most at the end.

Reminded me of http://www.cs.auckland.ac.nz/~ewan/essays/agenda.html which argues that most people in software view the adjective “modular” purely as a synonym for “good” (as opposed to any formal understanding of what modularity might actually mean).

Totally agree re thinking of a module as a block of code, which could be a low- (method, class) or high-level (component, web service). But I would interject that there is (should be) a level inbetween, what we might broadly think of as packages (or class clusters a la Booch). I wrote a post on this just yesterday and would be interested whether you agree with this.

We’ve been working on a highly changeable environment, building internet applications that should keep changing in order stay cutting edge and useful to people.

Loosely-coupled services have been the best shot for a while, and both interfaces and abstract software pieces play a very important part here, as you know.

Cheers!

We have to take these principals and not only apply them in our code, but also scale it up into the services/platforms we offer, business logic used etc.

Especially these days when we are slowly branching away from software as a service, but more towards platforms as a service.

We must create code/modules/services to be as loosely-coupled and agnostic as possible which ultimately shows others that we are developers/architects with a readiness towards change.