Arquitetura de Software_Estilos e Padrões de Design

Prévia do material em texto

Arquitetura de Software: Estilos e Padrões de Design 
Uma Reflexão sobre Arquitetura de Software 
A arquitetura de software representa o blueprint de um sistema, referindo-se aos fundamentos 
estruturais na composição de blocos de software, sendo a disciplina responsável pela organização e 
comunicação dos elementos essenciais durante a construção de componentes modulares de 
software. 
Quando construímos um software precisamos descrevê-lo seguindo um plano de execução 
arquitetural. Nesta etapa, será necessário detalhar como os blocos serão construídos, a forma como 
sua comunicação será efetuada, além de dividir as responsabilidades dos componentes entre as 
camadas de sua composição. 
O termo blueprint possui sua origem no emprego em projetos de engenharia civil e arquitetura 
urbana, sendo usado para descrever padrões de design e estruturais a serem seguidos durante a 
execução de determinada construção. 
Análogo a um plano de construção de engenharia civil, os passos arquiteturais precisam estar 
descritos detalhadamente, atuando como alicerces para que desta forma não tenhamos surpresas ao 
avançarmos para as etapas seguintes. Quanto mais segura e confiável for a base de arquitetura 
maiores serão as chances de sucesso. Assim, quanto mais alto estivermos na pirâmide do software, 
mais facilidade teremos de retroceder a decisões equivocadas. 
O conjunto de componentes construídos a partir de uma base arquitetural, moldam 
a implementação/codificação das peças representando o estilo/padrão aplicado. Mudanças 
necessárias na base de arquitetura possuem alto custo de reversão, tornando pouco flexíveis e 
rígidas podendo inclusive comprometer o projeto. 
Etapa de Planejamento 
A etapa de planejamento arquitetural de um software ocorre após a finalização da especificação de 
requisitos, precedendo a fase de design. Motivo pelo qual a etapa de arquitetura de software é 
conhecida como early design step. Planejar e implantar a arquitetura de um software significa 
representá-lo a partir de um alto nível de abstração. 
Desta forma, a fase de arquitetura pode ser definida como um passo pertencente ao ciclo de vida do 
componente de software. A arquitetura de um sistema deve prever o funcionamento de suas 
https://medium.com/@marcelomg21?source=post_page-----50d62d684ef2--------------------------------
https://medium.com/@marcelomg21?source=post_page-----50d62d684ef2--------------------------------
https://pt.wikipedia.org/wiki/Blueprint
https://pt.wikipedia.org/wiki/Blueprint
https://fontanarchitecture.com/architectural-design-phases/
operações sem apresentar quaisquer detalhes de implementação. O projeto de arquitetura de 
software deve contemplar atributos como eficiência, portabilidade, reusabilidade e confiabilidade. 
É comum utilizarmos ADLs (architecture description language) para descrever 
arquiteturalmente componentes de software, podendo ser encontrada em vários formatos, 
como UML (Unified Modeling Language), diagramas, variando de acordo com os tipo de 
notação adotada. Alguns exemplos de ADLs são: ABACUS, ADML (Architecture Description 
Markup Language), Wright, Unicon, Rapide, SSEP (software and systems engineering 
productivity), AO-ADL (Aspect Oriented Architecture Description 
Language), AADL (Architecture Analysis and Design Language). 
Um software precisa ser projetado para falhas, devendo prever os riscos adicionados a cada etapa 
que o compõe. Durante a fase de resolução do problema, a arquitetura de um sistema reflete a 
forma e estilos de comunicação que determinado componente deve adotar. Arquitetura de software 
trata-se do primeiro passo em direção a resolução de um problema, antes de sua implementação, 
mostrando como um software deverá ser construído e como deverá comportar-se. 
Arquitetura — A possibilidade antecipar, padronizar e estruturar o crescimento 
exponencial e sustentável de um software, consequentemente reduzindo custos em todo seu ciclo 
de vida. 
A importância desta etapa, quando bem executada, revela as facilidades relacionadas a 
manutenções futuras e na adição de novas funcionalidades ao sistema. Quando um software segue 
um padrão arquitetural conhecido, poderá ser capaz de minimizar custos associados aos riscos 
inerentes a qualquer sistema, reduzindo impactos e possibilitando um gerenciamento de risco 
apropriado. 
A Presença dos Trade-offs 
Na área de arquitetura de software, sempre existirão os trade-offs: termo utilizado para descrever 
uma tomada de decisão necessária, em cima de determinadas abordagens arquiteturais competindo 
entre si, devendo pesar os prós e contras de cada uma, possibilitando que ao final, uma escolha bem 
sucedida possa ser realizada oferecendo a resolução de um problema específico em um 
determinado contexto. 
Desta forma, quanto mais sólida for sua base de conhecimento e maior sua experiência, mais 
assertivo será o resultado de sua decisão. Imaginemos então, que este conjunto de conhecimentos 
https://cio-wiki.org/wiki/Architecture_Description_Language_(ADL)
https://pt.wikipedia.org/wiki/UML
https://en.wikipedia.org/wiki/Avolution
http://www.opengroup.org/public/arch/p4/adml/adml_intro.htm
http://www.opengroup.org/public/arch/p4/adml/adml_intro.htm
https://pt.wikipedia.org/wiki/Frank_Lloyd_Wright
https://www.cs.cmu.edu/afs/cs/project/vit/www/unicon/reference-manual/Reference_Manual_2.html
https://ieeexplore.ieee.org/document/385971
https://link.springer.com/chapter/10.1007/978-1-4615-4339-8_22
https://link.springer.com/chapter/10.1007/978-1-4615-4339-8_22
https://www.researchgate.net/publication/237691268_Aspect-oriented_Software_Architecture_Description_Language_AO-ADL
https://www.researchgate.net/publication/237691268_Aspect-oriented_Software_Architecture_Description_Language_AO-ADL
https://en.wikipedia.org/wiki/Architecture_Analysis_%26_Design_Language
https://pt.wikipedia.org/wiki/Trade-off
tratam-se de uma pequena caixa de ferramentas que acompanhará cada arquiteto de software em 
sua jornada. 
Quanto maior sua caixa, mais ferramentas você terá a seu dispor e mais rapidamente irá conseguir 
tomar a melhor decisão, resolvendo o impasse com maior riqueza de detalhes. Ao mesmo tempo, 
quanto menor sua caixa de ferramentas, mais limitadas serão suas opções, aumentando o risco em 
não prosperar em suas escolhas. 
Naturalmente, caso a única ferramenta existente em sua caixa de ferramentas seja um martelo, 
obviamente você irá tratar tudo como sendo prego. Precisamos estar atentos em sempre usar 
a ferramenta certa para o trabalho certo e isto nem sempre está vinculado a nossa 
linguagem de programação favorita. 
A Disciplina de Arquitetura de Software 
Quando nos deparamos com as primeiras leituras sobre a disciplina de arquitetura de software, 
enxergamos diversas opções junto a uma infinidade de conceitos ainda desconhecidos e 
inexplorados. Assim como em qualquer disciplina, precisamos de base sólida de conhecimento para 
entender determinados conceitos e seguirmos em frente. 
A base exigida para o sucesso nas decisões de um arquiteto irá variar de acordo com a complexidade 
de cada assunto envolvido no contexto de cada projeto. Para se aventurar, obtendo sucesso na 
compreensão da disciplina será necessário esforço buscando absorver conhecimentos cada vez mais 
relevantes e cultivando a procura incessante pela informação. 
Quanto mais absorvemos informações e evoluímos, maior será o amadurecimento de conceitos já 
existentes em nossa caixa de ferramentas. Sempre existirão obstáculos, porém a vontade de seguir 
em frente e levar a disciplina de arquitetura de software cada vez mais a sério e presente em nossas 
rotinas como profissionais de arquitetura nunca poderá enfraquecer-se. 
O Papel do Arquiteto de Software 
Durante a etapa de definição de arquitetura de um projeto, o arquiteto deve assumir o controle do 
processo, implicando desde estudos de caso envolvendo soluções de mercado, identificação 
de trade-offs e tomadas de decisãocom teor técnico. Assim, a este profissional torna-se 
obrigatória a detenção de uma base de conhecimento sólida para o enquadramento e composição 
do desenho técnico apropriado para cada cenário, dando origem à devida especificação sendo 
adequadamente confeccionada. 
https://pt.wikipedia.org/wiki/Trade-off
Não podemos subjugar nem menosprezar uma das etapas mais importantes e essenciais para a 
execução bem sucedida de um software: o estágio de planejamento de arquitetura. O 
principal problema, em muitas situações, refere-se a definição de postura a ser imposta pelo 
arquiteto de software em relação a apropriação de insumos técnicos necessários para nortear uma 
noção mais madura do que precisaria ser compreendido, e posteriormente seguido, no âmbito 
técnico, o que nem sempre acontece. Em outras palavras, ocorre falta de competência técnica para 
tomada de decisões cruciais. 
Quando percebemos a desconexão entre o peso da responsabilidade imposta pelo estágio 
arquitetural de um software e a superficialidade de conhecimento dominante no profissional de 
arquitetura, acabamos com uma execução prática pobre, desordenada e desorganizada. 
Assim, para superarmos a falta de conhecimento exigida para o desempenho pleno do papel na 
etapa de arquitetura e preenchermos estas lacunas evidentes, precisamos perseguir o 
aperfeiçoamento profissional cada vez maior em direção a tornar o trabalho dos arquitetos de 
software cada vez mais reconhecido dando a disciplina de arquitetura cada vez mais relevância. 
A Importância do Entendimento de Arquitetura 
Ao refletirmos sobre os softwares sob um viés de responsabilidade, comunicação e tudo que cerca 
as camadas de arquitetura, inevitavelmente acabamos nos dando conta que as percepções referem-
se a pontos de vista isolados aos olhos de quem os observa. Ao olharmos de perto será possível 
perceber as nuances de uma cadeia evolutiva, pretendendo sintetizar toda uma evolução tendo se 
passado algumas décadas. 
A partir deste contexto, podemos refletir sobre os movimentos/avanços que nos trouxeram até a 
modernidade, permitindo-nos contemplar o estado da arte para determinados padrões que 
prosperaram. Constatamos, desta forma, que diversos detalhes ocorreram silenciosamente 
enquanto seguíamos em frente. A partir desta reflexão, compreendemos que conceitos comuns, 
atribuídos atualmente a alguns componentes modernos, tratam-se apenas de uma projeção do 
passado, carregando consigo o peso e complexidade inerentes às raízes de sua descendência. 
Quando nos referimos a disciplina de arquitetura de software, precisamos dedicar esforços para 
entender os motivos pelos quais tais direcionadores arquiteturais existem e nos trouxeram até aqui. 
Conhecendo seus antecessores, precisaremos entender como e porque evoluíram, ou os motivos por 
terem sido ultrapassados. Até que por fim, consigamos ter uma visão clara de quais serão 
as próximas tendências. 
Uma estratégia sólida facilitará previsões sobre o futuro destas tecnologias, quais irão se manter 
no jogo e quais estarão ultrapassadas nos anos seguintes. Observar tendências nos permite 
realizar comparações mais assertivas, refletir sobre determinadas escolhas, oferecendo maior 
facilidade em resolver os trade-offs que surgirão. 
Aprofundamento Superficial dos Conceitos 
Embora, em muitos casos, a falta de dedicação necessária visando atingir a plenitude técnica no 
campo arquitetural, apresentar-se como uma realidade latente, parte deste cenário pode ser 
explicado adiante as facilidades presentes em padrões e estilos de arquitetura prontos para uso no 
mercado. Neste caso, a utilização de padrões mais rudimentares empregados em cenários mais 
complexos coloca em risco o sucesso do projeto de software. 
Na maioria das vezes, a etapa de definição de arquitetura, e o entendimento da sua importância 
acaba sendo subjugado. É bastante comum vermos desenvolvedores e arquitetos seguirem receitas 
de bolo sem mesmo interessar-se em conhecer os detalhes para justificarem sua utilização. 
Ainda assim, será sempre importante termos o papel de um arquiteto, independente de sua 
experiência, responsável pela execução prática desta etapa. Este papel, deve participar ativamente, 
não somente da etapa de concepção do software como da evolução do seu ciclo de vida. 
Quando responsabilizamos alguém por determinada atividade, provemos um dono para 
aquele processo ou etapa, garantindo maior qualidade na execução do que foi desenhado no 
momento da concepção técnica de arquitetura. 
A importância da etapa de arquitetura pode ser observada na execução de um software bem 
sucedido. Componentes de software quando pensados de forma modular desde sua concepção 
tornam sua comunicação e divisão de responsabilidades mais inteligente e flexível. 
Quando idealizados em uma etapa de arquitetura apropriada, os componentes possuem maior 
sofisticação e elegância, apresentando visivelmente maior qualidade tanto durante seu ciclo de vida 
quanto facilitando sua manutenção. 
Conseguimos observar a qualidade sendo refletida na redução de custos para manutenção 
posterior as entregas, incluindo a inserção de novos componentes, integrando-se 
ao ecossistema geral da arquitetura adotada. 
Estilos Arquiteturais (Architectural Styles) 
https://pt.wikipedia.org/wiki/Trade-off
Estilos arquiteturais referem-se a uma terminologia que caracteriza, através aparência estética, 
componentes de software cujo o design seja notável e identificável a partir de uma visão do nível 
mais alto de abstração. Quando definimos o estilo arquitetural de nosso software estamos 
interessados em prever como as camadas e módulos irão comunicar-se, identificando e isolando 
suas responsabilidades. Existem diferentes tipos de estilos arquiteturais, podendo ainda serem 
combinados produzindo estilos híbridos adicionais. 
Dentre os principais estilos podemos citar cinco grandes grupos: structure (layered, pipes and 
filters, component-based), shared memory (role-based, blackboard, database-centric), 
messaging styles (Implicit invocation, asynchronous messaging, publish-subscribe), adaptive 
systems (microkernel style, reflection, domain-specific language) e distributed 
systems (service-oriented, peer to peer style, object request broker, cloud 
computing), deployment (client-server, n-tier). 
Estilos arquiteturais são considerados soluções visando resolver certas classes de problemas os 
quais compartilham um conjunto de atributos semelhantes agnósticos a tecnologia. Não existe um 
único estilo capaz de resolver todos os problemas, pois cada sistema possui particularidades. 
Como exemplo, alguns sistemas direcionam esforços a nível de segurança enquanto outros 
preferem focar na capacidade de ser real-time. Desta forma, estilos arquiteturais sempre irão 
beneficiar determinados atributos em favor de outros de acordo com os propósitos iniciais 
definidos. 
Estilos arquiteturais são responsáveis por prover conectores, interfaces e regras de combinação 
entre eles, promovendo o reuso e o design de particionamento entre componentes compactos. 
Conceitualmente, estilos e padrões arquiteturais diferem-se dependendo de qual nível estamos 
descrevendo o software. Uma vez referindo-se a coisas distintas em diferentes níveis de abstração, 
estilos procuram oferecer uma visão periférica em torno do problema a ser resolvido. Por outro 
lado, padrões descrevem o processo de como determinado objeto deve ser construído, na esfera de 
solução concreta para alguns problemas comuns em contextos comuns, responsáveis por balancear 
o custo e o benefício sob o resultado obtido. 
A necessidade de entendê-los possibilitará adotar com maior assertividade a melhor escolha para 
cada projeto. Existem diversas abordagens para resolvermos problemas de software, sendo de 
responsabilidade do arquiteto a tomada de decisão com relação aos trade-offs de cada proposta 
arquitetural. 
https://pt.wikipedia.org/wiki/Trade-offA mais importante característica, não somente em arquitetura de software, mas no campo de 
engenharia de software, trata-se da abstração empregada pelos padrões que a sustentam. Cada 
estilo arquitetural define uma família de sistemas, semanticamente coerentes, contendo um 
conjunto padrão de componentes integrados a topologia de cada layout. 
Dentro de um estilo existem princípios e formas para definição dos componentes, conectores e 
interação compondo uma espécie de vocabulário de comunicação para uma solução. Juntamente 
com um conjunto de restrições impostas, os estilos refletem na maneira em como são combinadas e 
distribuídas as responsabilidades entre os componentes de software. 
Existem diversos estilos arquiteturais na indústria, podendo ser categorizados 
individualmente: communication, deployment, domain, structure. 
Arquitetura de software oferece uma representação do sistema permitindo entender o 
comportamento de seus elementos. Possibilitando uma definição, tanto na esfera estrutural como 
de interação entre os componentes computacionais. O mais importante aspecto relacionado a 
arquitetura trata-se da presença de Software Patterns (padrões de software), guiando atividades 
de design e apresentando regras de como e quando deveríamos criar nossos blocos de software. 
O ciclo de desenvolvimento de um software apresentará maior qualidade tanto na experiência 
quanto no suporte adequado quando atrelado a raízes arquiteturais sólidas. 
Embora a importância do design para arquiteturas de software seja reconhecida, ainda continua 
sendo vista como uma etapa complexa e com pouca orientação. Estilos arquiteturais são uma 
manifestação das decisões de design representando o significado desta abstração, utilizado para 
impor uma separação conceitual adequada e segura. 
Estilos e padrões arquiteturais diferem-se estruturalmente através do seu escopo de 
aplicabilidade. Digamos, um estilo poderia ter um significado mais amplo: “relacionado à 
maneira de fazermos algo”, enquanto qualquer outro conjunto de padrões, 
sejam arquiteturais ou de design, referem-se a uma esfera mais decorativa dos blocos internos 
de um componente de software. 
Conhecendo o escopo de determinado conceito a ser aplicado, além de sua definição, será possível 
entendermos com facilidade seu objetivo. Desta forma, o foco de utilização de um padrão, junto ao 
seu seu nível de granularidade, direcionam sua aplicabilidade. Portanto, hierarquicamente teremos 
os estilos arquiteturais ocupando o nível mais alto de abstração para composição do design dos 
componentes de software. 
Distinguirmos os níveis de granularidade existentes trata-se de um passo importante para 
a compreensão da hierarquia de utilização de cada padrão. 
Padrões Arquiteturais (Architectural Patterns) 
Na disciplina de engenharia de software, padrões arquiteturais (architectural patterns) 
possuem o propósito de serem soluções gerais e reutilizáveis para componentes a nível de aplicação 
para problemas recorrentes dentro de um determinado contexto. Portanto, sendo uma solução 
recorrente para um problema recorrente. 
Padrões arquiteturais possuem natureza conceitual, sendo aplicados com flexibilidade variando 
seu nível de granularidade em seu escopo de aplicação. A diferença entre estilos e padrões 
arquiteturais ocorre no escopo do problema a ser resolvido. 
Nada impede de termos a combinação de diversos padrões arquiteturais dentro de uma mesma 
solução de software, permitindo-nos enxergar como os módulos de um determinado componente 
de software interagem. Quando entendemos a forma como as peças se encaixam entre as camadas 
de um sistema compreendemos com maior transparência a fluência na comunicação entre os níveis 
de responsabilidade arquitetural. 
Em alguns casos, elementos arquiteturais compõem maneiras de resolver problemas particulares, 
restritos especificamente a um pequeno contexto onde foi concebido. 
Certas estratégias podem ser definidas e documentadas como padrões de arquitetura, podendo ser 
disseminadas para uso pontual em determinados subsistemas, promovendo o reaproveitamento. 
Percebemos desta forma a evidente diferença entre um padrão de arquitetura (architectural 
pattern) e um estilo arquitetural (architectural style). Um padrão, simplesmente focando na 
resolução de problemas específicos a determinado contexto, não transcendendo suas regras de 
responsabilidade e comunicação através do restante do sistema. 
Por outro lado, as regras de um estilo arquitetural recaem sobre uma condensação de 
necessidades, descrevendo a responsabilidade entre os componentes em alto nível, focando na 
solução apresentada como um todo (top-down). 
Descrevemos informalmente que um padrão arquitetural detém seu foco em um problema 
específico, propondo a resolução de suas divergências somente na combinação do emprego 
de técnicas isoladas. 
O conjunto de padrões e estilos de arquitetura são atrelados a uma representação fixa, empregados 
a determinados sistemas ou contextos, convidando-nos a refletir sobre camadas ou componentes 
estruturados unitariamente. Individualmente, temos padrões arquiteturais opondo-se aos estilos, 
que por sua vez concentram-se em uma esfera mais abstrata do design de arquitetura dos objetos. 
Muitos profissionais de software (TI) confundem estilos e padrões de arquitetura, acreditando 
serem a mesma coisa e atacando problemas semelhantes. 
Ao compreendermos as diferenças ao empregar formas e métodos de construção, não somente 
entre estilos e padrões arquiteturais mas adicionalmente entre e design patterns (padrões de 
design), teremos maior facilidade ao descermos aos níveis mais técnicos de da aplicação (detalhes 
de implementação). Assim, será possível perceber com maior clareza suas responsabilidades 
conceitualmente distintas nas camadas superiores. 
Alguns detalhes de interações em tempo de execução destes componentes não estão relacionados 
a aspectos técnicos de sua arquitetura e sim de aplicação. 
A arquitetura em alto nível, descrita a partir de um determinado ecossistema, pode conter um ou 
mais estilos arquiteturais. Ao mesmo tempo, um estilo arquitetural pode se valer do uso de 
diversos padrões arquiteturais, presentes em uma mesma solução, dado sua aplicabilidade em 
contextos específicos. 
No contexto de arquitetura, independente do nível de isolamento, sempre buscamos 
o desacoplamento de responsabilidades com o objetivo de promovermos a reutilização dos 
componentes. Estudar seus pontos fortes e fracos facilita aplicarmos múltiplos padrões 
combinados em um único sistema visando otimizá-lo. 
Padrões arquiteturais são soluções comprovadas evidenciando a existência de problemas 
recorrentes. A arquitetura de um sistema trata-se do entendimento compartilhado da forma como 
os componentes estão divididos, entregando uma visão geral de como os componentes interagem 
através de suas interfaces preestabelecidas. 
Exemplos de Estilos e Padrões Arquiteturais 
Uma única aplicação pode conter diversos estilos de arquitetura, ao mesmo tempo em que cada 
estilo pode fazer uso de vários padrões arquiteturais. Alguns dos principais estilos 
arquiteturais são: 
• Client-Server 
• Component-based 
• Layered 
• Publish-subscribe 
• Plug-ins 
• Pipes and Filters 
• Service-Oriented Architecture (SOA) 
• REpresentational State Transfer (REST) 
• Domain Driven Design 
• Microservices 
Quanto aos padrões arquiteturais, os mais conhecidos são: 
• Model-View-Controller (MVC) 
• Microkernel 
• Three-tier 
• Event-driven (EDA) 
• Message Broker 
• CQRS (Command and Query Responsibility Segregation) 
Considerações Finais 
https://en.wikipedia.org/wiki/Client%E2%80%93server_model
https://pt.wikipedia.org/wiki/Engenharia_de_software_baseada_em_componentes
https://pt.wikipedia.org/wiki/Arquitetura_multicamada
https://docs.microsoft.com/pt-br/azure/architecture/patterns/publisher-subscriber
https://medium.com/omarelgabrys-blog/plug-in-architecture-dec207291800https://docs.microsoft.com/pt-br/azure/architecture/patterns/pipes-and-filters
https://en.wikipedia.org/wiki/Service-oriented_architecture
https://en.wikipedia.org/wiki/Representational_state_transfer
https://medium.com/@marcelomg21/domain-driven-design-ddd-em-uma-arquitetura-de-micro-servi%C3%A7os-cac52a90a40
https://medium.com/@marcelomg21/arquitetura-de-microsservi%C3%A7os-bc38d03fbf64
https://pt.wikipedia.org/wiki/MVC
https://searchapparchitecture.techtarget.com/tip/What-is-a-microkernel-architecture-and-is-it-right-for-you
https://www.ibm.com/cloud/learn/three-tier-architecture
https://medium.com/@marcelomg21/event-driven-architecture-eda-em-uma-arquitetura-de-micro-servi%C3%A7os-1981614cdd45
https://en.wikipedia.org/wiki/Message_broker
https://medium.com/@marcelomg21/cqrs-command-query-responsibility-segregation-em-uma-arquitetura-de-micro-servi%C3%A7os-71dcb687a8a9
Todo o software precisa de um design arquitetural para representar sua essência, descrevendo em 
alto nível seu comportamento. De modo geral, o design de arquitetura é definido como uma coleção 
de componentes de hardware e software estabelecendo suas interfaces de comunicação com o 
mundo externo. Através de seu comportamento e aparência, cada componente expressa a categoria 
de estilo arquitetural a qual pertence, possuindo características notáveis e identificáveis. 
Estilos arquiteturais não resolvem problemas, representando apenas maneiras recorrentes de 
arquitetura com um propósito geral a ser seguido. 
A adoção de estratégias de alto nível precisa ser efetivada, contendo aspectos particulares de 
relacionamento e comunicação entre os principais componentes de um produto. Nosso software 
estará maduro somente após ter passado com sucesso pela esteira de arquitetura, assim quanto 
mais rigorosa for esta etapa maior qualidade será agregada ao produto final. 
Desta forma, a fase de arquitetura bem executada facilitará a manutenção posterior dos elementos, 
possibilitará uma visão ampla de seu funcionamento como um todo, além de garantir maior 
facilidade na tomada de decisões futuras. Por fim, vale reforçar a importância da etapa de 
arquitetura e do papel do arquiteto de software, guiando o projeto em direção ao sucesso.