Começar um novo projeto escolhendo primeiro a tecnologia e framework, e então voltar-se para o problema do projeto, pode ser bastante perigoso. Jeppe Cramon falou sobre esse assunto em uma recente apresentação em Aalborg, na Dinamarca. Ao invés disso, Cramon prefere a arquitetura a ser relacionada ao negócio e mostrando os principais conceitos, como: a venda, o transporte e a entrega de um produto.
Durante a criação de uma arquitetura, Cramon, um arquiteto independente que trabalha com sistemas de larga escala de integração, distingue entre macro e micro arquitetura, sendo no nível macro: o foco sobre o domínio das responsabilidades ou capacidades e na separação de questões de negócio não relacionadas. É importante também a integração de protocolos e o monitoramento de aspectos relacionados à infraestrutura. E no nível macro: o foco é sobre a linguagem de programação, frameworks e os padrões do projeto. Cramon observa especificamente a diferença no ciclo de vida de um projeto, que encontra-se mais no nível macro.
Para Cramon, o trabalho inicial com uma macro arquitetura é importante, devido ao refatoramento do nível macro ser muito mais trabalhoso do que no nível micro. Cramon recomenda de início a criação de uma equipe funcional com um arquiteto, desenvolvedores, analistas de negócio e outros profissionais que venham a ser necessários, a fim de que seja gasto pouco tempo com foco em requisitos e estimativas. A seguir, outras recomendações:
- Iniciar com recursos externos e modelo de negócio;
- Identificar o negócio de domínio;
- Projetar a macro arquitetura em torno do domínio identificado;
- Determinar os princípios de comunicação e integração;
- Garantir o monitoramento e registros comum das instalações.
Cramon acredita que o DDD (Domain Driven Design) auxilia em conceitos como linguagem ubíqua e delimita contextos para criar modelos pequenos e separados com clara propriedade de dados.
Melhorar a arquitetura interna, essa é uma crítica de Cramon aos sistemas construídos com CRUD, querendo se afastar da tradicional interface do usuário focada em "que" o usuário faz, com base em uma interface no "como" o usuário quer utilizar uma aplicação. Por esses e outros motivos é que Cramon acredita que o CQRS se encaixa bem, capturando as intenções dos usuários e as informações relevantes para ele. Trabalhando com CQRS, outros conceitos de DDD, como um conjunto de objetos associados, chamados de agregados e eventos de domínio, também são relevantes.
Agregados são conjuntos coerente de entidades e objetos de valor que devem sempre ser consistentes. Um comando só deve visar um agregado dentro de uma única transação, garantindo a consistência desejada.
Eventos de domínio são sinais de que algo significativo aconteceu nesse domínio, como um comando tenha se transformado em agregado. Os CQRS também podem ser utilizados para atualizar os modelos de consulta em uso.
Em Breaking monolith, Stefan Tilkov sugere quebrar um sistema dentro de muitos subsistemas, separando a macro e a micro arquitetura.
Em sua apresentação, Cramon diz que a arquitetura deve ser sobre intenções, não sobre frameworks. Robert C. Martin, acredita que o foco está demais nos detalhes e com isso são o centro dos sistemas.