Mastering Logical Architecture: Constraints, Reuse, and Layering Explained

5 Architecture Basic Constraints

Logical architecture constraints are divided into basic constraints and business constraints. Basic constraints include software design principles, responsibility constraints for modules and sub‑modules, and non‑functional constraints such as stability, performance, and cost.

5.1 Common Software Design Principles

Single Responsibility Principle (SRP)

Open/Closed Principle (OCP)

Liskov Substitution Principle

Dependency Inversion Principle (DIP)

Interface Segregation Principle (ISP)

Composition‑Aggregation‑Reuse Principle (CARP)

Law of Demeter (LoD)

These principles serve as the judgment standards, and design patterns are the methods to implement them.

5.2 Common Design Patterns

Design patterns bridge the gap between principles and implementation, especially in logical architecture where the focus is on how modules interact to satisfy the principles.

5.3 About Modules

Using design patterns to align module integration with design principles reduces maintenance and extension costs. Both business‑related and non‑business‑related modules must respect these constraints.

5.4 Technical Constraints in Specific Scenarios

Web development constraints such as duplicate submissions, transactions, and versioning.

MySQL constraints in high‑concurrency scenarios (sharding, indexing, etc.).

High‑concurrency system constraints (idempotency, caching, threading, lock granularity, remote calls).

Other physical‑architecture constraints.

5.5 Business Attribute Constraints in Logical Architecture

High‑level modules derive constraints from core business concepts (e.g., orders, marketing activities, products) to form unified technical business constraints.

5.6 Constraints Summary

Constraints exist at both logical and physical levels; understanding them is essential for effective architecture evolution.

6 Logical Architecture Reuse

6.1 Reuse Benefits

Improved development efficiency

Reduced R&D cost

Higher software quality

Other benefits

6.2 Abstraction and Extraction

Abstraction starts from similar models, processes, or data structures, leading to reusable modules through design patterns and domain modeling.

6.3 Reuse Summary

Reuse combines abstraction techniques with deep business understanding; organizational factors may affect its practicality.

7 Logical Architecture Layering

7.1 Layer Classification

Engineering skeleton layering (presentation, business, data) differs from logical architecture layering, which focuses on module responsibilities and dependencies rather than code organization.

7.2 Layering Cases

Examples include file system and network protocol stacks, where each layer solves distinct problems and depends on lower layers.

7.3 Domain‑Modeling Layering

Books often mix service/domain/repository layers with logical architecture, but the latter should remain independent of implementation details.

8 Granularity of Logical Architecture

8.1 Granularity Tree

A granularity tree visualizes modules at different levels (basic components → modules → final system), guiding abstraction and decomposition.

8.2 Granularity Implementation

Modules may materialize as sub‑packages, top‑level packages, applications, or platform services, depending on complexity and team size.

8.3 Mid‑Platform Concept

Mid‑platforms abstract stable core business concepts (models, processes, algorithms) to enable rapid front‑end iteration.

8.4 Considerations for Module Realization

Team efficiency (optimal team size per module)

Stability (strong vs. weak dependencies, core separation)

Performance (QPS, latency, threading, network optimization)

9 Full Summary

The article defines architecture, distinguishes product, business, logical, and physical architectures, emphasizes the need for proper analysis (bottom‑up) and design (top‑down), and highlights continuous iteration as the key to sustainable architecture.

PS: The author acknowledges possible omissions and invites feedback.