Release: Phase 15 — PaymentProvider boundary (Stripe deferred, #59) - #75
Merged
Conversation
… (Phase 15) Extract a PaymentProvider interface (charge(token, amount) → ChargeOutcome) so the OrderPlaced consumer depends on an abstraction, not the concrete simulator. SimulatedProvider wraps the existing PaymentSimulator: it resolves the token to its redacted last-four and delegates, preserving every approve/decline/insufficient branch. The consumer now switches on ChargeOutcome and no longer resolves tokens itself. Pure refactor — no behaviour, event-shape, or API change; the Stripe slice will add a second implementation behind the same interface and a config toggle. mvn verify green (98 tests; PaymentFlowIT unchanged). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…tub, Stripe deferred (Phase 15) Records the Phase-15 decision: ship the PaymentProvider boundary + the SimulatedProvider Service Stub (slice 1), and deliberately DEFER the live Stripe adapter rather than build it. Rationale cited to PoEAA (Gateway + Service Stub), XP YAGNI, APoSD (keep unearned complexity out), PragProg (reversibility — the seam makes reintroducing Stripe no-rework) and DDD (clean port on the Payment context). No config toggle added: a switch with one valid value is itself speculative. The project keeps zero external dependency. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Phase 15, rescoped. Ships the
PaymentProvidergateway +SimulatedProviderService Stub and deliberately defers the live Stripe adapter as a documented engineering decision (ADR-0015).Why the rescope
The original plan was a live Stripe Test-Mode provider behind a config toggle. On building it, the abstraction proved to be the whole value and the live adapter proved to be speculative weight that would add an external account + credential the project would essentially never exercise. The books line up behind deferring it:
PaymentProvideris the Gateway;SimulatedProvideris the Service Stub you develop and test the whole system against. The valuable half shipped.ShopSphere keeps its defining property: runs end-to-end with zero external dependency, in
simulatormode.What shipped
PaymentProviderinterface —charge(token, amount) → ChargeOutcome(Succeeded/Failed).SimulatedProvider— resolves token→last-four, delegates to the existingPaymentSimulator; every approve/decline/insufficient branch preserved.PaymentOrderingConsumerrouted through the interface (no longer resolves tokens or knows the backend).PaymentConfigbean wiring;SimulatedProviderTests(4);PaymentMetricsTestsupdated to construct via the provider.Deliberately NOT done (deferred, see ADR-0015)
StripeProvider, Stripe Java SDK dependency,shopsphere.payment.providertoggle (one-value toggle = speculative), network-gated Stripe profile IT, stripe-mode QA. All cheap to add later behind the shipped seam.Acceptance criteria (#59) — reconciled
PaymentProviderinterface in Payment (charge(token, amount) → ChargeOutcome;Moneycarries currency)SimulatedProviderwraps existing simulator; unit tests pass (approve/decline/insufficient/unknown-token)OrderPlacedevent-shape changemvn verifygreen (98 tests)StripeProvider, config toggle, network-gated Stripe IT, stripe-mode QACloses #59.
🤖 Generated with Claude Code