My advice: just think of it as “dumb” data, nothing else. If you need to ensure invariants, create some kind of wrapper around it.
My thought is that the domain object would wrap the DTO, and the DTO is only holding the state. Only the domain object, which understands the invariants and business rules, should be able to write to the DTO. Cheers, =David > On Aug 18, 2016, at 9:54 PM, David Daniel <[email protected]> wrote: > > I just realized that I was replying on the dev list and I definitly fall > more into the user seeking help range so I am moving the conversation to > the user list so other users can learn with me. The context of the > conversation was in regards to what should DTO's be used for. > > -------------------------------------------------------------------------------------------------------------------------- > > So copy could work for immutability but it limits my ability to help the > client (which is normally me and I am definitely stupid enough to not think > about how I designed the system) but it doesn't help with how to add > mutability of data objects transferred between services. I do think I may > be trying to do too much with DTO's but I am still trying to wrap my head > around where they should be used. Do I just use them as pojo's that come > in and out of services and then immediately convert them to domain specific > objects or do I let them stick around and try and make use of them. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
