Back to work
04 / 04MODULAR BACKEND

Campaign Engine

A modular backend for securities marketing campaigns

Campaign configuration, registered feature modules, a shared Action/View API and rules compose capabilities across campaigns while keeping published interfaces stable.

Development practice: AI agents drove much of the implementation, while API contracts, campaign isolation, and regression checks guided each iteration.

Modular execution pathConcept visual · based on actual product capabilities

The context

Stable protocols and composable capabilities let campaigns evolve independently.

When multiple campaigns evolve in parallel, each needs clear configuration and a reliable execution path without disrupting published activities.

What we built

Campaign configuration, registered features, and a shared Action/View API organize runtime capabilities. Domain events, rules, and state projections handle business change.

01 / CONFIGURATION

A campaign begins by declaring capabilities

Configuration defines identity, feature modules, Actions, Views, quotas and rules. Registered Features own their resources; a new campaign first composes existing capabilities, then adds bounded extensions where needed.

  • Declarative campaign configuration
  • Registered Features and explicit references
  • Composition across campaigns
CAMPAIGN / CONFIGURATION YAML + FEATURE
campaign.yamlCampaign config
feature registryRegistered Feature
Action / View bindingsRules / quotas

Declare capabilities instead of copying flows.

Concept visual · based on actual product capabilities
02 / EXECUTION

Behavior becomes events, rules and state

Action is the shared write entry point. It produces domain events; Rules invoke Guards and Effects before state changes. Views project stable read contracts. Idempotency protects business actions on retry.

  • Shared Action / View protocol
  • Domain Event → Rule → State Projection
  • Idempotent transactional execution
CAMPAIGN / EXECUTION ONE CONTRACT
01Action write API
02Domain Event
03Guard / Effect
04State Projection
05View read API

Transactions and idempotency protect every change.

Concept visual · based on actual product capabilities
03 / OPERATIONS

Controlled operations after launch

A separate Ops control plane handles campaign availability and declared product, reward-link and schedule data. Validation and formal revisions make changes effective without redefining published APIs.

  • Campaign lifecycle controls
  • Product and reward operations
  • Validation and revision boundaries
CAMPAIGN / OPERATIONS CONTROL PLANE
Operations planeONLINE
↗Online / offline
↗Product collections
↗Reward links
↗Schedules
Validate → publish revision
Concept visual · based on actual product capabilities

Architecture diagrams reflect actual system capabilities and contain no client or production data.

Next projectMarket Data Hub

LET'S BUILD WHAT'S NEXT

Let's turn a good ideainto a real product.

Planning a website, mobile app, mini program, or custom system? Tell us about your goals, timeline, and what you already have.

op@baicl.com