When is code duplication acceptable or even preferable, and how do you explain that decision in a code review?

1. Sources

2. Bounded contexts

In DDD the same word means different things in different contexts:

A single shared Customer class becomes a god object every team edits. Separate models linked by IDs and events (CustomerRegistered) duplicate a few fields but keep each context free to evolve.

3. Across microservices

Duplicated DTOs per consumer are fine; tolerant readers let producers add fields.

4. Tests: DAMP over DRY

DAMP (Descriptive And Meaningful Phrases) means a test should be understandable in isolation: the reader sees the arrange, act and assert without jumping into base classes. Some repeated arrange lines are a fair price. When setup is genuinely complex, use test data builders (new OrderBuilder().WithLines(3).Paid().Build()), which remove noise without hiding intent. Avoid deep test base classes with hidden setup.

5. Performance-motivated duplication

In measured hot paths, a specialised copy (e.g. a Span<byte>-based parser for one format instead of a generic configurable parser) can avoid allocations, virtual dispatch or branching. Only do this with benchmark evidence (BenchmarkDotNet) and a comment linking to it, because it's still a maintenance cost.

6. Making deliberate duplication visible

// Deliberately separate from SupplierAddressRules: owned by Onboarding, diverges for ABN checks.
// See ADR-0042. Revisit if a third address-rules variant appears.
public static class CustomerAddressRules { ... }

A comment or ADR prevents a well-meaning refactor from re-coupling them.

7. Try it yourself

1. Find a shared helper with boolean parameters; list callers and the flags each passes.
2. Inline it into each caller and remove unused branches; compare readability.
3. Re-extract only what's truly common (often a value object).
4. Find a shared DTO package across services and check how many consumers had to upgrade for its last change.
5. Rewrite one test that depends on a base class into a self-contained DAMP test with a builder.

// The wrong abstraction: one formatter, a flag per caller.
public static class AddressFormatter
{
    public static string Format(Address a, bool forLabel, bool includeCountry, bool upperCase)
    {
        var text = forLabel
            ? $"{a.Line1}\n{a.Suburb} {a.State} {a.Postcode}"
            : $"{a.Line1}, {a.Suburb} {a.State} {a.Postcode}";
        if (includeCountry) text += forLabel ? "\nAUSTRALIA" : ", Australia";
        return upperCase ? text.ToUpperInvariant() : text;
    }
}

// Deliberate duplication: each context owns its format and can change it alone.
public static class ShippingLabel
{
    // Australia Post style: upper case, suburb line separate.
    public static string Format(Address a) =>
        $"{a.Line1}\n{a.Suburb} {a.State} {a.Postcode}".ToUpperInvariant();
}

public static class InvoiceAddress
{
    public static string Format(Address a) => $"{a.Line1}, {a.Suburb} {a.State} {a.Postcode}";
}

// Shared knowledge stays shared: the Address value object itself.
public sealed record Address(string Line1, string Suburb, string State, string Postcode);

public static class Demo
{
    public static void Main()
    {
        var a = new Address("1 George St", "Sydney", "NSW", "2000");
        Console.WriteLine(ShippingLabel.Format(a));
        Console.WriteLine(InvoiceAddress.Format(a));
    }
}