Table of Contents- I. Architecture Fundamentals - 1. Software Design Principles - 2. Additional Design Principles - 3. Other Design Principles - 4. Software Design Layering - 5. Ensuring Architecture Quality - Stability and Robustness - 6. The Right Foundation - Architecture Preparation - 7. Small Issues, Big Problems - Technical Debt Management and Crash Prevantion - 8. Rebuild or Refactor? - System Refactoring - 9. Micro-Frontend Implementation Approaches Comparison - 10. Technology Selection - Determining Technology Stack - 11. Creating Project Architecture Diagrams

I. Architecture Fundamentals

1. Software Design Principles

* Single Responsibility Principle
    - A class should never have more than one reason to change
    - Understanding: A class should have only one responsibility that would cause it to change
    - Application: If a class has multiple responsibilities, it should be split into multiple classes
* Open-Closed Principle
    - Software entities should be open for extension, but closed for modification
    - Understanding: Open for extension, closed for modification. Extend classes rather than modifying them
    - Application: When requirements change, use inheritance or composition to extend functionality rather than modifying existing code
* Liskov Substitution Principle
    - Understanding: Parent classes must be replaceable by their subclasses
* Principle of Least Knowledge
    - Only communicate with your immediate neighbors
    - Understanding: Low coupling, high cohesion
    - Application: Minimize dependencies when designing systems
* Interface Segregation Principle
    - Depend on small, specific interfaces rather on large, general ones
    - Understanding: Don't expose interfaces that aren't needed. Users shouldn't depend on interfaces they don't use
    - Application: When exposing interfaces, remove any that aren't necessary
* Dependency Inversion Principle
    - High-level modules should not depend on low-level modules; both should depend on abstractions. Abstractions should not depend on details; details should depend on abstractions
    - Understanding: Program to interfaces, not implementations
    - Note: Not every class needs an interface, but when interfaces exist, prefer using them for programming
* Summary
    - The first letters of these six principles spell SOLID (stable), hence known as SOLID principles
    - Only by following these six principles can we design stable software architectures

2. Additional Design Principles

* Composition/Aggregation Reuse Principle
    - When extending functionality, prefer composition over inheritance
    - This principle is frequently used in the 23 classic design patterns
    - Examples: Proxy pattern, Decorator pattern, Adapter pattern, etc.
* Acyclic Dependencies Principle
    - When module A depends on module B, module B depends on module C, and module C depends on module A, a circular dependency occurs
    - Avoid this in design by introducing a "mediator pattern"
* Common Closure Principle
    - Classes that change together should be packaged together
    - This principle extends the Open-Closed Principle
* Common Reuse Principle
    - If you reuse one class from a package, you reuse all classes from that package; minimize package size
* Hollywood Principle
    - "Don't call us, we'll call you"
    - "Inversion of Control" (or "Dependency Injection")
    - Objects are created and managed by a container rather than being instantiated directly

3. Other Design Principles

* Don't Repeat Yourself (DRY)
    - Avoid duplicating code; make it reusable through proper encapsulation
* Keep It Simple, Stupid (KISS)
    - Maintain simple interfaces, practical functionality, and user-friendly operations
* High Cohesion and Low Coupling
    - Modules should have high internal cohesion and low external coupling
* Separation of Concerns
    - Break complex problems into simpler ones and solve them individually
    - Challenge: How to effectively separate concerns
* You Aren't Gonna Need It (YAGNI)
    - Don't over-engineer systems from the start
    - Keep systems simple while maintaining extensibility

4. Software Design Layering

* Architecture Types
    - System-level architecture
    - Code-level architecture
    - Module-level architecture
    - Application-level architecture
* System-level Architecture
    - How the application interacts with backend services and third-party systems
    - Primary consideration for frontend design: Understanding relationships between frontend systems and other systems
    - Relationships include: business relationships and collaboration mechanisms
    - Backend design focuses on data transmission mechanisms
    - Includes: API design rules, authentication standards (OAuth), token validation, data passing via cookies
    - Frontend-backend relationship considerations primarily focus on: separation of concerns architecture design
    - Frontend-backend separation involves technical decisions about user authentication, API management and design, API documentation, Mock usage, BFF (Backend for Frontend), server-side rendering needs
* Micro-Frontends
    - Within a single system, micro-frontends are an inter-application architecture solution
    - Across multiple applications, micro-frontends represent an inter-system architecture solution
    - Micro-frontends combine multiple frontend applications in some unified manner
    - They aim to solve the maintainability issues that arise when monolithic applications evolve into "frontend monoliths" over time due to increasing team size and personnel changes
    - Single-instance: Only one child application is displayed at a time, with a complete application lifecycle
    - Multi-instance: Child application switching based on URL changes
    - Multi-instance: Multiple child applications can be displayed simultaneously
    - Web Components are typically used for child application encapsulation, making child applications more like business components than standalone applications
* Application-level Architecture
    - Application-level architecture can be seen as a refinement of system-level architecture
    - Relationships between individual applications and external systems, collaboration between multiple applications in microservices architecture, data exchange, etc.
    - Includes scaffolding, pattern libraries, and design systems
* Module-level Architecture
    - This content is designed before business coding begins, referred to as iteration
* Code-level Architecture
    - Standards and principles
* Practical Implementation
    - Development processes
    - Code quality and improvement
    - Standards over implicit understanding
* Note:
    - In development, maintainability is crucial
    - Simple code is more maintainable; the more abstract the code, the harder it is to maintain

5. Ensuring Architecture Quality - Stability and Robustness

* System Stability
    - Definition: When a real system is in equilibrium, if affected by external forces, the system can return to its original equilibrium state after a transition period; such a system is stable
    - Cornerstone of architectural design
    - Enables better self-healing capabilities
* System Robustness
    - Definition: A robust software system continues to function without crashing or freezing when faced with erroneous inputs, disk failures, network overload, or malicious attacks
    - Explanation: A system with strong fault tolerance, resistance to interference, and good security
* Metrics for System Robustness
    - Software can infer correct input from erroneous input
    - Software can operate correctly in different environments
    - Software can detect internal design or coding errors and produce correct results
* System Robustness and Stability
    - Robustness and stability are specific requirements for software systems
    - They are part of software processing capabilities
    - Software architecture robustness and stability are goals established during planning
    - If implementation fails to meet original goals, the software's robustness and stability are inadequate
* Architecture Quality Metrics
    - Scalability
    - Maintainability
    - Manageability
    - High availability (fault recovery, disaster recovery, degradation, circuit breaking)
* Daily Development Architecture Quality
    - Comprehension difficulty
    - Dependency integration cost
    - Crash rate and error rate metrics
    - Development efficiency
    - Error reporting and information collection features

6. The Right Foundation - Architecture Preparation

* Architect Categories
    - System Architect
    - Application Architect
    - Business Architect
* System Architect
    - Responsible for overall system architecture design from a system perspective
    - Focuses on basic services and system coordination, with a global view
    - Concerns include load balancing, reliability, scalability, expansion, basic infrastructure design for project partitioning, caching, etc.
* Application Architect
    - Responsible for technical architecture of specific applications from an application perspective
    - Primarily focuses on business systems
    - Concerns include understanding business requirements, modeling, design patterns, interfaces, data interaction, etc.
* Business Architect
    - Focuses on industry-specific business processes from a business perspective
    - Analyzes domains to obtain domain models and ultimately system models
    - Also known as business domain experts, industry experts, product consultants, or senior advisors
* Technical Preparation
    - Technology selection: Research and reports on community ecosystem, development scale, future trends, alignment with current team, implementation costs, maintenance and migration costs, performance efficiency, etc.
    - Thoroughly investigate pros and cons of each technology
    - Predict architectural design flaws to prevent problems
* Technical Optimization
    - During architecture evolution, implementations that contradict current architecture design may emerge, causing architectural bottlenecks
    - Architecture optimization is needed to increase adaptability
* Architecture Optimization
    - Architecture is not static; it evolves with business development
    - Continuously tune architecture design to make optimization a regular practice
    - Improve initial architecture design shortcomings by adjusting implementations and addressing weaknesses

7. Small Issues, Big Problems - Technical Debt Management and Crash Prevention

* Technical Debt - Issue 1
    - Suboptimal implementations due to time constraints during development
    - Example: Finding prime numbers below 10,000
    - Loop approach vs. sieve method
* Technical Debt - Issue 2
    - Compromised implementations when better solutions aren't immediately apparent
    - Started with if-else implementation
    - Evolved to using chain of responsibility pattern
* Technical Debt - Issue 3
    - Details not considered in initial architecture design
    - Interaction details -> parameter passing via props (interaction redundancy, lengthy process)
    - Implemented using global state management for parameter passing
* Technical Debt - Issue 4
    - Poor interaction design leading to complex technical implementations
* Technical Debt - Issue 5
    - Missing documentation for old features, making extension, modification, and compatibility difficult, leading to increased post-launch issues
* Technical Debt - Consequence 1
    - Fixes become refactoring
    - Unaddressed small technical debts eventually lead to large-scale refactoring, resulting in low productivity
* Technical Debt - Consequence 2
    - Development speed is affected
    - Technical debt requires accommodating too many compatibility points, affecting development efficiency
    - Significantly slows down launch speed, causing overall project iteration to lag and losing competitive advantage
* Technical Debt - Consequence 3
    - Easy to fall into a vicious cycle of maintaining old features -> developing new features -> maintaining compatibility with old features
* Technical Debt - Solution 1
    - Excellent architecture design is fundamental
    - Must effectively handle foreseeable requirements; for unknown scenarios, small changes should solve problems
    - Reasonable project partitioning based on current business, maximizing code decoupling
    - Must include logging modules for operations, errors, business activities, etc.
* Technical Debt - Solution 2
    - Effective technical training and mentorship
    - Enable every developer to understand their implemented functionality at a deeper level
    - From code standards to business familiarity to documentation
* Technical Debt - Solution 3
    - Comprehensive technical plans can prevent some technical debt
    - Technical plans represent the ideal implementation approach after fully understanding requirements, making them essential
* Technical Debt - Solution 4
    - Code review among engineers
    - Code review is crucial and also improves personal skills
* Technical Debt - Solution 5
    - Increase awareness of the importance of addressing technical debt
    - Engineers will naturally spend time resolving issues when they foresee potential problems
* Technical Debt - Solution 6
    - Proactively identify and regularly address technical debt
    - Be brave enough to identify technical debt in systems and take responsibility
* Summary
    - After product launch, development pressure eases; this is the time to address technical debt, improving relationships while reviewing original code—a challenging but valuable experience
* Crash Prevention
    - Architectural crashes are serious design incidents that require prevention
    - 1. Causes of system crashes
    - 2. Logging (operation logs, error logs, business logs)
* Crash Prevention Strategies
    - User behavior tracking -> capture user operation chains at the earliest opportunity
    - Address existing issues -> technical debt
    - Prevent new issues -> reduce probability of new problems
    - Implement safeguards and validation for dirty data
    - Unit testing
    - Crash alerts
    - Automated testing
    - Broader gray-scale deployment
    - Performance optimization system

8. Rebuild or Refactor? - System Refactoring

* Architecture is not permanent. It has a lifecycle: birth, development, peak, decline, and eventual demise
* What is Refactoring?
    - A change to the internal structure of software
    - Purpose: Improve understandability and reduce modification costs without changing observable behavior
* Implementation Method
    - Use a series of refactoring techniques to adjust structure while maintaining observable behavior
* Refactoring Philosophy
    - Use numerous small steps that maintain software behavior to achieve large-scale changes
* Early System Advantages
    - 1. Fast development speed
    - 2. Low code complexity
    - 3. Well-maintained code standards
    - 4. Strict adherence to development standards, preventing architecture-threatening code
    - 5. Above factors make adding features easy and low-cost
* Late System Disadvantages
    - Has all early system disadvantages
    - 1. High code complexity
    - 2. Incomplete code standards
    - 3. Many features or requirements exceed architecture design
    - 4. Adding new features requires considering multiple modules, affecting the entire system
* When to Refactor
    - When an existing architecture can no longer meet current iteration speed, refactoring is needed
* Micro-refactoring
    - Apply micro-refactoring techniques to code with "bad smells"
        ~ Identify problem points and define refactoring scope
        ~ Review old architecture and logic
        ~ Ensure stability
        ~ Ensure performance
        ~ Address conflicts during requirements

9. Micro-Frontend Implementation Approaches Comparison

* 1. Iframe - Advantages
    - Mature technology
    - Supports page embedding
    - Natural sandbox isolation and independent operation
* 1. Iframe - Disadvantages
    - Can support different domains between pages
    - Requires designing application communication mechanisms (monitoring, parameter formats, etc.)
    - Implementation of application loading, rendering, caching systems
* 2. Web Components - Advantages
    - Supports custom elements
    - Supports shadow DOM with associated control
    - Supports templates and slots for custom component content
* 2. Web Components - Disadvantages
    - Requires rewriting current projects to adopt micro-frontends
    - Immature ecosystem, compatibility issues with newer technologies
    - Complex overall architecture design; overly fine-grained component splitting can lead to cumbersome communication and control
* 3. Custom Framework - Advantages
    - Highly customizable for all compatibility scenarios
    - Independent communication mechanisms and sandbox environments solve cross-application interference
    - Supports different technology stacks in child applications, enabling seamless page rendering without refresh
* 3. Custom Framework - Disadvantages
    - High technical implementation complexity
    - Requires designing custom communication mechanisms
    - Initial loading may result in excessive resource usage
* 4. Final Implementation - Custom Framework
    - Route distribution approach
    - Main application controls route matching and child application loading, sharing dependency loading
    - Child applications handle functionality and integrate with main application for control and interaction

10. Technology Selection - Determining Technology Stack

* Applications
    - Main application
    - Child applications
    - Backend services and deployment applications
* Main Application - Vue3 Technology Stack Selected
    - Vue2
    - Vue3
    - React
* Main Application Options
    - Angular
    - jQuery
    - Native JavaScript
* Vue2 Child Application
    - Implements new energy vehicle pages
* Vue3 Child Applications
    - Homepage
    - Car selection
* React15 Child Applications
    - News
    - Videos
    - Video details
* React16 Child Applications
    - New cars
    - Rankings
    - Login
* Server-side Interfaces
    - Koa implementation
* Deployment Application
    - Express

11. Creating Project Architecture Diagrams

* Requirements Analysis
    - Main and child application functionality
    - Framework functionality
* 1. Main Application
    - Register child applications
    - Load and render child applications
    - Route matching (activeWhen, rules - determined by framework)
    - Data acquisition (common dependencies, used for authentication)
    - Communication (parent-child, child-parent)
* 2. Child Application Functionality
    - Rendering
    - Communication monitoring (data passed from main application)
* 3. Micro-Frontend Framework
    - Child application registration
    - Start content (application loading complete)
    - Route update detection
    - Match corresponding child application
    - Load child application content
    - Execute all dependencies
    - Render child application in designated container
    - Common event management
    - Exception capture and error reporting
    - Global state management
    - Sandbox isolation
    - Communication mechanism
* 4. Server-side Functionality
    - Provide data services
* 5. Deployment Platform
    - Packaging and deployment of main and child applications