No it shouldn't be. indeed you shouldn't have a service layer in DDD as your logic is in the Domain.

How to fix:

1. Delete the DTO, Entity and Service classes.
2. Make a Repository in your Data layer that handles the mapping of a domain object to a database and back. any mapping classes or entities you need for your DRMs should be internal/private to this library/class
3. Use the same framework that currently maps incoming json to DTOs to map incoming json to Domain Models
4. Change the IDs to GUIDs so you can give new objects unique IDs without a database connection.

Your controller then becomes:

@RestController @RequestMapping("/api/orders") @AllArgsConstructor public class CustomerOrderController { private final CustomerOrderRepository repo; @PostMapping public void SaveOrder(@RequestBody CustomerOrder order) { repo.Upsert(order) } } 

If you have actual logic rather than just CRUD to perform you have a choice.

1. Add the logic to the Domain Object. ie CustomerOrder.Invoice()
2. Add the logic to a Domain Service ie InvoiceCreator.CreateInvoiceFor(CustomerOrder order)

No it shouldn't be. indeed you shouldn't have a service layer in DDD as your logic is in the Domain.

How to fix:

1. Delete the DTO, Entity and Service classes.
2. Make a Repository in your Data layer that handles the mapping of a domain object to a database and back. any mapping classes or entities you need for your DRMs should be internal/private to this library/class
3. Use the same framework that currently maps incoming json to DTOs to map incoming json to Domain Models
4. Change the IDs to GUIDs so you can give new objects unique IDs without a database connection.

Your controller then becomes:

@RestController @RequestMapping("/api/orders") @AllArgsConstructor public class CustomerOrderController { private final CustomerOrderRepository repo; @PostMapping public void SaveOrder(@RequestBody CustomerOrder order) { repo.Upsert(order) } } 

If you have actual logic rather than just CRUD to perform you have a choice.

1. Add the logic to the Domain Object. ie CustomerOrder.Invoice() If you do a lot of this you might find you need DTOs again and have more than one Domain Model, ie Warehouse.CustomerOrder, ECommerceWebsite.CustomerOrder. But it's more OOP and DDD
2. Add the logic to a Domain Service ie InvoiceCreator.CreateInvoiceFor(CustomerOrder order) keep your Domain Models anemic data structs. good for reuse