There seems to be a mindset that "DTO" is sacrosanct, clouding the OP's impulse to apply Single Responsibility principle due to conflating DDD framework and business domain model. Make a proper object of data AND function/behavior. Of course a proper domain object is still that if it has a method returning a DTO - a generic, non business/domain utility thing.

Thus the domain object is decoupled from any specific respository making other refactoring goals possible.

There seems to be a mindset that "DTO" is sacrosanct, clouding the OP's impulse to apply Single Responsibility principle due to conflating DDD framework and business domain model. Make a proper object of data AND function/behavior. Of course a proper domain object is still that if it has a method returning a DTO - a generic, non business/domain utility thing.

Thus the domain object is decoupled from any specific respository and the DDD framework more generally, making other refactoring goals possible.

There seems to be a mindset that "DTO" is sacrosanct, clouding the OP's impulse to apply Single Responsibility principle due to conflating DDD framework and business domain model. Make a proper object of data AND function/behavior. Of course a proper domain object is still that if it has a method returning a DTO - a generic, non business/domain utility thing.

There seems to be a mindset that "DTO" is sacrosanct, clouding the OP's impulse to apply Single Responsibility principle due to conflating DDD framework and business domain model. Make a proper object of data AND function/behavior. Of course a proper domain object is still that if it has a method returning a DTO - a generic, non business/domain utility thing.

Thus the domain object is decoupled from any specific respository making other refactoring goals possible.