Quality — or non-functional requirements — is often said to drive software architecture, meaning the structure of the software and the technical decisions behind it. While this sounds plausible at first glance, a closer look reveals that the situation is far more complicated.
A good decomposition of the domain logic is crucial for making systems maintainable in the long term. Discussions often focus on Bounded Contexts — but models are far more important.
Software architecture is about managing dependencies, and independence is the goal — or so it seems. In reality, however, it is not even entirely clear what dependencies actually are.
The estimated effort of a software project usually refers to the specific team involved. But can effort be estimated objectively and independently of the team?
Good modules have high cohesion — alongside loose coupling from previous post, this is the most important property of modules. But why is cohesion so important? And how does it influence the design of software systems?
Designing architectures is one thing — but how can you ensure that the architecture you’ve designed is actually implemented? Every architect faces this challenge if they want to make an impact in a project.
Loose coupling is a very well-known concept and is regarded as an important quality of an architecture—perhaps even the most important. But how can loose coupling actually be achieved? And why exactly should an architecture have this property?
At first glance, designing a software system seems like a purely technical task. In reality, however, it requires collaboration among different roles to build a shared understanding. This involves not only shaping technical artifacts but also social processes.
Software development happens in teams. That means every idea or change affects many people. So everyone involved – including technical staff – must contribute their ideas to the organization. Fearless Change and Fearless Journey offer the tools to do just that.