Packaging & namespacing

This post is part of The Software Architecture Chronicles, a series of posts about Software Architecture. In them, I write about what I’ve learned on Software Architecture, how I think of it, and how I use that knowledge. The contents of this post might make more sense if you read the previous posts in this series.

The architecture of a system is the high-level view of that system, the big picture, the system design in broad strokes. The architectural decisions are the structural decisions in the system, the ones that affect the whole code base, the ones that define where everything else will be built on top of.

Amongst other things, architecture is responsible for deciding the systems:

  • Components
  • Relationships between components
  • Principles guiding the design and evolution of components and relationships

In other words, these are the design decisions that are more difficult to change as the system evolves, it’s the foundations that give support to feature development.

Continue reading

Advertisements