Durante a DDD Exchange deste ano, ocorrida em Londres, Eric Evans abordou como modelos são temporários e a necessidade de desafiá-los a fim de encontrar pontos fracos. Eric rebate alguns enganos de suas análises sobre Design Orientado a Domínio (Domain-Drive Design), por exemplo, o fato de programação orientada a objetos ser mandatória ou blocos táticos como repositórios sejam uma obrigação. Nenhum destes itens são realmente pressupostos do DDD.
O primeiro desafio para muitos projetos de software é complexidade do próprio domínio.
Eric acredita que na maioria dos projetos isso seja verdade apesar de haver exceções; um exemplo são os projetos nos quais o modelo utilizado é realmente baseado em CRUD e uma descrição de schemas de banco de dados. Mas adicionar lógica de negócio como um emaranhado de condicionais aumenta o risco de terminar com um software monolítico e uma grande bola de lama (sobre bolas de lama).
Negócio e software podem colaborar em conceitos mal compreendidos.
A cultura de pessoas de negócio comparada com a cultura de pessoas técnicas são normalmente muito diferentes e a forma como as organizações se estruturam não facilita a colaboração entre elas. Encontrar desenvolvedores que conheçam bem o domínio de negócio pode ajudar nesta falta de interação. Se a colaboração não funciona, como possível alternativa Eric cita a prototipação rápida, tendo as pessoas de negócio rejeitando ou solicitando mudanças no protótipo. A forma mais extrema dessa ideia é trocar um sistema inteiro, mas Eric aponta o risco associado. Apesar de construir um sistema inteiro tendo a mesma funcionalidade como um sistema legado não é tão complexo, na maioria das vezes as dores de cabeça residem nos problema de migração, quando todas as peculiaridades nos dados devem ser migradas para o novo modelo.
O Domínio de Negócio é bastante relevante para o negócio, então foque nele
De acordo com experiência de Eric, as equipes as vezes sentem dificuldade para encontrar o domínio central. Como consequência, torna-se ainda mais difícil encontrar colaboradores. Uma alternativa para estes cenários seria desenvolver com maior velocidade assim não seria necessário focar em partes, mas Eric acha isso impossível.
Uma reação negativa que Eric tem visto nas pessoas que obtém sucesso ao criar um modelo simples para um problema complexo é o fato de não ser apreciado, pois outras pessoas tendem a ver somente o modelo e não a realidade complexa de negócio descrita pelo modelo.
Alinhar implementação com o modelo melhora a utilidade e velocidade da entrega
Eric faz uma analogia a caixa de câmbio automática de um carro como um exemplo de bom encapsulamento. A implementação, no interior, é completamente diferente da apresentação exterior. No contexto de software isso pode corresponder à dois diferentes contextos; tendo a parte do contexto interno voltada a especialistas de domínio. O que realmente estamos tentando é encontrar um modelo que seja tanto compreensível pelo negócio quanto praticável na implentação, e isto foi sempre uma premissa do DDD.
Tecnologia não é o problema
Expressar uma linguagem ubíqua em código é algo que Eric normalmente faz com sucesso, porém definir contextos delimitados (context bondaries) e gerenciar agregações são tarefas muito mais complexas, normalmente fazendo com que Eric volte ao convencional. Apesar disso, Eric acha que o desenvolvimento de software está bem melhor do que à dez anos atrás.
Modelar está profundamente ligado com a fala e a língua
Eric não está certo se este é um requisito absoluto porém é muito a sua maneira de fazer DDD. Modelos gráficos e matemáticos são alternativas porém Eric acha que ainda seja DDD. Uma das barreiras da qual Eric ainda não vivenciou foi pessoas falando diferentes línguas em um projeto, por exemplo, inglês e sueco, porém lidar com isso pode ser um problema.
Estruturas (como padrões do DDD e língua) ajudam as pessoas que modelam a trabalhar
Eric sugere que algumas pessoas conseguem modelar naturalmente e possuem um talento para abstração. Saber DDD não é um requisito para estas pessoas, mas Eric acredita que elas poderiam trabalhar de forma mais sistemática e utilizando um vocabulário comum entre elas a fim de melhorar o trabalho, apesar de Eric não ter provas sobre isso.
Eric termina a apresentação com a seguinte mensagem:
Tanto DDD, como com qualquer outro modelo, os desafios são a base que o mantém saudável. Voltando aos princípios várias vezes, pode-se adaptá-lo. Assim é possível ter um entendimento mais claro e conciso, a fim de tornar o DDD funcional a outras condições. Caso o DDD não se aplique a tais desafios, então ele não deve ser um obstáculo.
A próxima edição da DDD Exchange está marcada para 19 de julho de 2015 e as inscrições já estão abertas.