This is my collection of notes and opinions on Software Architecture. This helps to guide me through software architecture and design. I publish this to hope this will be helpful for others, and also to receive feedback as well 🙂
Architecture is about identifying the necessary components to support the business requirements, their characteristic, role, and how they interact with each other.
Software design is the realization of the architecture. There may be multiple designs that support the architecture. One can consider the architecture is the most abstract design of the system.
Architecture is about things that are not likely to change throughout the lifecycle of the system. It’s like when you build a house, the architecture tells you how many stories, where are the doors, where are the rooms. These elements are fixed, at least for a very very long time. The furniture may be changed, the paint may be changed, the people in the room may be changed, but it’s not likely that you will change the location of the door.
Architecture is also not a one-time thing. As time goes by, there are new requirements, new technology, and new people. New components may be identified, or existing components may be split or merged. The architecture should be reviewed once for a while (quarterly?) to update with the current status.
We should be able to come up with the basic architecture of the system with enough requirements. If there are not enough requirements to come up with an architecture, then just don’t start. The architecture should not be changed dramatically when the requirement changes. If the requirement changes too much or too fast, then we should stop engineering and finalize the requirements first.
Going straight into coding without doing architecture is wrong. Architecture helps to see the big picture and the end state of the system. Most of the time, the developer would have a picture in mind about the overview of the system, and that picture is likely to be the first iteration of the architecture.
Architecture is hard, you have to think in term of abstraction. It’s very tempting to go to the detail level such as what database or framework should be used. But we should leave the details later, and in fact, the detail should not influence the architecture. I find it useful to note down all the details and defer the discussion later.
Architecture should be technology-free. Architecture defines the criteria to select technology and framework. For example, Kafka is a technology, a design choice, the architecture should not restrict to only Kafka but it should tell that Kafka is the right choice. At the architecture level, it could just be a distributed queue.
Saying we use micro-services architecture at the beginning is a premature decision. Micro-services is a design choice where the components communicate across networks. The architecture should support the micro-services decision, not that microservice enforce the architecture.