What is correct way to accept arguments in Domain Model when you want to add item?

Question

I'm looking for ways how to accept arguments in the domain model when you want to add items in it.

Let's take a look at this example:

public class Order {
    public ICollection<OrderItem> Items { get; set; }
    
    // Way 1
    public void AddItem(OrderItem item) {
       // Add
    }

    // Way 2
    public void AddItem(decimal amount, Address address, string cardNumber) {
       // Add
    }

    // Way 3
    public void AddItem(ItemArgs args) {
       // Add
    }
}

As you can see there I have been using 3 ways but which one is right and why?

Is that okay to build up domain model entities from outside? Like create OrderItem from outside of the domain model and pass it through AddItem method

In the second case I'm accepting many arguments if there will be more properties then it could grow up.

and last one where I have argument class where are properties aggregated.

For example if I need same properties as I have in OrderItem should I accept that type directly ? But that case not happens everytime. So I don't want to have different approaches in my domain model. I would like to implement the one and follow that.

I would like to hear it from you how you manage such things in your domain model?

Answer 1

As you can see there I have been using 3 ways but which one is right and why?

The first thing that I would call your attention to is that this is purely a design question; what you are asking, really, is whether the OrderItem constructor should be called from inside the domain model or from the outside.

Design is what we do to get more of what we want than we would get by just doing it -- Ruth Malan

So the answer is going to be "it depends"; it depends on "what you want" -- once you understand that, then guessing which design gives you more of it is usually a straight forward process.

One of the ideas hidden with domain driven design is that the domain dynamics (my term for the parts of the domain that govern how information changes) should be described by an abstraction in the language of the domain itself. Imagine, if you will, an expert in your domain who is not a programmer, looking at your code and correctly identifying a bug because she can see the inconsistency between what you've written and how the domain should work.

In your example, that would normally mean we want

void AddItem(OrderItem item)

because that's the way we think about it when we are thinking in the language of the domain - we add Items, not "things that can be frankensteined together to create an Item", to orders. We describe the dynamics at that level of abstraction, and the other "computer stuff" happens somewhere else.

If you like, you can think on it through the lens of SRP - the responsibility of the domain model is the domain dynamics; the responsibility to assemble the information into abstractions that the domain understands belongs out in the plumbing.

(The line isn't normally quite so clean as that - the OrderItem constructor, and the Address constructor, and so on - are often deployed along side the domain dynamics, and if you look at the flow of control it will frequently pinball between modules until the data structures and abstractions are prepared.)