Architecture
NewSun is designed as a modular monolith with strict boundaries, independent migrations, and toggle-driven activation. The architecture is intentionally extraction-ready for microservices.
Module boundary model (DDD)
Each module is a bounded context with its own domain, API (optional), persistence, and migrations.
flowchart LR
subgraph APP[Spring Boot 4 Application]
direction TB
CORE[Core Platform: auth, tenancy, logging, i18n]:::p
subgraph M1[Audit Module]
AAPI[REST API]:::m
ASVC[Use cases]:::m
ADOM[Domain]:::m
APER[Persistence + Flyway]:::m
end
subgraph M2[Inspection Module]
IAPI[REST API]:::m
ISVC[Use cases]:::m
IDOM[Domain]:::m
IPER[Persistence + Flyway]:::m
end
subgraph M3[RCSA Module]
RAPI[REST API]:::m
RSVC[Use cases]:::m
RDOM[Domain]:::m
RPER[Persistence + Flyway]:::m
end
CORE --> M1
CORE --> M2
CORE --> M3
end
DB[(MySQL 9.5.0 LTS)]:::db
M1 --> DB
M2 --> DB
M3 --> DB
classDef p fill:#0f1a2f,stroke:#7cdbff,stroke-width:1px,color:#e6eefc;
classDef m fill:#101f3a,stroke:#a78bfa,stroke-width:1px,color:#e6eefc;
classDef db fill:#0f1a2f,stroke:#34d399,stroke-width:1px,color:#e6eefc;
Deployment topology (today → tomorrow)
sequenceDiagram
autonumber
participant FE as Web UI
participant APP as Spring Boot App (Monolith)
participant MOD as Module (Audit)
participant DB as MySQL 9.5.0
FE->>APP: API call (JWT/OIDC)
APP->>MOD: In-process call
MOD->>DB: Read/Write owned tables
MOD-->>APP: Result
APP-->>FE: Response
Note over MOD: Tomorrow: extract module
FE->>APP: same API
APP->>MOD: REST/Event instead of in-process
MOD->>DB: same owned schema