Skip to content

Catalog

A subdomain is a problem you were given. A bounded context is a solution you chose.

Which is why they are listed separately here, and why the mapping between them is not forced to be one to one. Where a single subdomain is served by two contexts, somebody decided that on purpose. Where one context is straddling two subdomains, that is not a tidy-up job — it is the most interesting sentence on this page, and it usually explains an argument that has been running for years.

What an entry holdsCompare against the estate

The domain

Personal and commercial insurance

Underwrite risk, price it, collect premium for it, and pay what is owed when it materialises. Everything else in the estate exists to make one of those four things possible.

Subdomains
9
Bounded contexts
9
Fully modelled
5
Not aligned
4

A worked example.The contents below are a seed catalog for an insurance carrier — the canonical domain in the literature, and one whose core/supporting/generic split is unusually crisp. Replace it with your own; what is worth copying is the shape of an entry, not the entry.

Core subdomains

3

The reason the business wins. Modelled deeply, built in house.

Underwriting

Deciding which risks to accept and on what terms. The judgement here is the business — an underwriter who is right more often than the market is the entire competitive position.

  • Risk appetite

    Drifting

    Where a submission is judged against what the carrier is currently willing to take on. A Risk here is a described exposure under consideration — it is not yet anything anyone is on cover for.

    Language
    SubmissionRiskAppetite ruleReferralDecline reason
    Aggregates
    Submission, AppetiteRuleSet, Referral
    Realised by

    uw-workbench implements it — Owns Submission and Referral end to end; the aggregate boundaries in the code match the model.

    legacy-policy-master reaches into it — Reads the appetite tables directly over a database link to pre-screen renewals, so an appetite change takes effect in two places at different times.

    Owner: Head of underwritingModelled

Pricing and rating

Turning an accepted risk into a number. Distinct from underwriting because the appetite question and the price question have different owners, different data and different regulators.

  • Rating

    Aligned

    Where a Risk becomes a premium. The same word "Risk" arrives from Risk appetite meaning a judgement; here it means a vector of rating factors, and the translation between the two is explicit rather than assumed.

    Language
    Rating factorRate tableBase premiumLoadingTechnical price
    Aggregates
    RatingRequest, RateTableVersion
    Realised by

    rating-engine implements it — Stateless service behind a published language; rate table versions are immutable and addressable, so a quote can be re-run years later.

    Owner: Chief actuaryModelled

  • Quotation

    Aligned

    Where a technical price becomes an offer with a validity period and a set of conditions. Deliberately separate from Rating: a price is a calculation, a quote is a commitment with an expiry.

    Language
    QuoteOfferValidity periodConditionLapse
    Aggregates
    Quote
    Realised by

    uw-workbench implements it — Same deployable as Risk appetite, separate module and separate schema. The boundary is enforced in the build, not by convention.

    Owner: Head of underwritingModelled

Claims handling

Establishing what is owed and paying it. The only part of the business the customer experiences at the moment it matters, and the only place a mispriced book becomes visible.

  • Claims

    Breached

    From first notification to settlement or repudiation. "Policy" here is a snapshot of cover as it stood on the date of loss, not the live policy — a distinction that has decided more disputes than any other in this catalog.

    Language
    NotificationClaimReserveSettlementRepudiationCover snapshot
    Aggregates
    Claim, Reserve, Payment
    Realised by

    claims-platform implements it — Owns Claim and Reserve.

    legacy-policy-master shares a database with it — Claims reads live policy rows rather than a cover snapshot, so a mid-term endorsement retroactively changes what an open claim appears to be covered for. This is the single most expensive finding in the landscape.

    Owner: Claims directorModelled

Supporting subdomains

3

Necessary and specific to us, and not a differentiator. Built simply.

Policy administration

Keeping a policy correct through its life: endorsements, renewals, cancellations, reinstatements. Specific to us, necessary, and not a reason anyone buys from us.

  • Policy lifecycle

    Drifting

    The policy as a thing with a history: incepted, endorsed, renewed, cancelled, reinstated. Every change is an event with an effective date, because "what did the cover say on 3 March" is a question that gets asked in court.

    Language
    PolicyInceptionEndorsementEffective dateRenewalCancellation
    Aggregates
    Policy, Endorsement
    Realised by

    legacy-policy-master partially implements it — Holds the data and enforces roughly half the invariants; the rest live in a batch job that runs overnight, which is why an endorsement can be inconsistent for up to fourteen hours.

    policy-service partially implements it — The strangler. Owns renewals today; inception and endorsement are still upstream.

    Owner: Operations manager, policy servicesDrafted

Distribution and party management

Who we deal with and through whom — brokers, agents, policyholders, beneficiaries — and the commission that follows. Necessary, and unusually good at hiding a modelling problem behind the word "customer".

  • Party and relationships

    Breached

    People and organisations, and the roles they play — policyholder, broker, beneficiary, claimant. The model is deliberately role-based, because the same organisation is a broker on one policy and a policyholder on another and "customer" cannot hold both.

    Language
    PartyRoleRelationshipBrokerPolicyholderClaimant
    Aggregates
    Party, PartyRelationship
    Realised by

    crm partially implements it — Bought package. Its "Account" is not a Party — it merges the organisation and the broker role, which is why commission is occasionally paid to a policyholder.

    legacy-policy-master partially implements it — Keeps its own customer table, unreconciled. Two identities for the same organisation is the normal case, not the exception.

    Owner: Head of distributionDrafted

Product definition

What a product is: covers, limits, exclusions, wordings, and the rules for combining them. Built in house because the products change faster than any vendor release cycle.

  • Product catalogue

    Aligned

    What can be sold and how it may be assembled: covers, limits, exclusions, wordings, and the compatibility rules between them. Upstream of nearly everything, and the reason a product change is a configuration exercise rather than a release.

    Language
    ProductCoverLimitExclusionWordingCompatibility rule
    Aggregates
    Product, WordingVersion
    Realised by

    product-service implements it — Open host service with a published language; every downstream context consumes the same versioned product definition.

    Owner: Product owner, personal linesModelled

Generic subdomains

3

A solved problem someone else sells. Bought, wrapped, not modelled.

Billing and collections

Invoicing, instalments, dunning, reconciliation. Nobody has ever chosen an insurer for its direct debit handling.

  • Billing

    Aligned

    Premium in, refunds out, instalments tracked, arrears chased. Bought whole and wrapped: nothing inside this boundary is our model, and an anticorruption layer keeps its vocabulary from leaking into the ones that are.

    Language
    InvoiceInstalmentDunningWrite-off
    Aggregates
    None — bought whole and wrapped.
    Realised by

    billing-saas is bought for it — Vendor product. Integration is one-way over the published events, through an adapter owned by us.

    Owner: Finance systems managerNot modelled

Document generation

Producing the schedule, the certificate and the letter, in the format the regulator expects. A solved problem with a mature market.

  • Documents

    Unobserved

    Rendering a schedule, certificate or letter from a template and a payload, and keeping the evidence of what was sent. A generic subdomain treated as one.

    Language
    TemplateRenditionDispatch record
    Aggregates
    None — bought whole and wrapped.
    Realised by

    doc-gen is bought for it — Vendor product. Nothing observes it, which is why its conformance is unknown rather than aligned.

    Owner: Operations manager, policy servicesNot modelled

Notifications

Email, SMS and postal dispatch with delivery evidence. Bought, wrapped, and deliberately not modelled.

    Every context, at a glance

    The same 9 contexts as a table, because the useful question is usually comparative: which core contexts are not fully modelled, and which boundaries the estate is not respecting.

    ContextSubdomainModelEstateOwner
    Risk appetiteUnderwritingCoreModelledDriftingHead of underwriting
    RatingPricing and ratingCoreModelledAlignedChief actuary
    QuotationPricing and ratingCoreModelledAlignedHead of underwriting
    ClaimsClaims handlingCoreModelledBreachedClaims director
    Policy lifecyclePolicy administrationSupportingDraftedDriftingOperations manager, policy services
    Party and relationshipsDistribution and party managementSupportingDraftedBreachedHead of distribution
    Product catalogueProduct definitionSupportingModelledAlignedProduct owner, personal lines
    BillingBilling and collectionsGenericNot modelledAlignedFinance systems manager
    DocumentsDocument generationGenericNot modelledUnobservedOperations manager, policy services

    The Estate column comes from thelandscapes, not from anybody’s opinion. A context nothing is observing readsUnobserved rather than Aligned, which is the only honest answer.