Hi, Alex Soong thank you for your message.

I totally agree that there are different approaches. Personally, I don’t think that one is better than the other but rather on how much effort or simple you want to keep your code. It’s also a matter on the context that you are working on.

On bigger applications, you don’t probably want to query and return all your entities. Imagine the example below:

class SomeRepo
def get_entity; end # this will return a complex valid entity with all its relationships
def get_partial_entity; end; # this will return you entity but not fully initialized wich means that some components will be missing. def get_other_partial_entity; end # same hereend

The above example is a repository where you return different states of an entity based on the client’s need. From a DDD perspective, the above is wrong since it violates the entities invariants (normally that would be an aggregate root). Each entity in its whole life cycle should be valid and keep its constraints and invariant all the time. That does not apply in our case since we return a partially initialized entity.

Maybe in your case, other architectural patterns like CQRS would be a better approach where write and read operations are separated. In any case, I prefer to return DTOs instead of entities when we come to the above situation.

I will try to find some time and finish the article and follow up in a separate post regarding some possible implementations.


Written by

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store