Defining Platforms, Systems, and Modules in FinTech Architecture

01 Platform

In the financial‑technology domain, a “platform” refers to a foundational environment or framework that defines a specific business domain, provides common capabilities, and enforces standard technical specifications.

All systems and modules built on a platform share the same technical standards and can rapidly iterate using the platform’s base services.

Domain scope – e.g., an e‑commerce platform is limited to the “e‑commerce” domain.

Technical standards – data‑processing platforms, AI platforms, and traditional Java stacks each have distinct standards.

Common base services – platforms typically expose services such as merchant, payment, shopping‑cart, and logistics APIs for downstream applications.

02 System and Module

A “system” is a generic term that can describe anything from an ecosystem to a human circulatory system. In fintech, regulators such as the People’s Bank of China treat “systems” as units for compliance requirements.

System: a group of interrelated entities operating under rules to accomplish tasks that individual components cannot achieve alone – Wikipedia.

For our purposes, a system is defined as a collection of one or more related modules that cooperate according to business rules to deliver a product or service.

Modules are the concrete, deployable units within a system. They represent a cohesive set of business capabilities within a bounded context, independent of implementation technology. In a micro‑service architecture, a module may be further split into “service units,” each with its own codebase, such as front‑end gateways, batch jobs, or business services.

03 Framework, Component, Artifact, Plugin, Control, Middleware

Beyond platform, system, and module, technical architecture distinguishes several reusable building blocks:

Framework – an application skeleton that encapsulates reusable technical features and requires developers to conform to its standards (e.g., Spring).

Component – a logical functional unit that encapsulates domain functionality (e.g., logging component, ORM component).

Artifact – a tangible build output produced during the software lifecycle, such as a *.jar file.

Plugin – a minimal functional extension that cannot run independently and must be assembled by a framework.

Control – a visual UI element used in front‑end development.

Middleware – independently deployable services that connect application‑level systems to the operating system (e.g., Tomcat).

Component vs. Artifact

Although the Chinese terms “组件” (component) and “构件” (artifact) are often confused, they serve different purposes:

When discussing design, functionality, interfaces, and reuse, we refer to components .

When discussing packaging, deployment, versioning, and concrete files, we refer to artifacts .

Key distinctions:

Core concept : Component = functional unit (what it does); Artifact = build output (what it is).

English focus : Component (design view) vs. Building Block / Artifact (build/deploy view).

Nature : Component is logical and functional; Artifact is physical or logical product.

Concern : Component emphasizes interfaces, behavior, reuse; Artifact emphasizes composition, deployment, version management.

Granularity : Component can vary from small functions to subsystems; Artifact is typically a concrete deployable unit such as a file or package.

Primary context : Component appears in software design and architecture; Artifact appears in build, configuration, and deployment processes.