The argument about whether an Order has a delivery address or a billing address is usually two contexts insisting on one word, and the resolution is that they each get their own.
// OrderingOrder — lines, totals, customer id
// FulfilmentShipment — address, weight, carrier, tracking
// BillingInvoice — tax, terms, payment status
//
// one database row may back all three. they are not the same object,
// and forcing them into one produces a class with forty properties
// of which each caller uses six.The signal that two contexts have been merged is a model where most fields are irrelevant to most uses, and a set of nullable columns that are only populated for some kinds of the same thing. Splitting them means translation at the boundary, which is more code and is the code that makes each side simple. Getting the vocabulary right on a whiteboard is genuinely most of the design work, and it is cheaper there than in a migration.