Can objects outside the Application Layer hold references to Aggregate Roots

Question

Reading Domain-Driven Design, on the section of Aggregates, it says

The root is the only member of the Aggregate that outside objects are allowed to hold references to, although objects within the boundary may hold references to each other.

The Application Layer is the direct client of the domain model.

Can objects outside the Application Layer hold references to Aggregate Roots, or are the outside objects limited to the Application Layer objects? For instance, in another model or context?

---

From the comments, I suppose I'm asking about both separate layers, and separate models (different application in different domain).

Let's say I had a Shop Aggregate, which maintained a list of Items, with an associated Price. When a Player purchases an Item from a Shop, the cost of the Item is deducted from their Wallet, and the Item is added to their Inventory. These are separate Models, and they don't necessarily know about each other individually; ie. the Wallet doesn't know about Shops, the Items don't know about Wallets, etc. But I need to perform this coordination somehow. My ultimate goal is to perform this via Domain Events, but that's a separate question. This coordinating component, within a single transaction, would deduct the price of the Item from the Player's Wallet, and add the specified Item to their Inventory. The reason I want this to be as transactional as possible, is because this exists within the context of a video game, so I want to prevent annoying or exploitative results (like having the money removed from the wallet, but the item not being added; or the item being added, but the money not being removed, allowing duplication of Items, or Money).

As for the separate layer portion, the implementation of an Event Store, or Repository, would exist in the infrastructure layer (by Ports and Adapters).

While typing these portions of the comment response, I realized that it's a bit more obvious; why would I need to reference an Aggregate somewhere else, when everything I would want or need to do with that Aggregate should be exposed via Application Service, preferably referencing the Aggregate with an Id Value Object? I probably wouldn't need to reference the actual Aggregate, especially if I follow the rule of only modifying on Aggregate per transaction.

I would still like input as to the original quote, but I will write up another question for the portion I got confused about.

Answer 1

The reason I want this to be as transactional as possible, is because this exists within the context of a video game, so I want to prevent annoying or exploitative results (like having the money removed from the wallet, but the item not being added; or the item being added, but the money not being removed, allowing duplication of Items, or Money).

Stick to command-driven architecture to ensure that outside actors cannot subdivide your commands into smaller operations. The specifics on how to implement this depends on how your system is structure. At a basic level, you'd do something like:

public class PurchaseGoodsCommand
{
    public int TotalPrice { get; set; }
    public Dictionary<GoodType, int> Goods { get; set; } // Key = item type, value = amount 
}

I am going to leave the handling logic up to you, essentially taking money from the wallet and adding items to the inventory.

However, this is exploitable if you don't validate the price of items. I could send a request to purchase anything I want for a price of 0 (or even negative!)

Can objects outside the Application Layer hold references to Aggregate Roots, or are the outside objects limited to the Application Layer objects?

Depending on how to validate the price, you can change this. If prices are fixed, then only pass the Goods and let the backend figure out the price. If prices can differ between shops, then you need to pass Goods and some sort of ShopId so the backend can figure out the correct price for the shop.

If you let the pass the Shop object themselves, instead of the ID, then you give them the freedom to construct their own shop, which then can set its own prices. By forcing the consumer to pass the ShopId, you force the consumer to refer to an existing shop which your backend manages.

Of course, this implies that your consumer isn't able to create new shops in your backend either.

Overall, it's easier to have your backend maintain the data store, and to force the consumer to use references to that data, rather than pass the data themselves.

Note the ambiguity of "reference" meaning object reference or resource identifier. In your question you meant the former, but I mean the latter here.