System Context
This project concerns the modernization of Comers, a proprietary online sales management platform available at comers.app, designed and continuously developed by our team for approximately 10 years.
The system was originally built as an internal operational platform supporting a network of online stores operating across multiple European Union countries.
Comers serves as a centralized sales and integration system, enabling:
- integration of multiple online stores,
- integration with marketplaces (e.g. Amazon, eBay),
- full order lifecycle management,
- carrier integrations and shipping operations,
- inventory and warehouse management,
- returns handling,
- service and warranty workflows,
- product listing management,
- invoice generation,
- operational reporting and analytics.
Comers is multi-organization by design. Within a single instance, multiple organizations can operate independently, each with:
- its own sales integrations,
- its own operational configuration,
- its own user structure and permissions.
Within each organization, users operate under different operational roles and access levels.
The platform also automatically sends transactional and operational emails to customers and staff, acting as a central communication hub.
Why a Monolith Was the Right Decision 10 Years Ago
At the time the system was designed:
- microservices architecture was not yet an operational standard for mid-scale platforms,
- container orchestration infrastructure was not widely adopted,
- delivery speed and operational stability were primary goals,
- the operations team needed one cohesive system to manage sales workflows.
Building a modular monolith was a deliberate architectural decision:
- one deployable artifact,
- one shared runtime environment,
- one relational database,
- a simplified deployment model,
- full control over operational flows.
Over the years, that approach proved its business value.
The system was not an experiment. It was a real operational tool supporting sales and logistics at scale.
Why Modernization Is Necessary Today
After a decade of growth, the system reached a natural architectural inflection point.
1. Growing integration density
The platform integrates with:
- online stores,
- marketplaces,
- carriers,
- invoicing systems,
- communication mechanisms.
Over time, integration logic became significantly denser in key domain areas.
Formalizing boundaries became necessary in order to:
- reduce blast radius,
- improve separation of responsibilities,
- enable independent evolution of high-I/O areas.
2. Shared runtime across multiple execution contexts
The system handles:
- interactive HTTP requests,
- batch operations,
- scheduled scripts (cron),
- queue processing.
All of those execution paths use the same application runtime.
Historically, that model was operationally efficient, but it now limits flexibility and scalability.
3. Need for a clear frontend boundary
Originally, the system functioned as a server-rendered operational interface.
Current requirements include:
- introducing a SPA layer,
- separating frontend contracts from domain models,
- establishing a Backend-for-Frontend (BFF) layer.
The BFF is treated as a core part of the architecture, not merely an HTTP adapter.
Transformation Strategy
The modernization effort is being led by the same team that designed and evolved the platform over the past decade.
The approach is evolutionary, not revolutionary.
Phase 1: Boundary formalization
- separating orchestration from state transitions,
- isolating integration adapters,
- introducing explicit contracts between layers.
The priority is structural clarity before physical service extraction.
Phase 2: Extraction of high-I/O domains
Selected domain areas will be extracted into independent services.
Extraction order is based on:
- integration density,
- orchestration complexity,
- change risk and operational impact.
This is the beginning of the move toward a microservices architecture.
Phase 3: Introduction of the BFF layer
Before full SPA migration:
- existing JSON endpoints are being formalized as contract boundaries,
- the BFF layer takes responsibility for response shaping,
- frontend development becomes decoupled from internal domain structures.
Phase 4: Transformation toward a microservices architecture
The target architecture includes:
- domain-oriented independent services,
- dedicated execution contexts,
- separation of batch processing from interactive flows,
- the ability to scale independently.
The transformation is being carried out under live production conditions.
Phase 5: Operational AI support
Over the long term, the system will be extended with an AI-assisted decision-support layer.
AI will:
- operate exclusively on explicit contracts,
- generate recommendations and summaries,
- support operational decisions,
- remain an augmentation layer rather than an execution authority.
Key Architectural Decisions
- Modernization while the production system remains active.
- Operational continuity is more important than fast, radical refactoring.
- Boundaries are defined before runtime isolation.
- Extraction order is based on integration density, not folder structure.
- Contracts are established early, before service-level separation.
Modernization Progress (Real Changes)
Modernization is not limited to plans or architectural direction. Key parts of the transformation have already been implemented and are running in the live system.
Work completed so far includes:
- building new domain modules (
ebay,messages,listings,shipping,notifications), - rebuilding the eBay integration (Trading API + REST API) using ports and adapters,
- introducing a message-thread communication model with a dedicated interface,
- extracting the listings module with its own API and ingestion pipeline,
- restructuring carrier integrations (DPD, DHL) into a shared shipping layer,
- introducing a notifications module with its own API and UI,
- adding explicit contracts (ports) and adapters in key areas of the system,
- applying a raw-first ingestion model with reprocessing support,
- moving artifacts (e.g. labels) to object storage as part of a stateless model,
- stabilizing job runtime behavior (DB locks, timeouts, concurrency control),
- cleaning up runtime environment and configuration management (env-based),
- introducing CI/CD pipelines and preparing for containerization,
- refreshing selected parts of the user interface.
Selected Comers platform views
UI screenshots from Comers (comers.app) are shown with anonymized data; any visible branding is limited to the Comers product identity.
Full technical change log:
👉 Architecture evolution and modernization log
Current State
The system remains fully operational.
Modernization is incremental:
- boundaries are being formalized,
- contracts are being strengthened,
- new modules with explicit boundaries are being developed,
- additional extraction candidates are being prepared.
Some of the key transformation elements have already been implemented and are described in the section above.
Current Outcome
The project demonstrates:
- responsible modernization of a production system,
- architectural evolution without operational disruption,
- long-term system thinking guided by domain continuity.
This is not a greenfield project or a full rewrite.
It is a production-proven operational platform, Comers (comers.app), being transformed in a controlled, contract-driven way by the same team that designed and operated it from the beginning.
Architecture showcase (GitHub)
This case study describes the context, evolution, and transformation strategy of the system.
If you want to see:
- how the modular monolith is organized today,
- which boundaries have already been identified and formalized,
- how domain extraction toward microservices is being sequenced,
- which architectural decisions and trade-offs are driving the transformation,
we have prepared a dedicated architecture showcase.
The repository includes:
- runtime architecture and execution-context descriptions,
- module and integration mapping,
- a step-by-step modernization model,
- domain boundary analysis,
- operational and evolutionary design assumptions,
without exposing business logic or sensitive data.
👉 Architecture showcase (GitHub)
https://github.com/rocketdeploy-dev/showcase-commerce-platform-modernization