The argument about whether an Order has a delivery address or a billing address is 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 populated only 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 most of the design work and is cheaper there than in a migration.