Hey. Welcome to the next CPSA Certification preparation post. The previous one is here. This time I read about architecture development. Below, I listed some approaches mentioned in the book that I use to prepare myself to CPSA Certificate. I hope the author has noting against promoting his book 🙂
Top-down approach
This approach is about starting the design from general aspects and going gradually into details. This approach can be used on any level: system, sub-system, component, etc. Here we have to think abstractly, having in mind a broader overview of the system.
Bottom-up approach
It’s the opposite of the above. In this approach, architecture development starts from the very details and moves up to more general aspects. Here we can build MVPs, try new technologies and tools, and validate decisions proving they can work in practice.
Even if these two approaches sound different, they can work together.
View-based-architecture
This is about looking int architecture development from many different views. We can try to define some components structure, sequence diagrams, describe deployment process or place the system in the broader context. Having all perspective in front of you, you consider what is important in all these views and start building architecture having in mind this information.
Iterative and incremental design
That approach is nothing else than just building an architecture piece by piece iteratively. It sounds like an agile approach where we build something, provide, get feedback, improve/extend, provide, and so on. In this approach, we can react faster to changes and avoid situations where we build something big in a few months, and in the end, we finish with unhappy customers, solutions difficult to develop, etc. I intuitively find this approach very reasonable, safe, and relatively low-cost.
Domain-driven design
DDD is an approach to building the software in close cooperation with business stakeholders. The structure of the application reflects business processes. Communication between people from the business and development team uses a common language called ubiquitous.
We have two approaches to DDD:
- Strategic design is about finding so-called bounded contexts and transforming them into subdomain or business-driven partitions. Top-down approach.
- Tactical design is more like a bottom-up approach. Here we focus on low-level things like events, entities or value objects.
Event Storming is the event in software or architecture development that helps identify low-level aspects mentioned in tactical design. In simple words, the team and stakeholders meet in one room, and using sticky notes they try to describe the business and technical people by asking questions are finding connections between the provided information. More about event storming here.
Evolutionary architecture
When talking about evolutionary architecture, it’s worth to mention first about fitness functions. Fitness function (evolutionary function) evaluates how close the given solution is to the optimum solution. With fitness functions with mostly meet when talking about generic algorithms.
In the context of the architecture, we can use fitness functions as a tool to measure some quality requirements, for instance performance. We can define requirements as a test, which will be our fitness function, and improve our software architecture to be closer and closer to the requirement. This way the architecture development becomes evolutionary.
Quality-driven software architecture
In short it’s similar to evolutionary architecture development and iterative approach but focusing on quality scenarios. Like in global analysis mentioned in Summary of this post, we identify concrete set of actions to achieve required quality scenario.
Repetitive steps in this approach are:
- identify quality requirements and prioritize,
- plan measures to be able to estimate the maturity of the increment
- implement
- Verify
Summary
Here is the list of the most important approaches. It’s not like one excludes another. From my experience, people responsible for architecture development are using a mix of those approaches to get the best result. If of course no strict rule that someone has to stick to one approach without using others. We don’t treat it as incompatible tools but more like complementary techniques.
Additionally, I have to mention something like global analysis, which is about identifying and describing the factors which could potentially affect the architecture. Based on that information, the specialists build strategies to foresee and acknowledge the potential consequences of these factors.
Functional decomposition is also one of the used approach. Here we just focus on functional requirements, which can be also grouped by any similarities.
It is also worth to mention that many problems in software architecture development can be solved by applying commonly known patterns. I will also describe some of them in incoming posts.
That all for today. See you in the next post 😉