Saltar a contenido

Q&A — Redundancies & Boundaries

Questions Aswered

1) Are Goals & Savings and Forecasting & Financial Advice different domains?

Short answer: Yes.

  • Goals & Savings owns planning & execution toward a specific target (create goal, fund goal, track progress, mark reached). This domain is about intentional financial behaviour. Users define what they want to achieve and how they’ll get there.

  • Forecasting & Financial Advice owns system-wide predictions & recommendations (cashflow horizon, risk alerts, optimization tips).

    Interaction: Goals emits GoalCreated/GoalFunded/GoalReached; Forecasting consumes those to update global projections and produce advice.

Why separate?

  • Clear ownership (goal lifecycle vs. global reasoning)
  • Independent evolution (you can swap/upgrade forecasting models without touching goal invariants)
  • Cleaner APIs and event contracts

2) Should the Conversational Assistant (Core) use the Notifications & Communication domain?

Short answer: Yes, by design.

  • The Assistant decides what to say (content & timing), but how/where it’s delivered (WhatsApp, push, email) is the job of Notifications.
  • Pattern: Assistant → (message/intention) → Notifications → Channel adapters (WhatsApp, ChatGPT Apps, Push)

Benefits

  • Centralized delivery logic (templates, localization, rate limits)
  • Unified user preferences (quiet hours, opt-in/out)
  • Auditable message history independent of the assistant

3) Document upload & recognition: how do we continuously identify financial institutions and validate they’re legit in a given country?

Ownership split

  • Document Management (Generic): ingest files, OCR, extract fields.
  • Integration Platform (Generic) + Ingestion (Supporting): maintain Institution Registry and perform validation.

Model

  • InstitutionRegistry (per country):
    • Bank identifiers (SWIFT/BIC), IBAN rules (length/checksum), ABA/Routing, BIN/IIN ranges (cards), tax IDs where applicable.
    • Source links (official registries / Open Banking directories).
  • DocumentExtraction: normalized fields from OCR (bank name, BIC/IBAN, account number, statement layout signature).
  • ValidationService:
    1. Syntax checks (IBAN checksum, routing number algorithm).
    2. Directory checks (BIC in registry, BIN/IIN ranges, issuer country match).
    3. Heuristic/layout checks (known templates, watermark/hash of statement headers).
    4. Risk flags (mismatch between claimed country and identifier, expired institution, unlisted brand).

Event flow

  • DocumentUploaded → OCR → DocumentParsed → InstitutionValidated {status: Valid/Unknown/Suspect}
  • Unknown/Suspect → human review queue (ops tool) and feedback loops to improve templates.

Privacy

  • All checks happen under an active Consent Grant (purpose = “document verification”), and PII is minimized/redacted in logs.

Policy architecture

  • Consent Grant (aggregate): scopes (read:transactions, read:documents, write:transfers), purposes, expiry.
  • PDP/PIP Pattern:
    • PDP (Policy Decision Point): service that decides “allow/deny” per request using consent + IAM + purpose.
    • PEP (Policy Enforcement Point): middleware in every service/API that calls PDP before accessing data.
  • Data tagging: records labeled with tenant_id, consent_id, purpose.
  • Event metadata: domain events carry consent_id + purpose so consumers re-check.
  • Minimization: queries project only needed fields; sensitive fields masked by default.
  • Retention: background jobs enforce RetentionPolicy per consent.
  • Audit: append-only DataAccessLog and ConsentAuditTrail.

Guarantee comes from: deny-by-default + centralized decisions + per-record tagging + immutable audit + automated retention—not just trust in service code.

5) Is the Integration Platform & APIs domain involved in the infrastructure that maintains/communicates core services?

Short answer: Externally, yes. Internally, no.

  • Yes (external): owns public/partner APIs, inbound webhooks (e.g., WhatsApp, Open Banking), token/rate-limit policies, and mapping external payloads → internal commands (with Anti-Corruption Layers).
  • No (internal mesh): core-to-core comms (REST/gRPC/events) are platform/infra concerns (API Gateway/Service Mesh/Event Bus) and not owned by the Integration domain. Those are part of Technical Architecture/Infra, not a business domain.

Rule of thumb

  • Integration Platform = the boundary to outside.
  • Service Mesh / Event Bus / API Gateway = inside, infra-level, shared by all domains, defined in your Architecture section.

Questions to be asnwered

Please add below any questions that whose aswer must be added in the previous section