Acumatica Domain-Driven Design

I get asked, usually by a developer who just came off a .NET Core project with a clean bounded-context diagram in Miro, whether Acumatica customizations can follow proper Domain-Driven Design. The honest answer is: partially, and you have to know exactly where the platform's own opinions override yours. Acumatica was not built as a DDD codebase - it predates the term's mainstream adoption in enterprise .NET by years - but several DDD ideas map cleanly onto it, and a few map so badly that trying to force them causes real damage.

What actually maps: aggregates and the DAC graph

The closest thing Acumatica has to a DDD aggregate root is a document DAC with its child line DACs - an SOOrder and its SOLine rows, an APInvoice and its APTran rows. The graph enforces consistency across that cluster the same way an aggregate root is supposed to: you don't persist an SOLine independently of its parent order's save cycle, because RowPersisting validation and the transaction boundary around Persist() treat the whole document as one unit. If you're coming from DDD, think of the PXGraph's primary view and its related child views as the aggregate boundary, and the RowPersisting/Persist() pair as the invariant-enforcement mechanism a DDD aggregate root method would normally own.

Where this breaks down is that Acumatica's "aggregate root" is not an object with behavior - it's a cache-tracked data bag, and the behavior lives in a separate graph class that operates on it from outside. A purist would call this an anemic domain model, and by classic DDD vocabulary, it is. I've stopped fighting that. Acumatica's entire extension model depends on behavior living in graphs and extensions that can be layered without touching the DAC, and a DAC with real behavior baked in would make that layering far harder to achieve safely across upgrades.

public class SOOrderEntry_CreditCheck : PXGraphExtension<SOOrderEntry>
{
    public static bool IsActive() => true;

    // The invariant "an order over the customer's credit limit cannot
    // release" is enforced here, at the aggregate boundary (RowPersisting
    // on the document), not scattered across individual line handlers.
    protected virtual void _(Events.RowPersisting<SOOrder> e)
    {
        if (e.Row == null || e.Row.Hold == true) return;
        var customer = PXSelect<Customer,
            Where<Customer.bAccountID, Equal<Required<Customer.bAccountID>>>>
            .Select(Base, e.Row.CustomerID);
        if (customer?.CreditLimit > 0m && e.Row.OrderTotal > customer.CreditLimit)
        {
            e.Cache.RaiseExceptionHandling<SOOrder.orderTotal>(e.Row, e.Row.OrderTotal,
                new PXSetPropertyException("Order total exceeds the customer's credit limit."));
            e.Cancel = true;
        }
    }
}

Bounded contexts exist, they're just called modules

Acumatica's module split - AR, AP, SO, PO, CA, GL - is a reasonably honest bounded-context map already drawn for you. Each module owns its own DACs and its own graphs, and cross-module references go through well-defined integration points: GL batches posted from subledgers, inventory transactions generated from sales orders, not modules directly manipulating each other's tables. When I design a customization that spans modules - say, a custom rebate calculation that reads sales history and writes AP bills - I treat the module boundary the same way I'd treat a bounded context boundary in a greenfield DDD project: read through public BQL views and graph actions, never reach into another module's DAC and mutate it directly from outside its own graph's save cycle, because that bypasses the invariants that module's own RowPersisting logic is there to enforce.

Where forcing DDD actively hurts

I've seen developers try to introduce a proper domain layer - POCOs with behavior, repository interfaces, a mapping layer between "domain objects" and DACs - inside an Acumatica customization, treating the DAC/graph pair as pure infrastructure to be wrapped. On a project two years ago I inherited exactly this: a rich domain model sitting on top of DAC-backed repositories, with business rules duplicated between the domain layer's validation and the DAC's own attribute-driven validation, because the two systems couldn't share Acumatica's event pipeline. Every bug fix had to be applied twice, once in the domain layer and once in the corresponding RowPersisting handler that the framework still fired regardless of what the domain layer thought. We ripped it out over three sprints and moved the logic back into graph extensions directly. The DAC/PXCache/event pipeline is not swappable infrastructure you can abstract behind an interface - it is the framework, and every screen, GI, workflow, and REST endpoint routes through it whether your domain layer knows about it or not.

What I actually recommend

• Treat document-plus-lines DAC clusters as your aggregates, and put invariant enforcement in RowPersisting at the document level, not scattered across every line handler.
• Respect module boundaries as bounded contexts - read via public BQL views and graph actions, don't reach across modules directly.
• Keep ubiquitous language in your field names, screen labels, and code comments. It's free and it prevents the worst kind of miscommunication.
• Do not build a separate domain layer with its own validation on top of DACs. The event pipeline already is your domain logic layer; wrapping it just creates two sources of truth that will drift.

Wrapping up

DDD's strategic patterns - bounded contexts, ubiquitous language, aggregate boundaries - translate reasonably well onto Acumatica's existing module and document structure, because the platform was already organized along similar lines even before the term existed. The tactical patterns - rich domain objects, repositories, layers that abstract away the ORM - fight the framework directly, because PXGraph and PXCache are not infrastructure you can hide behind an interface. Use the strategic ideas to organize your thinking and your customization boundaries; leave the tactical ones in the DDD book.