Saiu uma entrevista interessante no InfoQ com um cara chamado Greg Young, onde ele discute algumas boas práticas de DDD que ele adotou em seus projetos.
Fonte: http://www.infoq.com/interviews/greg-young-ddd#
Algumas coisas interessantes que ele falou:
:arrow: i only use domain driven design on appropriate projects. Domain driven design is a hard thing to get done and get done right. It is costly and you are going to end up spending a lot of time on it. Most systems that are out there don’t have a cost function that allows for domain driven design to be done. If you are dealing with a project that is being done in less than a year, chances are it’s probably not a project you are looking to do domain driven design on.[/i]
Ou seja, nem todo projeto é passível de usar DDD. Mas isso você já sabia, claro 
:arrow: I mentioned before that I personally like dealing with valid objects and I also really like to not have any getters or setters on my domain objects, I prefer to have behaviors. Well, there is a big problem with that and people are going to say “What happens when I’ve got the customer and I need to display information about it on the screen?” My comment would be “Do you really need your domain object to do that or can we have some customer object, which actually represents a data transfer object to the screen?”
De início, a tendência é não concordar muito com isso. Pra que criar um DTO pra exibir dados na tela só pra satisfazer o purismo de não ter getters nas entidades? Mas ele se explica melhor depois:
:arrow: I’m probably going to have to come back to that a little bit - this is a big part of my talk tomorrow as well. When I say mapping to DTOs, I don’t mean mapping the domain to DTOs, I mean mapping the underlying data source to DTOs. -It’s a lot easier to explain this with a whiteboard -. What we end up with is we have a very simple layer - let’s imagine it is a web service - where I can say “Get me a customer”. It goes directly to database - I don’t care how it does it - and we have some form of shared customer DTO. The data that gives me back does not match up to my structure and my domain, it maps up to how I want to use the data in - let’s say - my interface.
É aqui que você começa a entender. No exemplo do WebService que ele deu, por que você criaria um Domain Model - ou passaria por um já existente - só pra obter dados da tela quando você pode pedir direto ao banco de dados?
Mas… Mesmo após esses argumentos, continuo com meus getters das entidades :oops:
Em um determinado momento, um dos espectadores pergunta a ele: “Are you suggesting that you only convert to the internal domain model when you write stuff?”. Eis a resposta:
:arrow: [i]Absolutely, and it is a very common system architecture in general. If we were to look at a typical domain driven design based architecture, we would have - let’s say - an application service sitting there. This application service is going to have probably some query in methods - things like I need to get customer information, so I can put up on the screen, that’s why I’m going to have some command methods “I need to change this customer’s address, too”. All the command-query separation is to recognize that these 2 things exist and to separate them. They both do not need to go to the domain.
Whereas the first one was going directly to a domain for the queries, we are just going to pull that across and we are only going to have our thin little DTOs, which we had before, but now we are going to populate them directly from some data source. It may or may not be the same data source that we write to. There may be 2 data sources and they may or may not be eventually consistent. Even if we start off with this single data source, we know that we have this ability to move towards an eventually consistent architecture layer, which will allow us for a large amount of scalability, if we needed that at a later point. Beyond that we’ve cleaned up our domain in terms of making a transactional only on the write side now. Our domain ends up cleaner, our DTO layer ends up cleaner and let me just say I would hate to be the junior programmer who has to write all the DTO mapping code - It’s a pain! Been there, done that.[/i]
Abraços.