Domain-Driven Design
also called DDD
Modelling software around the business domain, with boundaries drawn where the language of the business changes.
The durable contributions of DDD are strategic, not tactical. Ubiquitous language — the same words meaning the same thing in conversation, in the model and in the code. Bounded context — the recognition that "customer" means something different to billing than to support, and that forcing one shared definition creates a model that serves neither. Context mapping — being explicit about how those contexts relate.
Bounded contexts are the single most useful tool available for deciding where services should split, because they are drawn from how the business actually partitions rather than from technical convenience.
The tactical patterns — aggregates, repositories, value objects, entities — are useful but far more optional, and applying them without the strategic work produces ceremony with no benefit.