0

I'm thinking of not keeping user orders as separate Aggregate instances, but combine them into one UserOrders. Is such an approach going to have some flaws in terms of DDD? Along with orders, I would keep the deliveries (that can spread across the orders) and payments info.

There is probably will be not many orders created by the user 1-4 per year.

1

The problem with this approach is that there is a limit to the amount of memory a computer can have and no limit to the number of orders a customer can make.

You will "probably" be ok with the low level of orders, but in 5 years time why will you want to load 20 previous orders, with potentially all their related delivery and payment info, every time you want to load a customer?

Imagine you have a microservice that processes orders. How many customers will be in memory at a time? How long will it take to load a Customer from the database? Or transmit a serialised copy over the network?

The smaller you make the objects the less that microservice costs to run. Its not a day 1 worry, but you should have these things in mind when you are designing stuff.

  • Yes I believe you are right. Thanks) – WHITECOLOR Jun 8 at 9:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.