I'm reading OO DDD slides from Robert Brautigam, who is quite active here so I hope he can personally answer as I quite agree with his personal understanding of DDD, and approach of having a more object oriented approach instead of a service one.
In our apps we have an awful lot of this:
class OrderService {
OrderRepository _orderRepository;
Future<void> confirmOrder(Order order) {
final confirmedOrder = order.confirm(); // we use immutable entities
return _orderRepository.save(confirmedOrder);
}
}
class DBOrderRepository {
Future<void> save(Order order) => db.save(order.toJson());
}
The service seems unnecessary because the domain object, Order in this instance, is doing the work to update the fields it needs to and the service just saves the result. For most use cases where there is only one entity involved it seems like the service layer is very thin and might not need to actually exist at all ? That the call could be made directly inside the domain object, which I think is what OP of the slides alludes at. I understand there is an argument for unit testing each part individually and maybe a single responsability principle, but I'm not convinced those 2 arguments hold.
In slides 31 and 32 he gives 2 options. He eliminates the services, but where the entity is saved to persistence is not clear.
In slide 32:
class Order {
Json toJson();
static Order fromJson();
My problem with this is that implementation details are leaking out of the Order, but most importantly the Order is not persisted. You'd still need a service to call the repository eg the same snippet as I have above (it's the method that we currently use):
class OrderService {
OrderRepository _orderRepository;
Future<void> confirmOrder(Order order) {
final confirmedOrder = order.confirm();
return _orderRepository.save(confirmedOrder); // <== this needs to be called somewhere ?!
}
}
class DBOrderRepository {
Future<void> save(Order order) => db.save(order.toJson());
}
