I’m trying to apply some DDD-like patterns to the code I write to use it as an example of how to write good code. We already have a bunch of classes that represent the domain objects, but most of them “know too much” and have both logic, getters/setters and data access (in the form of untyped DataSets) strewn throughout them.
For this portion of the application, I need to use the same domain object but with a small subset of the data returned that makes it unwieldy to use the “fat” object (for instance let’s say the “fat” object has 20 properties and methods and I only heed to work with 7 properties for this portion). Is it acceptable for me to create a lean DTO-style object with the same name (in a different namespace/package of course) with only the properties that I need? I seem to recall this was a good practice in the DDD world but I cannot remember for sure (something to do with bounded contexts, as I recall?) and I would hate to pollute my design.
I’d be wary here with what it is you’re trying to achieve. For it to be truly domain driven, your Entities should be rich in functionality and not an “anemic” domain model
So if you find yourself in a situation where you “need to use the same domain object but with a small subset of properties”, what exactly is using the Domain Object in this scenario.
Is it just being used as a DTO and being handed around to other manager classes which contain the actual functionality.
If that’s the case you may want to revisit your design to see if it’s truly domain driven.