mORMot Open Source

macfly

Member

From: Brasil

Registered: 2016-08-20

Posts: 374

DDD rules

I have Customers and Orders.

A customer can have none, one or many orders.

In this case, is it OK to have the Customer persisted individually ? Or it breaks the DDD rules?

In this case:

TCustomer = (TSynPersistent); //Mapped to TSQLCustomer

TOrder = (TSynPersistent) //Mapped to TSQLOrder
  property CustomerID;
end;

And a class used only to transmit the complete order:

TResultOrder = (TSynPersistentAutoCreate...)
  property Customer : TCustomer;
end;

Another option would be to have both entities persisted, but in this case an update from a Customer would make it necessary to change all of his orders. Would this be correct too?

In this case:

TCustomer = (TSynPersistent); //Mapped to TSQLCustomer

TOrder = (TSynPersistentAutoCreate...) // Mapped to TSQLOrder
  property Customer : TCustomer;
end;

  Update(Customer);
  SelectAllCustomerOrders(Customer.ID);
  while GetNext do
   Order.Customer := Customer;
   Update(Order);
  end;
  Commit;

Last edited by macfly (2020-05-15 16:43:31)

ab

Administrator

From: France

Registered: 2010-06-21

Posts: 14,655

Website

Re: DDD rules

In DDD you don't persist "Customer" in abstract.

In DDD you use Aggregates as persistence, for a given bounded countext.
For instance, you define a "Customer with its last orders" aggregate, or a "Customer detailed information when editing taxes" or a "Customer with all its contact history"...
So the same fields may be duplicated.

Please read the documentation and the DDD presentations you may find.

macfly

Member

From: Brasil

Registered: 2016-08-20

Posts: 374

Re: DDD rules

But isn't TOrder and TCustomer my aggregates in the code above?

Believe me, I read the documentation several times.

The above question appeared after reading the documentation and some topics here on the forum.
Also i have played with the Samples.

ab

Administrator

From: France

Registered: 2010-06-21

Posts: 14,655

Website

Re: DDD rules

In your context, you need a TCustomerWithOrders aggregate.

Then

1. either you persist it as a single record in the database (this is what we usually do)
For instance, a TSQLCustomerWithOrders.
You can use the automated aggregate flatenning of mORMotDDD.pas for this.

2. or you may use some separated TSQLRecord:  TSQLCustomer and  TSQLOrder and TSQLCustomerOrder and make a relational link between the 3 via manual SQL.

But you don't "store both entities".
You store only aggregates, in which you have nested entities.

macfly

Member

From: Brasil

Registered: 2016-08-20

Posts: 374

Re: DDD rules

Thanks for the tips, made it more clearer.

Another doubt is that to consume the service only by Ajax clients, I need to create a interface-based service, o top of that, correct?

The application will have these layers:

- Interface-based service, that uses:
- DDD implementation to store the aggregates, that uses:
- ORM, that uses:
- Low level DB access

Sample 35 would be more complete if this last layer were included.
At least in my case I never used the framewok to be consumed by Delphi / FPC clients.
And I believe that the tendency is to be used less and less.