Software Architecture Books Summary And Highlights -- Part 2 Architecture and Architect
About Architect and Architecture
Highlights
Goal of Software Architecture
An effective architecture is one in which the most common changes are local, and hence easy to make.
SAP ch2 Why is software architecture important
The goal of software architecture is to minimize the human resources required to build and maintain the required system.
CLA Part I Introduction
The strategy is to leave as many options open as possible, for as long as possible.
Good architecture helps to scale development with multiple teams.
A good software architecture communicates the operational needs of the system. e.g. make developer aware of operation system, hardware limitation.
The most important thing a good architecture can do to support behavior is to clarify and expose that behavior so that the intent of the system is visible at the architectural level.
A good architecture makes the system easy to change, in all the ways that it must change, by leaving options open because some trade-offs are hard to make.
CLA Part V Architecture
Why architecture is important
- predict system quality
- language to communicate with stakeholder
- early design
- constraint on implementation
- Influences on Organizational Structure - hard to change
- enable incremental change
SAP ch2 Why is software architecture important
CAP
We can create a system where some capabilities are CP, and some are AP. No matter how consistent you build your system, physical world problem can still make your system not consistent. for example, some fire burned your inventory and you will have to update it later which make the record inconsistent with real value. So AP is more reasonable goal.
MSV Ch 11 Microservices at Scale
Software lifespan
lifespan of a software (whether long or short) makes a big difference in design.
Software with a long lifespan should be made easy to adapt to new dependency version or changes.
Hyrum’s Law: With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody
Given enough time and enough users, even the most innocuous change will break something; your analysis of the value of that change must incorporate the difficulty in investigating, identifying, and resolving those breakages
The more frequently you change your infrastructure, the easier it becomes to do so. Because during your upgrade, it stops depending on the nuances of the underlying implementation. Instead, it depends on the actual abstraction guaranteed by the language or OS. You are making your code easier to be changed.
SWG ch 1 what is software engineering?
Technical Debt
Developers may make sub-optimal decisions due to a lack of understanding of the structures of the system, schedule pressures, or perhaps a lack of clarity in the architecture from the start. This kind of deterioration is a form of technical debt, called architecture debt.
SAP ch3 Understanding Quality Attributes
Quality Attribute
What is quality attribute
The architect (or architecture team) should, on an ongoing basis, base the architecture on a prioritized list of well-specified quality attribute requirements
The architecture should contain a specific (and small) set of resource contention areas, whose resolution is clearly specified and maintained. e.g. SLO
SAP ch1 What is Software Architecture
Quality Attributes of the Architecture
- buildability how well the architecture lends itself to rapid and efficient development.
- Conceptual integrity: Conceptual integrity demands that the same thing is done in the same way through the architecture.
- Marketability**:** how easy to persuade others to adopt this
Development Distributability
Organization structure support of distributed team development and communication
SAP ch 14 working with other quality attributes
Architectural fitness function:
Any mechanism that performs an objective integrity assessment of some architecture characteristic or combination of architecture characteristics. The fitness function can be
For example, Fitness function to limit a module’s dependency
- No component shall have more than <some number> of total dependencies
- <some component> should not have a dependency on <another component>
The fitness function should not be overused. We should build an executable checklist of important but not urgent principles on software projects which doesn’t hamper developers.
SAH ch 1 What Happens When There Are No “Best Practices”
Layers
Domain model 4 layers
Concentrate all the code related to the domain model in one layer and isolate it from the user interface, application, and infrastructure code.
- UI layer: show information
- Application layer: thin layer connecting UI layer with domain layer by distributing tasks to domain layer
- Domain layer: domain model, business model, business logic
- Infrastructure layer: technical infrastructure
The layered architecture could be too complicated for simple project and less experienced team. Another option is to put all business logic into UI and use a relational db. This can improve productivity and easy to implement. Cons are hard to reuse, hard to integrate with other apps, hard to scale
DDD Ch 4 Isolating the Domain
A strict definition of “level” is “the distance from the inputs and outputs.” The farther a policy is from both the inputs and the outputs of the system, the higher its level. The policies that manage input and output are the lowest level policies in the system.
Higher level are changed less frequently
Source code dependencies must point only inward, toward higher-level policies.
data formats declared in an outer circle should not be used by an inner circle, especially if those formats are generated by a framework in an outer circle. We don’t want anything in an outer circle to impact the inner circles.
The software in the use cases layer contains application-specific business rules. It encapsulates and implements all of the use cases of the system. These use cases orchestrate the flow of data to and from the entities, and direct those entities to use their Critical Business Rules to achieve the goals of the use case. We do not expect changes in this layer to affect the entities.
Typically the data that crosses the boundaries consists of simple data structures.
High level core business rule logic can only call low level input and output modules through interface to avoid dependency from high level to low level
CLA Part V: Architecture
Framework
There is a risk that an architecture can interfere with expressive implementations of the domain model and easy change.
Don’t write frameworks for dummies. The framework author should respect all developers’ capability in design and avoid encapsulating too much irrelevant technical details in the framework.
DDD Ch 17 Bring the strategy together
Frameworks are single direction commitment. You make a huge commitment to use the framework while framework author has no commitment to you.
So don’t couple a framework.
If the framework wants you to derive your business objects from its base classes, say no! Derive proxies instead, and keep those proxies in components that are plugins to your business rules. Don’t let frameworks into your core code. Instead, integrate them into components that plug in to your core code, following the Dependency Rule
CLA Part VI Details
Integrating with Third-Party Software
such as CMS and CRM
“Build if it is unique to what you do, and can be considered a strategic asset; buy if your use of the tool isn’t that special.
If you’ve decided to buy a product but the particular capabilities it provides aren’t that special to you, it might make more sense to change how your organization works rather than embark on complex customization.
The core idea here is to do any customizations on a platform you control, and to limit the number of different consumers of the tool itself.
Also add service and data wrapper above external services so that you can limit the usage to only what you need and easily switch to other external services.
MSV Ch 4 Integration
When to break down large things?
For domain model
If a large BOUNDED CONTEXT addresses compelling integration needs, and if it seems feasible apart from the complexity of the model itself, then breaking up the CONTEXT may not be the best answer.
DDD ch 14 Maintaining Model Integrity
To mitigate the risk of splitting, try to make mistake in small less risky place
When building monolith, know it will be eventually splitted and prepare for that and split when necessary. If you can do that, maybe define clear service boundary first.
MSV Ch 5 Splitting the monolith
Architectural Decomposition
2 types of decomposition
- Component-based decomposition
- The tactical forking approach involves making replicas of an application and chipping away at the unwanted parts to form services,
- most suited to codebases that have little or no internal structure.
Ideal Abstraction and Instability relationship is the main sequence which is easy for decomposition.
Zone of pain and Zone of uselessness are hard to decompose.
SAH Ch4 Architectural Decomposition
Be careful to enforce your architecture and decoupling in an efficient way such as with tools and components considering your team size and skill level. Because a good architecture could be easily breached.
CLA Part VI Details
Microservice Architecture
Pros:
- time to market reduced
- Each team can make its own technology choices for its service
- Services are more easily scaled than coarser-grained applications
Cons:
- Overhead is increased
- Microservices are less suitable for complex transactions because of the difficulty of synchronizing activities across distributed systems.
- The freedom for every team to choose its own technology comes at a cost
- Intellectual control of the total system may be difficult because of the large number of microservices.
- Hard to design service boundary
- need to allow deploy versions independently
SAP ch 5 Deployability
MicroService Principles
Principles:
- automation
- independently deployable
- decentralize everything including team responsibility
- Model Around Business Concepts
- highly observable
- isolate failure kw(failure detection)
- Hide Internal Implementation Details
consider starting monolithic first and break things out when you’re stable.
MSV Ch 12 Bringing It All Together
SOAP vs micro service Architecture
Microservice architectures are assumed to compose a single system and be managed by a single organization, however, whereas SOAs provide reusable components that are assumed to be heterogeneous and managed by distinct organizations.
SAP ch 7 Integrability
vs SOA Service-oriented architecture: SOA is top down and ambiguous in many practice. Microservice evolves from real practice.
MSV Ch1 What is MicroService
Required Standard for MicroService
allowing too much divergence among different services can result in a pretty torrid time.
So we need to find the balance between optimizing for autonomy of the individual microservice without losing sight of the bigger picture. Defining clear attributes that each service should have is one way of being clear as to where that balance sits.
The standards include: monitoring, allowing few interface standards, and architectural safety (basic service reliability, error handling)
MSV Ch2 The evolutionary architect
Governance and Leading from the Center
Governance ensures that enterprise objectives are achieved by evaluating stakeholder needs, conditions and options; setting direction through prioritisation and decision making; and monitoring performance, compliance and progress against agreed-on direction and objectives.
Having a governance group with architect as chairman, having the bulk of the group drawn from the technologists of each delivery team — the leads of each team at a minimum.
When the majority of group members disagree with architect, what to do? Need to find a balance. Sometimes architect wants to stick to his decision to avoid the system heading to too much troubles. Sometimes it is fine to make mistake and learn
MSV Ch2 The evolutionary architect
Team building:
Microservice can encourage people to step up to take more ownership and grow their careers.
MSV Ch2 The evolutionary architect
Agile Development
Agile, as it was first created, seemed to work best in small organizations building small products.
Organizations of medium to large size wishing to apply Agile to large projects quickly found that coordinating the large number of small Agile teams was a formidable challenge.
In Agile development, better to have overall architecture design at first but not too much. Also consider the modifiability in the future and do small incremental design in the future.
SAP Ch 24 The role of Architects in Projects
User interface
options:
1. API composition
Pros:
- same api for both mobile and web
Cons:
- cannot differ response for mobile vs web because mobile usually has fewer bandwidth
- ambiguous ownership on UI and api per domain
2. Render UI fragment on server side with different microservices
Pros:
- same team makes both UI and API change
cons:
- hard to control UI consistency
- not useful for native app
- the rendered UI cannot have too complicated behavior
3. Backends for Frontends
Use global API gateway or API gateway per client type (web vs mobile)
Pros:
marshal multiple backend calls, vary and aggregate content if needed for different devices, and serve it up,
Cons:
it can take on logic it shouldn’t
We can use hybrid solution of all 3 above
MSV Ch 4 Integration
Architect responsibility
Unless your requirements are unprecedented—possible, but unlikely—your quality attributes should be achieved by using well-known architectural patterns and tactics
SAP ch1 What is Software Architecture
Deciding when changes are essential, determining which change paths have the least risk, assessing the consequences of proposed changes, and arbitrating sequences and priorities for requested changes all require broad insight into the relationships, performance, and behaviors of system software elements. These tasks are all part of the job description for an architect.
SAP ch2 Why is software architecture important
An architecture’s duties, skills and knowledge involves many communication, interpersonal, organizational, leadership skills
SAP Ch 25 Architecture Competence
Architect needs to fight for better architecture against not urgent feature requirement
CLA Part I Introduction
All software systems can be decomposed into two major elements: policy and details.
The policy element embodies all the business rules and procedures. The details are those things that are necessary to enable humans, other systems, and programmers to communicate with the policy, but that do not impact the behavior of the policy at all. e.g. IO devices, databases,
The goal of the architect is to create a shape for the system that recognizes policy as the most essential element of the system while making the details irrelevant to that policy. This allows decisions about those details to be delayed and deferred.
A good architect maximizes the number of decisions not made.
CLA Part V Architecture
as software engineers, we are asked to make more complex decisions with higher-stakes outcomes, often based on imprecise estimates of time and growth.
SWG ch 1 what is software engineering?
Become a Better Architect
- Be mentored by a great architect either from inside the company or from professional communities
- mentor others as giving back
SAP Ch 25 Architecture Competence
For an architect, understanding where to push back or where to go with the flow is often something that comes only with experience.
MSV Ch2 The evolutionary architect
Modeler Responsibility
The modeler who designs the model must also write implementation code so that
- the business logic can be implemented correctly based on model
- the modeler could quickly detect technical limitation and update model to reflect that
DDD Ch 3 Binding Model and Implementation
Related Chapters
DDD Ch 4 Isolating the Domain
DDD ch 14 Maintaining Model Integrity
DDD Ch 17 Bring the strategy together
SAP ch 1 What is Software Architecture
SAP ch 2 Why is software architecture important
SAP ch 3 Understanding Quality Attributes
SAP ch 5 Deployability
SAP ch 7 Integrability
SAP ch 14 working with other quality attributes
SAP Ch 19 Architecturally Significant Requirements
SAP Ch 24 The role of Architects in Projects
SAP Ch 25 Architecture Competence
SAH ch 1 What Happens When There Are No “Best Practices”
SAH Ch 4 Architectural Decomposition
SAH Ch15 Build Your Own Trade-Of Analysis
CLA Part I Introduction
CLA Part V Architecture
CLA Part VI Details
MSV Ch1 What is MicroService
MSV Ch2 The evolutionary architect
MSV Ch 4 Integration
MSV Ch 5 Splitting the monolith
MSV Ch 11 Microservices at Scale
MSV Ch 12 Bringing It All Together
SWG ch 1 what is software engineering?
