Context
BSFG facts carry canonical JSON payloads and may include an optional schema reference in the envelope. This leaves an architectural question: should the boundary substrate enforce business-schema validation before accepting a fact, or should validation remain the responsibility of producers and consumers?
The decision affects:
- whether BSFG remains domain-agnostic or becomes schema-governing middleware
- how fast new bounded contexts can evolve
- how failures are classified at the boundary
- whether transport durability depends on domain-model readiness
Options Considered
| Option | Description | Benefits | Drawbacks |
|---|---|---|---|
| Strict boundary validation | BSFG validates every fact object against a registered schema before append. |
- strong uniform gatekeeping
- bad payloads fail early
|
- boundary becomes domain-coupled
- schema registry becomes mandatory infrastructure
- transport availability depends on schema lifecycle
|
| Best-effort validation when schema is present | BSFG tries to validate only when an object_schema hint is provided. |
- partial protection
- more flexibility than strict enforcement
|
- ambiguous contract
- different payloads get different boundary behavior
- still drags schema logic into the transport layer
| | No schema reference at all | Carry raw canonical JSON only and omit schema references entirely. |
- maximal transport neutrality
- minimal metadata surface
|
- weak interoperability hints
- harder downstream evolution and governance
- less diagnosable payload contracts
| | Optional schema reference; validation stays outside BSFG (Selected) | BSFG accepts canonical JSON payloads, may carry an optional schema hint, but does not perform business-schema validation itself. |
- keeps boundary substrate domain-agnostic
- preserves transport durability independence
- supports schema governance without transport coupling
- lets bounded contexts evolve independently
|
- bad domain payloads may still be durably transported
- producers and consumers must own validation explicitly
|
Decision
BSFG does not perform business-schema validation as part of the boundary append path.
boundary acceptance = transport validity + idempotency validity
not = business-schema validity
An envelope may include an optional schema hint, for example:
object_schema = "urn:bsfg:schema:batch.step_completed:v1"
That hint is carried for downstream interpretation and governance, but BSFG itself remains agnostic. Producers, consumers, and downstream domain services are responsible for:
- validating payloads against expected schemas
- enforcing compatibility rules
- rejecting or correcting semantically invalid facts in their own bounded contexts
Consequences
Benefits:
- the boundary appliance remains transport-centric rather than domain-governing
- schema governance can evolve independently of the durable transport substrate
- new bounded contexts can start using BSFG without waiting for central schema enforcement
- transport outages and schema outages do not collapse into one failure mode
Tradeoffs:
- semantic correctness is not guaranteed by the boundary layer
- downstream systems must emit their own acceptance, rejection, or correction facts deliberately
- organizations that want strict schema governance must implement it outside the core BSFG append path