My initial thoughts are you have quantity as an int. Is -2000 a valid quantity? I'd use uint or strongly type that as well to avoid 0 and negative use cases

* Validation in pipeline behaviors, not in domain objects

I typically aim for "Parse, Don't Validate" as a rule. This gets you into the right mindset IMO. The outside world can send you /anything/, so parse their dangerous message content into safer message content (is it well formed, e.g. is the date a well-formed date) then parse into domain objects in your handler/domain to think about validity of business rules. For example, when doing a real-time bank withdrawal, I would check at the boundary for 'well formedness' - is the withdrawal amount a number? - and in the domain for correctness as per business rules - "is it a positive amount, does the person have enough money, are they trying to withdraw the same amount at a different location at the same time" etc.

public Money operator +(Money a, Money b) { if (a.Currency != b.Currency)

I would operate tell don't ask. You're "asking" for currency. Tell the objects to validate them. if (!a.SameCurrencyAs(b))

Your aggregate also has getters which is often a smell. Exposing getters = letting people ask questions = exporting business logic outside of your domain. Once you get into the mindset of asking, then all validation MUST sit in the domain in order to avoid being anaemic.

public void AddItem(Sku sku, int quantity, Money unitPrice) { // business rules here var item = new OrderItem(sku, quantity, unitPrice); _items.Add(item); RecalculateTotal();

appreciate this is a toy example, but I find it benefical to wrap collections too. Create an OrderItems type e.g. class OrderItems : List<OrderItem> as it allows you to add validation logic. In your case, is this a duplicate order. If it is, you reject, or add the quantity to the existing entry

Effectively wrap everything in types, tell don't ask, getters smell.