0

I am learning the DDD pattern and I have the following question.

On my [HttpPut] API endpoint I have a request command model which contains some properties to update a domain model aggregate root.

Now what is the correct way using DDD to update my domain model.

  1. Create a new object of the domain model mapping all the request command properties and use this object in the update method Update(Model model). Then update only the properties that were filled in for update.

  2. Just pass all properties one by one in the update method Update(string prop1, string prop2, bool prop3).

  3. Create a new domain model representing all properties for update Update(UpdateModel model).

Mivaweb
  • 5,580
  • 3
  • 27
  • 53

1 Answers1

3

I think you are somewhat missing the point here. DDD tactical patterns are mutually exclusive to CRUD. If the only commands you have in your system are create, update & delete then you won't benefit from DDD tactical patterns like aggregates and rich models much.

The first thing to do is ask yourself if you aren't wrongly forcing a CRUD model in a domain that isn't inherently CRUD. If you are then consider refactoring towards a task-based UI & avoid an anemic domain model.

If CRUD naturally fits your domain (or sub-domain) then you may go for a less rigorous architecture. For instance, you could used automated mapping (or explicit mappers) to map the command data to entities (getters & setter bags) in services.

You could also pass commands directly to entities and let it map values such as entity.update(command). I'm against that approach for rich models, but like I said for CRUD that's the kind of purity concessions you can make to remain pragmatic as you are mostly designing a glorified database editor.

plalx
  • 42,889
  • 6
  • 74
  • 90
  • 1
    Its not only CRUD, I have for instance a Customer aggregate root and Address and Contact as aggregate. So using methods on the aggregate root I am managing does child aggregates. Also for instance SalesInvoice where I have methods to Publish an invoice or SetCustomer for setting the customer on an invoice and so on. Its just that we also have some normal CRUD tasks also like updating some main properties of a Customer. Should I then move away from DDD just because of this? – Mivaweb Jul 15 '21 at 07:25
  • 1
    Found another thread [here](https://stackoverflow.com/questions/33698225/ddd-guidance-on-updating-multiple-properties-of-entities) where you marked some pointers that helped me understand DDD more. In my example I could better have a UpdateCustomerContactDetails command to update phone, email, etc. and another for update the billing address. – Mivaweb Jul 15 '21 at 08:33