Files
pnoker 372d75b0c9 refactor(core): rename find/query/fetch methods to get per crud law
sweep every module to satisfy the new method-name rule, renaming
about 40 methods together with their interface, implementation, test
and cli call sites: store find() lookups become get(), analytics
queryLatest/queryHistory become getLatest/getHistory, sql helper
query() becomes spec()/sql(), jwks fetch() becomes load(), and the
cursor record component queryDigest becomes requestDigest

no behavior changes; full unit suite (5278 tests) and both quality
gates stay green
2026-09-18 09:53:51 +08:00
..
2026-05-26 00:30:11 +08:00

DC3 Common Facade

The facade modules define and implement cross-service business boundaries without binding callers directly to gRPC or in-process service classes.

Modules

Module Role
dc3-common-facade-api transport-independent facade interfaces and request/result contracts
dc3-common-facade-grpc distributed implementations backed by shared gRPC stubs
dc3-common-facade-local-auth in-process auth facade implementation
dc3-common-facade-local-data in-process data facade implementation
dc3-common-facade-local-manager in-process manager facade implementation
dc3-common-facade-local convenience POM aggregating all local implementations

Selection

  • Distributed center applications normally use dc3-common-facade-grpc.
  • Single-process applications use the required domain-specific local modules.
  • Depend on dc3-common-facade-local only when the application intentionally needs every local facade.
  • Business code imports interfaces from dc3-common-facade-api; transport selection belongs in assembly/configuration.

Verification

mvn -s .mvn/settings.xml -q -f dc3-common/dc3-common-facade/pom.xml -DskipTests compile
mvn -s .mvn/settings.xml -f dc3-common/dc3-common-facade/pom.xml test