Give the requirement its own value object. It describes what an acceptable result looks like. Validation asks whether one result fits; selection finds existing results that fit; building to order asks a generator to produce a result that fits.

The generator owns the method. The specification owns the acceptance criteria.

type Report = { rows: number; format: string };
class ReportSpec {
  constructor(
    readonly maxRows: number,
    readonly format: string
  ) {}
  isSatisfiedBy(r: Report) {
    return r.rows <= this.maxRows && r.format === this.format;
  }
}
const spec = new ReportSpec(500, "PDF");
spec.isSatisfiedBy(report);             // validate
reports.filter(r => spec.isSatisfiedBy(r)); // select
const built = generator.build(spec);    // build to order
if (!spec.isSatisfiedBy(built)) throw Error("Invalid output");

Name the small predicates first. Compose them into a bigger specification. The result has the same interface as its parts, so callers do not need a second way to evaluate a compound rule. This is also an example of closure of operations.

A combined rule is still a rule. That small property makes composition useful.

type Spec<T> = { isSatisfiedBy(value: T): boolean };
const and = <T>(a: Spec<T>, b: Spec<T>): Spec<T> => ({
  isSatisfiedBy: value =>
    a.isSatisfiedBy(value) && b.isSatisfiedBy(value)
});
const eligible = and(trainingComplete, membershipCurrent);
eligible.isSatisfiedBy(candidate);

Keep hard requirements in a specification. Give the variable choice policy its own strategy. A route can satisfy the delivery deadline and still be a poor choice under the cheapest-route policy. Changing the preference should not quietly change what counts as valid.

Validity is a constraint. Preference is a choice among valid options.

const feasible = routes.filter(route =>
  deliverySpec.isSatisfiedBy(route)
);
const cheapest = (r: Route) => r.costCents;
const fastest = (r: Route) => r.hours;

function choose(routes: Route[], score: (r: Route) => number) {
  return routes.reduce<Route | undefined>((best, r) =>
    !best || score(r) < score(best) ? r : best, undefined);
}
const chosen = choose(feasible, cheapest);

Move the calculation into a side-effect-free function, often on a value object. Keep the command that applies the result small. Describe its preconditions, postconditions, and invariants so a caller can understand the outcome without following every internal call.

A preview should be repeatable. A command should make its changes obvious.

const before = order.snapshot();
const quote = pricing.quote(before, discountPolicy);
// quote() does not change the order.
assert.deepEqual(order.snapshot(), before);

order.acceptQuote(quote);
// Contract: accepted total equals this quote's total.
assert.equal(order.totalCents, quote.totalCents);

A value object is defined by its attributes, without an identity you need to track through change. Give a complete concept like DateRange its own behavior. Return a new value for a new result. Use an entity when continuity matters even as attributes change.

A useful value object owns both the data and the rules that make those data meaningful.

class DateRange {
  // Integer day indexes; half-open interval [start, end).
  constructor(readonly start: number, readonly end: number) {
    if (!Number.isInteger(start) || !Number.isInteger(end)
        || end <= start) throw Error("Invalid date range");
    Object.freeze(this);
  }
  overlaps(other: DateRange) {
    return this.start < other.end && other.start < this.end;
  }
}

Start with an invariant: allocated seats must never exceed capacity. Put the state needed to enforce it inside one aggregate and route changes through its root. The boundary says which facts must agree when the transaction completes. It is more than a convenient object graph.

Choose the consistency rule before choosing the aggregate boundary.

// Illustrative application + persistence boundary.
await transaction(async tx => {
  const event = await events.loadForUpdate(eventId, tx);
  event.reserveSeats(requestedSeats); // checks the invariant
  await events.save(event, tx);
});
// The root owns capacity and reservations.
// Locking, or version checks with retries, must prevent
// concurrent writes from committing incompatible states.

Ask what distinction the model is failing to express. In the book, separating interest accrual from payment removes a false coupling: income can be earned before cash arrives. Extracting another helper would not reveal that distinction. A named concept gives the team something precise to discuss.

Sometimes the best refactor changes what the code means, not just where it lives.

// Two different facts, with independent timing.
type Accrual = {
  earnedOn: string; amountCents: number; ledger: string
};
type Payment = {
  receivedOn: string; amountCents: number
};
// Accrual calculation no longer depends on when cash arrived.
const accruals = asset.accrueThrough(asOfDate);

Tell the same scenario using the objects and operations in the model. When the sentence becomes vague or needs a long technical aside, look for a missing concept or a misleading name. Update conversation, tests, and code together. The language is a working model, not just a glossary.

A clearer sentence can reveal a better behavior: keep an itinerary that still satisfies the changed requirements.

// Mechanism hides the business decision.
if (changedFields.length) rebuildRows(recordId);

// An illustrative domain conversation in code.
if (!newRouteSpec.isSatisfiedBy(currentItinerary)) {
  cargo.assignItinerary(router.find(newRouteSpec));
}

Define where each model and language apply. A prospect in sales and an invoice recipient in billing may refer to the same person without being the same concept. Draw the existing contexts, their owners, and what crosses each boundary. Make translation explicit.

Consistency inside a context lets different models coexist across contexts.

// Sales context
type SalesCustomer = { prospectId: string; stage: SalesStage };
// Billing context
type BillingCustomer = {
  accountId: string; invoiceAddress: Address
};
// Link identities deliberately. Do not silently treat
// prospectId and accountId as interchangeable.

Put a translation layer between models. Its public interface speaks your domain language; its implementation understands the other system. Translate meaning, units, identities, and failure cases. A transport wrapper alone does not do this job.

The boundary earns its keep when a foreign concept changes and the change stops there.

type Availability = "available" | "unavailable" | "unknown";
function translateAvailability(code: string): Availability {
  // Fictional provider contract: 1 = ready, 0 = not ready.
  switch (code) {
    case "1": return "available";
    case "0": return "unavailable";
    default: return "unknown";
  }
}
// Provider codes stay inside this adapter.

A factory creates a valid new object or aggregate and hides complex assembly. A repository provides access to existing aggregates through a collection-like interface. Returning a usable domain object keeps persistence details out of the business conversation.

Creation establishes a valid beginning. Retrieval preserves an existing identity.

const booking = bookingFactory.create(request); // new identity
await bookings.add(booking);

const existing = await bookings.byId(booking.id); // same identity
existing.changeItinerary(replacement);
await bookings.save(existing);
// Transaction ownership stays explicit at the application edge.

Within the domain layer, organize modules around cohesive concepts. A module name should help someone predict where a business change belongs. Observe which responsibilities repeatedly change together, and refine the boundaries as your understanding improves.

A module name is part of the model. Use it to explain a piece of the business.

domain/
  booking/
    Booking.ts
    BookingFactory.ts
    BookingRepository.ts
  routing/
    RouteSpec.ts
    Itinerary.ts
    RoutingPolicy.ts

Extract a coherent computational mechanism behind an intention-revealing interface. The domain still owns the question and its rules. The mechanism carries out the calculation. A narrow graph solver or constraint solver is a better boundary than a general-purpose Utils or Calculator class.

The domain formulates the problem. The mechanism solves the computation.

const problem = routingModel.toSearchProblem(request);
const solution = solver.findPath(problem);
if (!solution) return { kind: "no-route" };
const itinerary = routingModel.toItinerary(solution);
if (!request.spec.isSatisfiedBy(itinerary)) {
  throw Error("Solver returned an invalid itinerary");
}
return { kind: "found", itinerary };

Identify the core domain: the specialized capability that justifies this system. Separate supporting and generic concerns so the core is visible. Invest modeling effort and strong developers there. A small core makes the project's priorities easier to defend.

The most technically interesting component is not automatically the core domain.

// Example for a specialized scheduling product.
Core:       matching scarce skills to urgent work
Generic:    identity, email delivery, basic calendaring
Supporting: operational imports and local admin workflows

Refactor first: the allocation model blocking new policies
Keep adequate: the already-working email template engine

Build a simple implementation behind the intended domain interface. It should respect the agreed constraints even if it finds worse answers or misses feasible solutions. The rest of the application can integrate, users can try the workflow, and discoveries can improve the contract early.

A small working implementation can test an interface more honestly than a canned response.

const result = simplePlanner.tryBuild(spec);
if (result.kind === "found") {
  assert(spec.isSatisfiedBy(result.plan));
  return result;
}
return { kind: "no-answer-found" };
// A heuristic finding no answer does not prove impossibility.
// Build a candidate separately; commit only an accepted plan.

If configuration is itself meaningful in the domain, give it a model. A workflow definition describes allowed steps; a workflow run records one execution under that definition. Keep the definition model focused on the variations users actually need.

The definition is domain data too. Give it a lifecycle and clear limits.

type WorkflowDefinition = {
  id: string; version: number;
  allowedSteps: readonly StepDefinition[];
};
type WorkflowRun = {
  id: string; definitionId: string;
  definitionVersion: number; currentStep: string;
};
// A definition change needs an explicit rule for existing runs.