Ao usar a filosofia e as práticas centrais do Domain Driven Design (DDD) como diretrizes para o design e desenvolvimento de software, podemos resumi-las em três princípios: Capturar - Incorporar - Proteger.
Foi o que Steve A. Lower afirmou em sua apresentação no DDD eXchange deste ano . Devemos capturar o modelo de domínio entendendo o suficiente para tomar ações positivas. Devemos incorporar o modelo no código e nas conversas. Devemos proteger o modelo de domínio da corrupções de outros domínios , especialmente os técnicos.
Para Lowe, Principal Consultant da Thoughtworks, o DDD foi um avanço quando surgiu porque destruiu a obsessão com os modelos de dados empresariais e os substituiu por modelos cooperativos com foco em domínios, independentes e sobrepostos. Ele enfatiza que o DDD mudou o foco e o escopo no desenvolvimento de software do ponto de vista técnico para que os objetivos de negócios guiem nossa exploração e soluções. Ele acredita que o DDD ainda sofre com alguns "mitos", mas afirma que eles são todos falsos:
- DDD é difícil. Não! DDD requer foco e autodisciplina, mas programação é indispensável.
- DDD traz sobrecarga. Somente se você achar que aprender sobre um domínio é desnecessário.
- DDD é apenas para domínios complexos. Eles podem precisar mais do DDD que outros cenários, mas a mentalidade é sempre apropriada para qualquer situação.
O objetivo do capturar é tornar um modelo mental do domínio visível e interativo para que todos possam concordar com isso. Uma maneira de criar modelos que Lowe recomenda é fazendo com que todos se envolvam em uma sala e depois se concentrem nos eventos no domínio. Esta é uma técnica chamada "Event Storming", uma abordagem de modelagem de grupo criada por Alberto Brandolini, que Lowe acredita ser extremamente poderosa, uma maneira de maximizar a velocidade de aprendizagem com o mínimo esforço.
Ao incorporar um modelo de domínio no código, duas partes importantes estão nomeando coisas para que elas reflitam as intenções do domínio e componham coisas para que elas reflitam o comportamento do domínio. Lowe observa que, se você não conseguir um bom nome para uma coisa, então talvez você não entenda bem o que está nomeando. Como a documentação e os diagramas podem estar desatualizados, o código é a única fonte confiável de verdade. Ao incorporar o modelo de domínio no código, o modelo sempre estará correto e estará disponível para os desenvolvedores. Em um nível alto, o código também pode ser lido e compreendido pelos especialistas do domínio.
Para proteger um domínio de ser corrompido, usamos limites para separar subdomínios uns dos outros. O limite de um contexto é a sua interface, ou seja, os comandos e eventos que entram e saem. Mas a força do limite também é importante: qual o tipo de validação e tradução feita na interface? Uma forma prática de proteção é usar módulos para separar subdomínios fisicamente. As vantagens incluem uma base de código menos acoplada e mais resiliente. Lowe observa que não adicionar uma dívida técnica em primeiro lugar é mais fácil do que removê-la mais tarde.
Lowe concluiu enfatizando que capturar - incorporar - proteger é um processo iterativo com cada passo feito várias vezes, aumentando gradualmente o modelo de domínio a partir de modelos menores já validados. Ele também ressaltou a importância de tornar o pensamento de design orientado por domínio de forma onipresente se você não modelar o domínio intencionalmente, você irá modelar outra coisa qualquer de forma involuntária.