Share via

Logical vs. Physical Architectural Modeling Concerns

  • Article

We've been having hallway discussions about some of the dimensions of modeling application architectures.  SDM adopts a particularly physical perspective, as it focuses on the deployment packaging stack of concerns.  Its focus is on resources (things like assemblies, config, XML files etc.) that are composed into independently deployable applications, that are composed into systems, which are then composed into still higher level systems.  SDM, does allow you focus on tangible software entities and express their behavior - very CBD-like.  But of course there are other perspectives, and particularly troublesome to some is the absence in the current designers of a logical perspective, in which you can define what an application does, independently of describing how it does it or how that implementation is packaged.  The discussion turned to the role of namespace in that logical perspective, specifically to the question, are namespaces the primary logical organizing perspective. I wrote some comments in an email on the subject and have elaborated on them here and invite comment.

While namespaces are clearly not a packaging concept as they can cut across assemblies, they are not necessarily the best or only way to organize the elements in a logical architecture.  Instead the notion of a cross-cutting and entirely logical organization of function is proposed.  The term "module" was suggested some months ago by a colleagure for this notion.  Thus a module is an arbitrary collection of function.  A module could be a collection of methods, one class, many classes; may be coincident with an assembly, cross assemblies or contain assemblies.  Modules can also describe data. Early on in your design, you might think about modules but go no further than giving a name and describing the role.  A classic block structure architecture diagram might be used to show the way modules interact, either depicting a specific instance of an architecture or a pattern before any details exist of the behavior of each module. 

You might assign namespaces to modules – although the naming of types/classes, while important, is not intriniscally linked to the logical structuring of software.  Namespaces might reflect the logical structure and you might be tempted to conflate the two, such that you use namespaces when really you arethinking about modules.  At some point in your design process as you refine your module designs and start to define classes, creating namespaces will become important.  And at some point in your design packaging considerations will become important, when you will specify applications, frameworks, and systems.  With your packaging decisions you harden the partitioning of the functions in your modules and make communication and binding decisions.  

Thus there are module, namespace and packaging dimensions, These represent orthogonal but related concerns which inform each other.  Different design strategies will have you tackle these aspects: physical structure (systems, applications, frameworks), logical structure (modules) and implementation (classes with namespaces) in different amounts at different times – being able to reason about all three as and when you choose will be the most flexible and should be what we aim for in tools.  Associating a namespace with a module or even a package may make good sense when the purpose of the module/package and the goals of the namespace align but the two are not intrinsically linked.

Comments