Identifique os elementos de design arquiteturalmente significantes

Considere cada cenário de alta prioridade que está dentro do escopo do projeto. Percorra as ações que o cenário inicia, e destaque as áreas da arquitetura que são fatores da realização ou implementação dos requisitos.

A identificação de componentes irá ajudar a esconder a complexidade do sistema e o ajudará a trabalhar em um nível superior. Os componentes precisam ser internamente coesos e fornecer serviços externos através de uma interface limitada. A identificação dos componentes pode ser baseada nas camadas arquiteturais, escolhas de implantação ou nas principais abstrações. Faça estas perguntas para si próprio:

O que está logicamente ou funcionalmente relacionado (o mesmo caso uso ou serviço, por exemplo)?
Quais entidades fornecem serviços para vários outros serviços?
Quais entidades dependem umas das outras? Fortemente ou fracamente?
Quais entidades você deve ser capaz de trocar independentemente das outras?
O que será executado no mesmo processador ou nó de rede?
Quais partes estão restritas por semelhantes requisitos de desempenho?

Cada componente inclui entidades do domínio do problema, classes de controle que coordenam tarefas complexas dentro dos componentes e interfaces que gerenciam a comunicação com o ambiente. A interface para cada elemento instanciado está identificada. Neste ponto, as interfaces não precisam ser tão detalhadas como as assinaturas, mas elas precisam documentar a necessidade dos elementos, o que eles podem usar e o que eles podem ser dependentes.

Os padrões identificados definem os tipos de elementos, mas não uma quantidade específica. Aplique os padrões escolhidos para definir um novo conjunto de elementos que estejam em conformidade com os padrões. A funcionalidade será atribuída aos elementos instanciados.

Associe o software ao hardware

Produza uma associação precisa dos componentes de software implantáveis aos nós de rede.

Defina as arquiteturas de desenvolvimento e teste

A configuração dos ambientes onde o sistema será desenvolvido e testado pode ser diferente do ambiente de produção, e isso pode ter um impacto sobre a solução. Por exemplo:

Pode ser necessário o desenvolvimento de software adicional para suportar os testes.
Pode ser necessário definir configurações alternativas de implantação para ambientes diferentes, em resposta às restrições do hardware de desenvolvimento e testes.
Múltiplos ambientes podem ser necessários para suportar diferentes categorias de testes (tais como testes de desempenho ou de aceitação pelo usuário). Estes terão que ser especificados.

Estes cenários, embora não seja desejável, muitas vezes são impostos à equipe através de várias restrições. Consequentemente, a arquitetura para estes diferentes ambientes terá que ser especificada com especial atenção para diferenças significantes. Certifique-se de considerar o impacto de qualquer diferença na qualidade da arquitetura de produção global.

Valide a arquitetura

A forma mais segura de validar a arquitetura é através de software. O software desenvolvido até o final da fase de Elaboração é altamente direcionado para validar a arquitetura (até o ponto em que possa ser colocado em linha de base), proporcionando certo nível de estabilidade durante a fase de Construção.

Ele também pode ser útil para efetuar validações simples, percorrendo os principais conceitos e modelos de design, talvez usando um quadro branco ou outras técnicas colaborativas. Isso pode ajudar a refinar a concepção, mas não será um substituto para a construção de algum software.

Comunique as decisões

Você pode documentar e comunicar suas decisões de várias formas, por exemplo:

Publicação de código fonte de referência
Publicação de modelos de referência
Publicação de documentação da arquitetura de software
Apresentações formais do material
Demonstrações informais da arquitetura