An aggregate that was three aggregates in a trench coat

A Subscription class of nine hundred lines, holding the plan, the billing schedule and the usage record, loaded in full to check whether a feature was enabled.

the consistency question, per group of fields:

  plan + entitlements     must be consistent. one
                          aggregate.
  billing schedule        changes independently, on a
                          different clock, by a
                          different process.
  usage counters          written thousands of times a
                          day by a metering job, and
                          read once a month.

three aggregates. the feature check now loads 1 row
instead of 40, and the metering job no longer collides
with a plan change.

The collision was the symptom that forced this: a plan change and a usage increment touching the same row produced lock waits under load, which looked like a database problem and was a modelling one. Splitting by what must be transactionally consistent gives a smaller answer than splitting by what belongs together in a sentence, every time.