mirror of
https://gitee.com/pnoker/iot-dc3.git
synced 2026-11-01 02:31:46 +08:00
pnokerandClaude Code
4cb3fd6440
The dc3-db aggregate mixed two naming axes and one axis-free module:
infrastructure used dc3-db-r2dbc-{core,runtime,postgres} (with "postgres"
sitting in a layer slot), the domain adapters used dc3-db-postgres-{domain}
(no "r2dbc" at all), and tck had no axis. PostgreSQL-only and R2DBC-only
are properties of the whole aggregate (dc3-db README, docs/db-dialects.md),
so the per-module prefixes carried no discriminating information — the
65 store classes already say R2dbc in their names.
New layout, one dc3-db-{role} pattern, aligned with the common-{domain} /
center-{domain} pairs they serve:
dc3-db-r2dbc-core -> dc3-db-core
dc3-db-r2dbc-runtime -> dc3-db-runtime (absorbs the dialect)
dc3-db-r2dbc-postgres -> (merged into dc3-db-runtime)
dc3-db-postgres-auth -> dc3-db-auth
dc3-db-postgres-manager -> dc3-db-manager
dc3-db-postgres-data -> dc3-db-data
dc3-db-postgres-agentic -> dc3-db-agentic
dc3-db-tck -> unchanged
The dialect module held a single 12-line AutoConfiguration registering
StandardR2dbcDialect("postgres", ...) plus the r2dbc-postgresql driver;
both move into dc3-db-runtime (package io.github.pnoker.db.runtime.dialect,
registered in the runtime AutoConfiguration.imports, driver dependency
transferred). Its six dependents now rely on the runtime they already
pulled in. Java packages rename in step — io.github.pnoker.db.r2dbc.core
-> io.github.pnoker.db.core, io.github.pnoker.db.r2dbc.runtime ->
io.github.pnoker.db.runtime, io.github.pnoker.db.postgres.{auth,manager,
data,agentic} -> io.github.pnoker.db.{auth,manager,data,agentic} — so no
trace of the old axis survives outside git history.
Also fixes the stale module layout in docs/design/relational-r2dbc.md §6
(it still described stores living in dc3-common-*/repository, the
pre-7fde11134 arrangement) and ships migrations/02-schema-fingerprint-
resync.sql for existing volumes still carrying the pre-documentation
fingerprint marker.
Verified: full-reactor compile, dc3-db aggregate tests (-am), all six
service images rebuilt through the multi-stage Dockerfile (container
Maven package), WSL stack recreated with every center healthy, and an
end-to-end login + manager list smoke test through the gateway (JWT
cookie, offset/limit/sort paging).
Co-Authored-By: Claude Code <noreply@anthropic.com>
DC3 Common
dc3-common contains reusable backend libraries and the shared business implementations assembled by the deployable
center and driver applications.
Domain modules
| Module | Responsibility |
|---|---|
dc3-common-auth |
authentication, authorization, identity, OAuth2, and auth gRPC servers |
dc3-common-manager |
driver/device/profile/point metadata and manager APIs |
dc3-common-data |
values, commands, events, status, and data APIs |
dc3-common-agentic |
AI models, sessions, tools, and assisted operations |
dc3-common-driver |
driver SDK, registration, scheduling, metadata, command, and value runtime |
dc3-common-gateway |
gateway routes, authentication filter, and ingress support |
Contracts and models
| Module | Responsibility |
|---|---|
dc3-common-model |
shared BO/VO/DTO bases, builders, extension models, validation groups, and transport models |
dc3-common-public |
response envelope, BaseService, shared entities/utilities, and tenant markers |
dc3-common-api |
shared gRPC conversion helpers |
dc3-common-facade |
cross-service facade contracts and implementations |
dc3-common-constant |
stable platform-wide constants and shared domain/wire/persistence enums |
dc3-common-exception |
shared exception hierarchy |
Infrastructure modules
| Module | Responsibility |
|---|---|
dc3-common-mqtt |
MQTT client configuration |
dc3-common-quartz |
scheduling infrastructure |
dc3-common-thread |
managed executors |
dc3-common-web |
WebFlux, springdoc, security, and controller support |
dc3-common-log |
logging defaults |
dc3-common-sql |
SQL utilities |
dc3-common-resource |
API/resource annotation discovery and synchronization |
dc3-common-test |
shared tests, harnesses, and Testcontainers |
Datasource, messaging, and time-series storage were split into dedicated top-level families; business modules depend on them directly:
dc3-db— canonical PostgreSQL R2DBC runtime, dialect contract and schema fingerprint gatedc3-mq— broker-neutral messaging port with per-broker adapters (RabbitMQ, Kafka, RocketMQ, Pulsar, ActiveMQ, MQTT)dc3-tsdb— store-neutral time-series port with per-store adapters (TimescaleDB, TDengine, InfluxDB, IoTDB)
Architecture rules
- Preserve
Controller -> Service -> Manager -> Mapperlayering. - Keep tenant scope in queries, cache keys, gRPC calls, and cross-service lookups.
- Use BOs in persistent business services and builders for VO/BO/DO conversion.
- Use facade interfaces for cross-service business calls.
- Add dependencies to the narrowest module that owns the required capability.
- Treat Java visibility and module ownership separately: framework-neutral shared code belongs in
dc3-common-public, while capability-specific public APIs remain with their owning module. - Keep platform-wide constants and top-level shared enums in
dc3-common-constant; keep module-local constants and nested implementation/configuration enums beside their owner. Top-level*Constantnames and top-level public enums are reserved fordc3-common-constant; use concern-specific local names such as*Limitsor*Defaults.
Verification
mvn -s .mvn/settings.xml -q -f dc3-common/pom.xml -DskipTests compile
mvn -s .mvn/settings.xml -f dc3-common/pom.xml test
Use the child README for module-specific configuration and tests.