In this post, we will learn about software architect.
This is a note for me while I’m reading the book “Head First Software Architecture” by Raju Gandhi, Mark Richards & Neal Ford.
TL;DR
- Software architect basics
- Know your capabilities
- The two law of software architecture ( current )
- Logical components
Okay, let’s go further the details
The two law of software architecture
There is nothing “static” about architecture. It is constantly changing and evolving.
Requirements and circumstances change. It’s up to you to modify your architecture to meet new goals.
For every decision you make, there is a trade-off. You can’t have it all.
The First Law of Software Architecture: Everything in software architecture is a trade-off.
The answer to every question in software architecture is “it depends.” It depends on the requirements, the constraints, the goals, the team, the technology, the budget, the timeline, and so on. There is no one-size-fits-all answer. You have to weigh the pros and cons of each decision and make the best choice for your specific situation.
The Second Law of Software Architecture: Why is more important than how.
To formalize the process of capturing architectural decisions, use architectural decision records (ADRs). An ADR is a document that captures an important architectural decision made during the development of a system. It describes the context of the decision, the decision itself, and the consequences of the decision. These documents have seven sections: Title, Status, Context, Decision, Consequences, Governance, and Notes.
The instance of Architectural Decision Records (ADRs)
- Title: The title of the ADR should be descriptive and concise.
- Status: The status of the ADR should be one of the following: Proposed, Accepted, Rejected, Deprecated, or Superseded.
- Context: The context of the ADR should describe the forces that are driving the decision.
- Decision: The decision section should describe the decision that was made.
- Consequences: The consequences section should describe the impact of the decision.
- Governance: The governance section should describe how the decision will be enforced.
- Notes: The notes section should contain any additional information that is relevant to the decision.
- Title:
001: Use of queues for asynchronous messaging between order and downstream services
- Status:
Accepted
- Context:
The trading service must inform downstream services (namely the notification and analytics services, for now) about new items available for sale about all transactions. This can be done through synchronous messaging (using REST) or asynchronous messaging (using queues or topics).
- Decision:
We will use queues for asynchronous messaging between the order service and downstream services.
Use queues makes the system more extensible, since each queue can deliver a different message type, and the downstream services can consume messages at their own pace. Furthermore, queues provide a natural buffer between the order service and the downstream services, which can help to absorb spikes in traffic. The trading service is acutely aware of any and all subscribers, adding a new consumer involves modifying it - which improves the security of the system.
- Consequences:
Queues mean a higher degree of coupling between services.
We will need to provision queuing infrastructure. It will require additional operational overhead.
If additional consumers are added, the trading service will need to be modified to send messages to the new queue.
- Governance:
The decision will be enforced by the trading service team.
- Notes:
Original author: @hei
Approved date: 2021-01-01
Approved by: @hei
Superseded date: N/A
Last modified date: 2021-01-01
Modified by: @hei
Last modification: Added notes section
Over time, your ADRs will build into a log of architectural decisions that will serve as the memory store of your project.
An ADR’s title should consist of a three-digit numerical prefix and a noun-heavy, succinct description of the decision being made.