Intrigada e inspirada pelo Domain-Driven Design (Desenvolvimento Guiado por Domínio), ou DDD, mas com uma grande experiência em Data-Driven Development (Desenvolvimento Guiado por Dados), Julie Lerman lutou, discutiu e lamentou até que conseguiu utilizar suas habilidades com DDD. Lerman, que é uma MVP da Microsoft desde 2003 e trabalha como consultora e mentora na plataforma .NET, supõe que vários desenvolvedores passam pela mesma luta. Este é o motivo dela compartilhar as lições aprendidas em três artigos na revista MSDN.
Lerman enfatiza que DDD serve para comportamentos mais complexos, algo que não existe em algumas partes de uma aplicação. Para módulos de uma aplicação que fazem uma simples criação, leitura, alteração e deleção de um determinado objeto no banco, ou seja CRUD (create/read/update/delete), pode-se escolher uma abordagem que não seja DDD. Porém, para módulos que possuam um comportamento mais complexo além de um CRUD, a sugestão da Lerman é que se identifique as partes complexas e separe-as aplicando DDD somente nestas partes do software.
Ao pensar em DDD para modelar o domínio de uma aplicação, Lerman foca no negócio, trabalhando com as tarefas e comportamentos necessários. Segundo Lerman, a persistência de dados não está relacionada com os problemas das regras de negócio do software, sendo assim, não interfere tanto no projeto do domínio.
O compartilhamento de tipos de dados em diferentes sub-sistemas é algo que Lerman não concorda. Ela sempre achou que compartilhar tipos era obrigatório, inclusive trabalhando com a mesma tabela no mesmo banco de dados. DDD mostrou para ela que é perfeitamente aceitável NÃO compartilhar um modelo de domínio, sendo assim, pode-se armazenar o mesmo tipo de dado de diferentes sub-sistemas em tabelas diferentes de bancos diferentes. Ou seja, duplicar dados não é um crime; inclusive com o passar do tempo pode simplificar seu sistema ao remover a necessidade de compartilhar dados.
Em suas reflexões finais nos artigos, Lerman examina alguns problemas que ocorrem ao utilizar ferramentas de ORM, no caso dela o Entity Framework. Um problema é o de relacionamentos uni-direcionais, que é a maneira predileta de relacionamento entre entidades quando se trabalha com DDD. Eric Evans, o autor de livro original de DDD, aconselha que "é importante para restringir os relacionamentos, o tanto quanto possível", porém a forma de relacionamento que Lerman tem usado desde que começou a trabalhar com Entity Framework foi o bi-direcional. Agora ela acha que, embora sejam convenientes, os relacionamentos bi-direcionais raramente são necessários para o domínio e remover este tipo de relação pode diminuir algumas complexidades de manutenção de relacionamentos de entidades.
Os artigos da Lerman são acompanhados de um exemplo escrito em C# e também utiliza o Entity Framework, a ferramente da ORM da plataforma .NET da Microsoft.