Enterprise Core Architecture Design: 4 Case Studies & Layered Derivation Method

Chapter Overview

A rich architecture diagram often loses communication value by trying to answer too many questions at once. This chapter uses four case studies—a messaging platform, a fund collection/payment platform, a business monitoring system, and a regulatory data reporting system—to show a consistent layered derivation: first identify participants and business capabilities, then divide service responsibilities and interactions, finally realize deployment, storage, state management, and exception handling. These four systems emphasize platformization, multi-channel adaptation, high-reliability transactions, monitoring closed-loop, and batch data pipelines, validating the architecture principles from the previous 12 chapters.

Key Knowledge Breakdown

13.1 Messaging System: From Common Capability to SaaS Platform

The messaging platform unifies SMS, email, App push, and in-app messages into a multi-tenant service. The functional architecture splits into a common layer (merchant, application, address book, blocklist, alerting), a business service layer (channel-specific templates and sending capabilities), and an open layer (management UI and APIs).

Technically, SMS can be further decomposed into management, open interface, batch processing, and sending services. All entry points route through a message queue to concentrate sending responsibility on scalable consumers, avoiding direct carrier adaptation per service. Core data models comprise merchant, application, signature, template, authorization, and send records.

The platform must handle data privacy, massive send records, and open-interface capacity. Message content retention is policy-controlled; historical data is archived; real-time verification codes and ordinary batch messages require resource isolation.

13.2 Fund Collection/Payment System: Centered on State Certainty

The fund system integrates third-party payment or bank channels. Functional modules include merchant, payment channel, fund collection/payment, account, scheduling, reconciliation, management, and open interfaces. The payment channel service handles protocol, dictionary, and message adaptation so core fund services do not couple directly to each bank's differences.

A single payment may synchronously return success, failure, or processing. The processing state relies on bank callbacks complemented by active polling until a final result is obtained. Batch collection/payment can use batch messages or file transfer combined with notification interfaces. Deduction requires prior authorization signing; daily reconciliation discovers discrepancies between parties.

The fund system must prevent duplicate transactions, preserve complete state transitions, and monitor unknown states, lost callbacks, reconciliation differences, and channel anomalies. Real-time and batch services, as well as different channel services, should be deployed in isolation for fault isolation and on-demand scaling.

13.3 Business Monitoring System: From Alerting to Incident Handling

Business systems report anomalies via monitoring point codes. The monitoring interface service persists synchronously and returns an event ID, then asynchronously hands off to a trigger service. The trigger service sends messages or creates tickets based on monitoring definition, level, recipient group, and trigger method.

Monitoring definitions, personnel groups, trigger methods, and event records are kept separate, making rules configurable and events statistically analyzable. Dashboards should rely on pre-aggregation or real-time computation to avoid repeated full aggregation on massive raw events.

13.4 Regulatory Reporting System: Traceable Data Pipeline

The reporting process covers collection, processing, validation, reporting, and receipt. Data flows from a source layer (preserving original structure) through an intermediate processing layer to a reporting layer that matches regulatory calibers. A subject/model layer may sit atop the source layer, providing stable, understandable common business data for multiple reporting systems.

Different regulators vary greatly in calibers and interaction modes, so intermediate and reporting layers usually cannot be forced to share. Collection, scheduling, validation frameworks, and transport capabilities can be reused while each reporting domain retains its own rules and data models. Massive files are pre-sharded, packaged in parallel by multiple nodes, then aggregated for reporting.

Receipts drive subsequent actions: data content errors route back to processing or validation; scope omissions route back to collection. The entire chain must retain batch ID, source, rule version, and file checksums to guarantee traceability for supplementary and re-reporting.

Architecture Diagram Explanations

General Derivation Method

Fund Transaction State Closure

Regulatory Data Pipeline

These three diagrams represent the universal design process, fund state certainty, and regulatory data closed-loop, covering the chapter's most important architectural relationships.

Personal Learning Insights

The final chapter's cases—messaging, fund, monitoring, regulatory reporting—differ from my work domain. The transferable element is not business details but the author's layered problem-unfolding method: first capabilities and participants, then service responsibilities, data states, deployment structure, and exception flows.

This reinforces that a single "big and comprehensive" architecture diagram cannot solve communication problems. Product owners care about requirement-to-release closure; developers care about services and interfaces; operations care about deployment and failures; auditors care about who released which artifact when. Different questions need different views; cramming everything into one diagram only obscures clarity.

I distilled four checkpoint questions: Is responsibility clear? Is state visible? Can failures be recovered? Is the process traceable? They are not conclusions but starting points for continued solution review. No matter how polished the documentation, it must still be corrected by stress tests, drills, and operational records.

Practical Implementation Considerations

Work Object: A Complete Delivery Chain

The internal DevOps platform I participate in covers the process from requirement to production release. The diagram below describes the platform's work objects: requirements linked to code changes, pipelines completing build and test, artifacts entering version management, release orders linking approvals and target environments, deployment leading to verification or recovery flows. It is a system boundary diagram, not a record of a specific incident handled exactly as shown.

Whether this chain is fully connected, which links remain manual, and how real failures recover must be judged against the platform's current state and operational records. The design goal is certain: requirements, commits, pipelines, artifacts, approvals, environments, and verification results need traceable relationships. A real public-account case would further supplement trigger events, judgment divergences, and final outcomes from an actual release.

Generic Architecture Deliverables

Requirements & Constraints: participants, business goals, scale, timeliness, compliance, failure impact.

Functional Architecture: capability layering, common capabilities, domain capabilities, external participants.

Service Relationships: each service's responsibility, protocol, synchronous/asynchronous dependencies, data ownership.

Technical & Deployment: instances, network zones, clusters, storage, middleware, disaster recovery.

Data Design: core entities, state machines, unique keys, versioning, audit, archival.

Process Design: normal path, timeouts, retries, callbacks, compensation, reconciliation, human intervention.

Non-functional Proof: capacity planning, SLOs, security controls, monitoring metrics, drill plans.

Case Implementation Focus

Messaging Platform: tenant isolation, template authorization, priority, receipt, privacy, cost.

Fund Platform: idempotency, unknown state convergence, signing, channel isolation, reconciliation, full-chain audit.

Monitoring Platform: unified event model, responsibility routing, alert noise reduction, ticket closure, trend analysis.

Reporting Platform: data lineage, rule versioning, batch tracking, receipt-driven reprocessing, result archival.

Final Self-Check

For each core process, continuously ask: What if a dependency times out? What if a request is duplicated? How long is a processing state acceptable? How is data inconsistency discovered? Who is responsible? Can we replay or compensate? Can we explain after the fact? Clear answers move a solution from a "structure diagram" to a runnable architecture.