Como eu paro de projetar e começar a arquitetar este projeto como sugerido pela minha liderança? [fechadas]

Primeiro de tudo, eu diria que a diferença entre arquitetura e design é principalmente semântica. Algumas equipes têm pontos de verificação entre os dois. Seu líder técnico define a arquitetura como antes do design e arquitetura como implementação agnóstica. A partir disso, presumo que estamos falando de design, como no modelo em cascata e não em Design industrial, que ajudaria você a projetar o produto com vistas aos usuários antes de chegar à arquitetura do software. Eu acho que a arquitetura muitas vezes entra no design e isso não é necessariamente uma coisa ruim, muitas vezes é muito útil para o arquiteto ter um conhecimento profundo do que é possível dentro do sistema em questão.

Tendo dito tudo isso, você precisa de alguns conselhos para a situação em que se encontra. Há um mundo inteiro de arquitetura de software por aí, papéis, livros, conferências, mas você geralmente está procurando por padrões e abstrações. Sem mais detalhes sobre o projeto, só posso dar um exemplo amplo. Por exemplo, se você estava trabalhando em integração, há a Arquitetura Orientada a Serviços ( SOA ) onde você divide partes do sistema em 'serviços' para que você possa trabalhar com cada parte de forma definida, no programa web isso é frequentemente implementado como Web Services (embora não deva ser limitado a isso ) e mais recentemente o surgimento de APIs RESTful com JSON, novamente eu diria que este é um design vindo da arquitetura SOA. Eu diria que o Model, View, Controller (MVC) é outro exemplo de um padrão de arquitetura de uso comum, dividindo a responsabilidade dos componentes de um sistema para permitir que partes sejam trocadas, para conter erros e testes.

A partir de um nível de 10.000 pés, se você puder desenhar em um quadro branco e explicá-lo a um programador competente que não trabalhe em seu campo e não conheça sua linguagem de programação e os detalhes atuais da implementação, provavelmente é arquitetura. Se você pode escrever um livro sobre isso que qualquer pessoa fora de sua empresa se preocuparia, então provavelmente é arquitetura. Se você encontrar o seu próprio detalhe explicativo e não puder generalizá-lo para outras bases de código / empresas / indústrias, então provavelmente é design.

Eu concordaria que os dois exemplos que você dá são design de código e não arquitetura. O primeiro porque eu acho que quando você diz que você criou um 'algoritmo' para carregar recursos, eu acho que você quis dizer que você criou um conjunto de instruções para realizar essa tarefa, e não que você projetou um novo algoritmo que eles estarão ensinando no primeiro ano. COMSC no próximo ano. No segundo exemplo, novamente eu concordo que é design. Se você me mostrasse essas idéias, eu não conseguiria usá-las no meu projeto de software aleatório. Você tem que ir para um 'nível superior', Orientado a Objetos (OO) em Java, em vez de eu querer que a Classe do Cliente seja uma subclasse da Classe Person. Até mesmo falar sobre Exceções em geral poderia ser considerado de nível muito baixo (muito próximo da implementação).

Para tentar abordar os detalhes que você lista, acho que você deve pensar em como arquitetar um CMS baseado na web. O Wordpress tem um codex da arquitetura do site , onde eles falam muito sobre os detalhes da implementação do design, mas fica claro no post que a arquitetura principal deles Centra-se em torno de fazer Wordpress extensível com temas. Arquitetar uma interface clara para um tema de tal forma que pudesse ser escrito por alguém do lado de fora da empresa era claramente uma decisão de arquitetura que eles tomaram. Esses são os tipos de coisas que é bom colocar no papel ao arquitetar sua solução de "longo prazo" (não temporária) para que todas as decisões de design e implementação sejam feitas durante o desenvolvimento (por todos os desenvolvedores, não apenas pelo arquiteto). estão em linha com esta ideia.

Outros exemplos de arquitetura para sua situação:

1. Colocando a coisa toda em máquinas virtuais, hospedadas em um provedor de nuvem ou em casa e tendo instâncias de máquina sem estado, para que qualquer falha na máquina possa ser substituída por uma nova instância de uma máquina virtual sem ter que copiar em qualquer estado ou perder qualquer informação.
2. Criação de testes de falha de produção ao vivo desde o início com caos simies .

Talvez tente desenhar todo o sistema em um quadro branco. Experimente em diferentes níveis de detalhes, a primeira placa pode ser GUI > dispatcher > back-end > DB ou algo assim e, em seguida, detalhar até começar a usar os pronomes.

    

A distinção entre essas duas ideias é realmente importante onde eu trabalho.

O que você chama de "arquitetura", chamamos de "programação em inglês". Isso é parcialmente importante porque, se você não puder descrevê-lo para um não programador, algo está errado. Pode ser que você não entenda bem o problema, OU pode ser que você esteja resolvendo um problema "fantasma" (não discutido aqui).

Os termos usados para esses dois aspectos diferentes do design são muitas vezes diferentes, mas os princípios são facilmente reconhecidos em todos os lugares. Um aspecto (no seu caso, o arquiteto, no meu caso o designer) programas em inglês, enquanto o outro (no seu caso "designer", no meu caso "desenvolvedor") programas em um idioma específico. Eles também são bastante comumente distinguidos como "design" e "implementação". "Design" é o que deve ser feito e "implementação" é o código que faz isso acontecer.

Alguns exemplos do que eu trabalhei:

A arquitetura de um programa é: precisamos de um gerenciador centralizado ou hub para o qual possamos adicionar módulos facilmente. Esse gerente distribuiria eventos para todos os módulos registrados. Um módulo pode se registrar com o Event Manager e, assim, publicar eventos no restante do sistema e receber eventos com os quais se importa. Cada módulo tem uma "caixa de correio" que pode verificar e esvaziar como desejar. Isso nos permitiria acomodar novos módulos que ainda não sabemos que precisamos.

Nenhum código. Poderia ser escrito em qualquer idioma. A implementação não é ditada por esta descrição.

A arquitetura de outro projeto é: precisamos de uma forma confiável de iniciar e parar outros programas sem esperá-los. Poderíamos ter um gerente responsável por um programa específico. Podemos apenas dizer para iniciar ou parar o programa e o gerente cuida disso. Se este outro programa for solicitado a parar e não em um determinado período de tempo, o gerente sabe como forçá-lo a parar e limpar a bagunça. O programa não é iniciado ou interrompido por qualquer outra coisa, e o gerente pode ser perguntado se seu programa está sendo executado, parado ou aguardando para ser interrompido. Isso nos permite continuar com as outras coisas que precisamos fazer, enquanto ainda obtemos esses outros programas iniciados e interrompidos adequadamente.

Novamente, nada aqui determina a implementação, embora algumas implementações sejam claramente mais úteis do que outras.

A diferença entre design (o que chamamos de padrões ou implementação) e arquitetura (o que chamamos de design) é que um deles resolve um problema de codificação / implementação e o outro resolve um problema do mundo real .

    

Talvez isso ajude. Eu sempre vi a antiguidade de um engenheiro como uma questão de quão grande problema eles podem resolver por conta própria.

Grosso modo, para transmitir a ideia:

• Você pode dar a alguém novo para programar tarefas pequenas e contidas com muitas instruções explícitas sobre como a tarefa precisa se integrar a outras partes

• Um desenvolvedor de nível médio é alguém que pode fazer uma descrição de uma parte de um aplicativo e fazê-lo funcionar dentro do contexto desse aplicativo.

• Um desenvolvedor sênior pode criar um aplicativo de médio porte a partir do zero, dentro das restrições técnicas de uma loja.

• Um desenvolvedor mais experiente pode fazer isso e fazer escolhas tecnológicas ao longo do caminho sobre quais tecnologias usar para que ele funcione bem.

... mas essas não são regras rígidas e rápidas. E algumas pessoas saem do portão como "senior" IMHO, mesmo que tenham que passar algum tempo com um título diferente.

O que o arquiteto está pedindo é ver o problema de forma ainda mais geral do que isso. Se você tivesse que montar um número de aplicativos para fazer o sistema funcionar:

• De quais aplicativos e serviços você precisará?
• Quais partes interagem com os clientes e quais interagem entre si?
• Como eles se comunicarão?
• Onde eles armazenam dados?
• Onde estão os riscos de falhas?
• Como você fornecerá confiabilidade?
• Como você fornecerá segurança?

Então, em certo sentido, a arquitetura técnica é como uma arquitetura de construção. É o layout ou o plano. Ele mostra o que é necessário para as várias partes, como elas se mantêm juntas e tão importante quanto por que .

(BTW, eu tive uma curva de crescimento semelhante explicada a mim para arquitetos, variando de arquitetar uma família de aplicativos relacionados ou um conjunto de recursos muito complexos, para definir direção técnica para um grupo, para tomar decisões técnicas estratégicas para uma organização inteira.)

Dito isso, acho que a maioria dos engenheiros de todos os níveis precisa fazer algumas "arquiteturas" também. Não é uma linha brilhante. Parece que se você focar no Big Picture primeiro, e não ficar preso nos detalhes da implementação, estará mais alinhado com o que ele está procurando. BTW, a capacidade de ver o Big Picture, bem como os Little Details, é um grande trunfo nesta indústria, o que soa como uma grande oportunidade.

... Aqui está uma analogia. Vamos dizer que você é solicitado a criar uma Magic Black Box. Como engenheiro, você deve ficar obcecado com o funcionamento interno da Magic Black Box. Mas, como arquiteto, seu foco é diferente. Você pode espiar a caixa por curiosidade, mas espera-se que fique obcecado com tudo ao redor de todas as Magic Black Boxes.

Semelhante a essa analogia, você pode pensar na função de arquitetura como visualizar o sistema inteiro como a caixa mágica. Então, se pegar uma Gigantic Glass Box e colocar os clientes, os aplicativos do cliente, o firewall, a camada de serviço, o banco de dados e até mesmo os devops dentro, então, como arquiteto, você ficará obcecado sobre como fazer aquela enorme caixa de sistema trabalho bem .

    

A diferença exata entre "design" e "arquitetura" é um pouco subjetiva e existe alguma sobreposição. No entanto, esta é a diferença que eu entendo:

Arquitetura analisa conceitos de alto nível. Quem são os atores no sistema? Quais são os principais objetos e quais são responsáveis por quê? Quando penso em arquitetura, penso no Visio, não no código.

Por exemplo, um sistema de eventos pode ter um gerenciador de eventos que aceita eventos de entrada e os envia para manipuladores de eventos. A ideia de threads, assíncrona v. Síncrona e outros conceitos de nível inferior não entram em jogo aqui. O MVC é outro exemplo: detalhes específicos não são especificados no alto nível de como as três partes interagem, apenas que há três preocupações separadas tratadas por pacotes de código separados.

O

Design envolve prototipagem, esboço de interfaces de código, esqueletos de código, etc. Ele fica entre a arquitetura abstrata e o trabalho de "code monkey" de baixo nível.

Em uma estrutura de evento, o design pode dizer "um evento usa essa interface" e "há um conjunto de encadeamentos que o gerenciador de eventos usa para despachar eventos para os trabalhadores". Um design para MVC pode ser "use o Hibernate para o modelo, o Spring para o controlador e o GWT para a view".

Quando faço um trabalho de design, tenho interfaces de esboço e esqueletos de código e, em seguida, entrego os resultados aos programadores. Às vezes eu sou aquele programador. Mas são duas fases separadas, e ambas existem mais em direção ao concreto do que a arquitetura.

Colocar a arquitetura significa limpar sua mente do código e pensar em objetos em um quadro branco. Pense em objetos, pacotes, estruturas e no fluxo de mensagens entre eles. Se você está pensando em até mesmo uma linha de código, está fazendo errado. Não fique atolado em algo como "oh, essa mensagem poderia ser uma string, ou usar SOAP, ou qualquer outra coisa." Nesse nível, o fato de que a comunicação está ocorrendo é suficiente. Detalhes são irrelevantes.

    

If I can add anything here, it's that: don't think code. At all.

Não pense como você escreverá o código para realizar algo, mas pense no que o melhor método seria para realizá-lo . Sua descrição do que você precisa fazer deve ser independente de linguagem , então você estará falando de padrões de design - que são uma "linguagem" comum entre usuários de diferentes linguagens de programação - para discutir como avançar.

Para o seu caso de uso específico, mais questões arquitetônicas, na minha opinião, seriam as seguintes:

• Por que você está usando o MVC? É tudo que você sabe? Existem melhores padrões para usar? Por quê?
• Qual estrutura você usará e por que ?
• Como você dimensionará? Não em código, porque isso não importa ainda. Quais serão as condições para dimensionar horizontalmente? qual serviço (AWS) você usará para fazer isso?
• Como a autenticação será realizada? Não em código: você estará gerando um token único e aleatório em cada solicitação e verificando o token esperado? Não pense como você fará isso no código. Pense em por que você está fazendo isso - porque isso pode ser feito em praticamente qualquer linguagem da web.

Basicamente, não fale nada sobre código. Mesmo que você não saiba como fazer algo, quando há um testamento, existe uma maneira . Pense mais em como as peças do quebra-cabeça se encaixam melhor antes de se preocupar em realmente colocá-las juntas.

    

Pense em todas as operações (ou seja, casos de uso) que seu sistema pode executar. Para cada operação, documente o que acontece em termos do domínio do seu negócio para cada operação. Você deve falar apenas em termos do domínio do seu problema e não descrever detalhes de implementação. Desenhe um grande bloco e chame-o de Sistema. A combinação deste "grande bloco" e as descrições de operação é a arquitetura de sistema de nível mais alto.

Embora essa arquitetura de alto nível forneça um ponto de partida decente, ela não tem muito valor ao criar um sistema real. Você deve reduzir um nível de detalhe para transformar isso em uma arquitetura útil.

Então, você segue a mesma idéia geral da abordagem do "bloco grande", mas apenas começa a adicionar "sub-blocos" que são necessários para realizar cada operação. Esses "sub-blocos" são freqüentemente chamados de classes de domínio ou módulos. Eles são facilmente identificados usando as descrições de operação (da abordagem de grandes blocos) e desenhando diagramas de seqüência. Eles são chamados de classes de domínio porque não se destinam a ser classes "reais", mas destinam-se a descrever seu sistema em termos do domínio do problema de seu sistema.

O resultado final de criar todo o diagrama de seqüência e identificar todos os "sub-blocos" é que agora você tem uma lista de classes de domínio e suas listas de operações. Isso geralmente acaba resultando em uma arquitetura de software razoavelmente utilizável, onde cada um dos "sub-blocos" / módulos pode ser distribuído para desenvolvedores diferentes para projetar e implementar.

Claro, se você deixar como está, seus designers terão muita interação uns com os outros na definição das interfaces entre os módulos. Assim, o arquiteto também pode decidir sobre os mecanismos de interface específicos e os tipos de dados a serem usados entre os módulos.

Além disso, alguns "sub-blocos" ainda serão muito complicados por baixo do capô. Assim, uma outra iteração da abordagem "sub-block" pode ser necessária, mas só desta vez em um dos módulos recém-identificados.

Por fim, pode haver alguns padrões / limitações específicos entre as interfaces que o arquiteto deseja que o sistema adote (por exemplo, retornos de chamada de evento versus chamadas de método direto), para que essas decisões precisem ser comentadas no design de arquitetura. Além disso, pode haver módulos "comuns" que o arquiteto deseja que todos usem.

    

Como desenvolvedor, você provavelmente está acostumado a fornecer soluções. Essa é uma maneira muito boa de pensar, mas pode atrapalhar você quando se trata de pensar sobre arquitetura.

Acho que ajuda descrever o problema que você está tentando resolver primeiro. Quais são os requisitos? Quais são as restrições? Você pode conversar com as partes interessadas para descobrir esses requisitos?

Pode ser útil também descrever seus próprios objetivos de design. Sua solução precisa ser dimensionada ou o design de um único usuário é suficiente? Por quanto tempo sua solução precisa permanecer válida? É uma correção única ou uma solução de infraestrutura de longo prazo? Talvez também importante: quais são os limites aceitos de sua arquitetura?

E como essa é uma experiência de aprendizado, não tenha medo de fazer perguntas, mesmo que sejam bobas.