What Makes a Good Software Architecture? Principles, Practices, and Pitfalls

1. Definition of Architecture

In software development, since the term "architecture" became widespread, many architectural patterns have emerged and the focus has increased. Fundamentally, architecture—also called software architecture—is an abstract description of a system’s overall structure and components, used to guide the design of large software systems.

—Excerpt from Baidu Baike

2. What Does Architecture Do?

Many developers who only work on CRUD features imagine architecture as a quiet realm free from business noise, focusing on performance, TPS, high availability, and traffic support. In reality, architecture is only a small part of the picture. Historically, even before the internet era, C/S programs had architectural concepts.

Architecture emerges as teams grow, providing shared rules to align efforts and avoid internal friction. It helps define system boundaries, integration points, and quality expectations, especially as projects interact with existing systems and involve multiple modules and teams.

Common challenges that architecture addresses include:

Defining integration points and system boundaries when new systems must interact with existing ones.

Handling upstream module quality issues that affect downstream development.

Dealing with inconsistent code styles and maintenance difficulties across multiple contributors.

Choosing among multiple implementation options without clear criteria, leading to ad‑hoc decisions.

Reducing duplicated non‑business code (e.g., logging) and avoiding heterogeneous middleware in distributed systems.

Resolving design disagreements at the boundaries of dependent projects.

Architecture is not about swinging to the opposite extreme. For example, in large distributed systems it may be necessary to select different middleware (e.g., Kafka vs. RabbitMQ) for specific scenarios because their values are not interchangeable.

The key is to balance and choose the solution with the best cost‑benefit ratio.

The main goal of architecture is to guide everyone toward a common direction and standard, establishing a lower bound for mandatory requirements and an upper bound that defines the “ceiling” for future growth. Like designing a building’s framework, architecture sets load‑bearing walls and defines where innovation can occur, reducing complexity and misunderstanding while preventing wasteful assumptions.

Ideally, architecture becomes as natural as eating or drinking, so that taking over another’s project feels like working on your own code.

3. Best Practices for Architecture

Effective architecture relies on abstraction, often expressed through diagrams such as use‑case diagrams and robustness diagrams. Visualizing abstractions helps assess reasonableness and communication.

Another useful diagram is the robustness diagram:

The purpose of these diagrams is to:

Describe interactions with external entities (systems and end users).

Identify information and control flows between the system and those entities.

For further reading, see the article “Diagrams Used in Software Development” (https://www.cnblogs.com/Zachary-Fan/p/developdiagram.html).

In an ideal world, system boundaries align with business boundaries, but real projects often require careful prioritization before making architectural changes, especially when splitting business domains.

Key considerations before splitting or combining services include:

Whether an independent team can maintain the service and whether it has potential to become a standalone business (avoid shared‑kernel approaches when unnecessary).

Focusing on domains rather than individual features, with clear ownership to prevent overly fine‑grained components.

Assessing whether the split improves collaboration processes.

Determining if it helps distinguish core from non‑core business, enhancing stability.

After these questions, select appropriate middleware and frameworks based on:

Maturity and adoption by large companies.

Community activity and support.

Hard metrics such as performance and scalability requirements.

Soft metrics like complexity and maintainability, often compared against competitors.

Hands‑on validation through prototypes or simulations.

Reusing existing experience where possible.

4. What Is a Good Architecture?

A good architecture must align with business needs. One way to illustrate this is by treating the problem as a mathematical optimization: the sum of two numbers equals 10, and the goal is to maximize the product. The optimal combination is 5 × 5, not 3 × 7 or 4 × 6.

Architecture should not be a forced exercise or a showcase of personal preference. Choosing a middleware simply because it looks cool can introduce hidden costs and risks. The best architecture maximizes return on investment, balancing benefits such as reliability, security, scalability, maintainability, and performance against costs like manpower, time, and risk.

5. How to Become an Architect

Beyond the responsibilities listed above, an architect must first be a “good coder.” Architecture is abstract; without hands‑on experience it becomes mere theory. Practical expertise enables accurate cost evaluation and solution design.

To become a true “good coder” and move toward architect status, continuously deepen and broaden your knowledge, focusing on areas relevant to your current work. Then develop three core competencies: business understanding, communication skills, and personal influence.

In China, pure technical architects are less marketable than application‑oriented architects, so the article emphasizes the latter.

6. Conclusion

Architecture manifests in many forms, but the core ideas of monolithic design and distributed systems share the same principles. Service‑oriented architecture is essentially modular thinking applied at a different scale. Mastering these concepts is an ongoing journey; keep moving forward together.

Author: Zachary_Fan Source: https://www.cnblogs.com/Zachary-Fan/p/architecturetoarchitect.html