How to Design Scalable Engineering Architecture: From Value‑First to DDD

Introduction

Architecture design can be divided into engineering, business, deployment, and other dimensions. A good system architecture should be scalable, maintainable, reliable, secure, and high‑performance. While these qualities are well known, the article focuses on the key paths to achieve them, especially in engineering architecture.

Value First

When a solution is ambiguous, evaluating it from a product (business) value perspective is crucial. Two common technical traps are "accept everything" and "technology‑driven" approaches, which can lead to misaligned product value and disruptive technical iterations. Prioritizing product value helps teams reach consensus and plan for business evolution.

Architecture Design

Architecture patterns describe component relationships, responsibilities, and interactions, improving development efficiency. They help developers organize software and facilitate team collaboration.

3.1 Engineering Framework

New systems start with an engineering foundation: directory structure, configuration files, code templates, etc., to standardize project structure, responsibilities, and code style, thereby improving code quality and maintainability.

Define module dependencies and interaction methods.

Standardize interface protocols.

Unify exception codes, capture, and handling.

Standardize log formats.

Other common constraints.

Common layered and DDD architectures are introduced next.

3.1.1 Layered Architecture

Layered architectures (e.g., MVC, Hexagonal) evolved with business and technical growth. Early web applications mixed HTML, JavaScript, CSS, and SQL in scripts like JSP, leading to complexity, security issues, and limited extensibility. Frameworks such as Spring and Struts introduced the MVC pattern to separate concerns, improve maintainability, and enhance extensibility.

Typical benefits of layered architecture include:

Separation of concerns.

Improved maintainability.

Better extensibility.

However, MVC can increase learning curve, complexity, and development time. Modern development often splits work among front‑end, back‑end, testing, and operations roles.

Through horizontal layering, teams achieve clear division of responsibilities.

3.1.2 DDD Architecture

Domain‑Driven Design (DDD) centers on the business domain, encapsulating logic in domain models to improve maintainability, scalability, and reusability. DDD layers include:

User Interface Layer: handles web, RPC, MQ requests.

Application Layer: orchestrates, forwards, validates.

Domain Layer: expresses business concepts, rules, entities, value objects, aggregates, services, events, repositories, factories.

Infrastructure Layer: provides persistence, messaging, utilities, configuration.

DDD excels in complex business scenarios, supporting independent sub‑domains, rapid iteration, and high maintainability. However, it requires deep domain knowledge, cross‑department collaboration, and higher technical expertise.

3.2 Technology Selection

Beyond the base framework, selecting middleware and technologies is vital. Considerations include business requirements, technical characteristics, community support, team skills, cost‑benefit, and risk assessment.

3.2.1 Business Requirements

Identify functional, performance, security, and future expansion needs. Example: decide whether to split a system into WEB + microservice modules based on reuse and resource isolation.

3.2.2 Technical Characteristics

Evaluate availability, performance, security, scalability, and maintainability. Example: an embedded object database offers simplicity but lacks clustering support.

3.2.3 Community Support

Prefer technologies with active communities, documentation, and mature third‑party libraries.

3.2.4 Team Skills

Match technology complexity to team expertise to avoid high maintenance costs.

3.2.5 Cost‑Benefit

Reuse existing open‑source plugins when possible and consider migration costs for legacy systems.

3.2.6 Risk Assessment

Account for maturity, security vulnerabilities, and dependency risks (e.g., Fastjson security issues).

3.2.7 Summary

Choose solutions based on overall fit rather than chasing the newest hype.

Standard Consensus

Establishing shared standards improves communication, reduces duplication, and enhances development efficiency.

4.1 Data Layering

Use anti‑corruption designs to keep layers loosely coupled. Common data objects:

VO (View Object) – for UI display.

DTO (Data Transfer Object) – for remote calls.

DO (Domain Object) – business entities.

PO (Persistent Object) – database mapping.

4.2 Exception Management

Capture exceptions where needed to allow process continuation or rapid problem detection. Strategies include localized try‑catch for flow control and centralized handling for debugging.

4.3 Log Management

Adopt a unified logging framework (e.g., SLF4J with Log4j2 or Logback), configure formats, levels, rotation, and optional forwarding to analysis systems.

4.4 Monitoring Management

Monitor system performance, logs, security, business metrics, and trace request call chains using tools like Nagios, ELK, Prometheus, Grafana, Zipkin, etc., with alerting channels.

4.5 Collaboration Consensus

Discuss practical dilemmas such as HTTP GET length limits and front‑end vs. back‑end logic responsibilities, weighing short‑term fixes against long‑term maintainability.

Conclusion

The article details key considerations for building engineering architecture, from value‑first decisions to layered and DDD designs, technology selection, and operational best practices. It emphasizes balancing product value, technical feasibility, and team capabilities to achieve scalable, maintainable backend systems.