{"id":1261,"date":"2017-07-31T14:32:56","date_gmt":"2017-07-31T17:32:56","guid":{"rendered":"http:\/\/gianfratti.com\/?p=1261"},"modified":"2017-07-31T14:41:52","modified_gmt":"2017-07-31T17:41:52","slug":"como-definir-uma-arquitetura","status":"publish","type":"post","link":"https:\/\/gianfratti.com\/index.php\/como-definir-uma-arquitetura\/","title":{"rendered":"Como Definir uma Arquitetura"},"content":{"rendered":"<h2>Para que?<\/h2>\n<p>Legal quando precisamos pensar em arquitetura, mas \u00e9 interessante revisitar os conceitos e definir a fun\u00e7\u00e3o de uma arquitetura ou mesmo de um sistema? Acredito que um sistema possa ser definido como:<!--more--><\/p>\n<blockquote><p>Prover uma funcionalidade ou solu\u00e7\u00e3o de neg\u00f3cio, usando tecnologia e t\u00e9cnicas de programa\u00e7\u00e3o, entregando um sistema ou solu\u00e7\u00e3o eficaz e eficiente.<\/p><\/blockquote>\n<p>Assuma consigo uma verdade:<\/p>\n<blockquote><p>Nada mais \u00e9 necess\u00e1rio, do que oferecer uma funcionalidade de neg\u00f3cio de forma eficaz e eficiente.<\/p><\/blockquote>\n<p>Ent\u00e3o quando pensar em incrementar sua arquitetura com algum framework ou padr\u00e3o, avalie se aquilo aumenta efic\u00e1cia, ou efici\u00eancia, caso contr\u00e1rio corte! Corte severamente! Mas, pense bem no que voc\u00ea considera efic\u00e1cia e efici\u00eancia, entregar no prazo faz parte da efic\u00e1cia quando prazo \u00e9 relevante. Suportar evolu\u00e7\u00f5es r\u00e1pidas faz parte da efic\u00e1cia tamb\u00e9m. Ser confi\u00e1vel (menor quantidade de erros) representa efici\u00eancia. Todos esses itens demandam pontos de aten\u00e7\u00e3o na arquitetura.<\/p>\n<p><em>Voc\u00ea n\u00e3o usa NHibernate ou Entity Framework porque \u00e9 bonito! Inevitavelmente eles reduzem performance, mas voc\u00ea ganha em produtividade\u2026!<\/em><\/p>\n<p>N\u00e3o quero confundir, s\u00f3 criar um paradigma que se resolve com a seguinte frase:<\/p>\n<blockquote><p>Se o que quer adicionar \u00e9 bonito, mas n\u00e3o traz nem efic\u00e1cia, nem efici\u00eancia, corte! [Lean: \u201cEliminate waste\u201d]<\/blockquote>\n<h2>Como?<\/h2>\n<p>Na defini\u00e7\u00e3o de uma arquitetura, temos sempre de pensar no target, mas n\u00e3o podemos fazer isso sem pensar no caminho a ser percorrido. Para entregar o produto precisamos pensar em:<\/p>\n<h3>Equipe<\/h3>\n<p>Qual o Skill do seu time, quais os gaps t\u00e9cnicos, qual o n\u00edvel de motiva\u00e7\u00e3o da sua equipe em aprender algo novo. Qu\u00e3o reativos s\u00e3o? Voc\u00ea n\u00e3o vai muito longe se aplicar uma arquitetura muito complexa, na qual os programadores n\u00e3o conseguem sequer us\u00e1-la, quem dir\u00e1 entend\u00ea-la. Da mesma forma como voc\u00ea n\u00e3o vai muito longe se seu time n\u00e3o estiver disposto a aprender. Nesses casos conservadorismo \u00e9 extremamente relevante.<\/p>\n<h3>Contexto<\/h3>\n<p>Qual o cen\u00e1rio atual? Voc\u00ea tem as premissas para tocar o projeto? Necessita de uma coexist\u00eancia com um outro projeto que j\u00e1 est\u00e1 em on-going? Em qual n\u00edvel voc\u00ea precisa se preocupar com retrocompatibilidade? Qual a infraestrutura (servidores, servi\u00e7os) que voc\u00ea disp\u00f5e? At\u00e9 onde voc\u00ea pode ir?<\/p>\n<p><em>S\u00f3 para parafrasear, eu tive limita\u00e7\u00f5es graves, agora em 2013, por causa de infraestrutura. Meu parque .NET antigo \u00e9 todo hospedado em Windows 2003 Server, sim 2003. S\u00f3 em meados de 2014 terei alguma coisa em 2012 server, portanto estou preso a no m\u00e1ximo usar o framework 4.0. #ficaDica<\/em><\/p>\n<h3>Arquitetura<\/h3>\n<p>Podemos definir arquitetura, como a estrat\u00e9gia que usaremos para entregar o produto. Entenda por estrat\u00e9gia itens como:<\/p>\n<ul>\n<li>Plataforma<\/li>\n<li>Frameworks<\/li>\n<li>Fluxo de Desenvolvimento<\/li>\n<li>Versionamento<\/li>\n<li>Organiza\u00e7\u00e3o e Empacotamento do C\u00f3digo<\/li>\n<li>Deploy<\/li>\n<li>Ferramentas de desenvolvimento e auxiliares<\/li>\n<\/ul>\n<p>Todos esses itens fazem parte da arquitetura.<\/p>\n<p><em>Sobre esse ponto tenho uma hist\u00f3ria interessante. Assim que cheguei no iMusica a primeira dificuldade que encontrei no processo era o deploy. N\u00e3o havia no reposit\u00f3rio de fontes uma vers\u00e3o fiel \u00e0 vers\u00e3o de produ\u00e7\u00e3o de muitos sistemas. Na verdade ter uma vers\u00e3o fiel no reposit\u00f3rio era uma exce\u00e7\u00e3o. O motivo era o deploy feito a partir das m\u00e1quinas de desenvolvimento, e esse deploy geralmente era diferencial. Copiava-se o que havia sindo modificado, ou o que achava-se que havia sido modificado.<\/em><\/p>\n<p><em>Com um fluxo de deploy cont\u00ednuo baseado em 2 builds no jenkins, foi f\u00e1cil eliminar esse problema.\u00a0<\/em><em>O deploy s\u00f3 acontece via ferramenta. Todos os passos s\u00e3o respeitados e somente builds completos chegam a produ\u00e7\u00e3o.\u00a0<\/em><em>A escolha do Jenkins se deu por causa da profici\u00eancia, minha claro, que iria instalar e configurar o servi\u00e7o, mas tamb\u00e9m pelo fato de n\u00e3o termos servidores novos, e o fluxo de aprova\u00e7\u00e3o de compras ser extremamente custoso, muitas vezes invi\u00e1vel. O Jenkins\u00a0<\/em><em>caiu como uma luva!\u00a0<\/em><em>Esse \u00e9 um exemplo de decis\u00e3o tomada em fun\u00e7\u00e3o da equipe e do contexto. \u00c9 importante trabalhar com o que se tem!<\/em><\/p>\n<p>Voltando ao assunto principal, sem esses pilares, estamos desrespeitando leis universais, n\u00e3o levando em considera\u00e7\u00e3o ou o cen\u00e1rio, ou o target (que leis s\u00e3o essas? N\u00e3o sei, mas alguma deve estar desrespeitando).<\/p>\n<p>Note que <em>equipe<\/em> \u00e9 o primeiro ponto, e <em>arquitetura<\/em> \u00e9 o \u00faltimo. A ordem \u00e9 proposital, e acredito que deva ser priorizada assim. S\u00e3o as pessoas que movem a engrenagem, elas que v\u00e3o dar manuten\u00e7\u00e3o nas aplica\u00e7\u00f5es, aprender tecnologias novas para realizar coisas n\u00e3o vistas at\u00e9 ent\u00e3o, s\u00e3o elas as respons\u00e1veis pelo sucesso de qualquer projeto. O <em>contexto<\/em>, e nele inclui-se automaticamente a empresa, tem sua medida de responsabilidade, mas s\u00e3o <em>as pessoas<\/em> que realmente fazem a maior diferen\u00e7a. A <em>arquitetura<\/em> \u00e9 mera resultante, \u00e9 uma dire\u00e7\u00e3o que aponta o caminho para chegarmos de um ponto a outro, com a equipe que temos e com o contexto que temos. Voltando na empresa\u2026 infraestrutura, suporte, quantidade de profissionais, investimento em contrata\u00e7\u00f5es, treinamento\u2026 isso tudo encaixo na parte <em>contexto<\/em>, s\u00e3o os Meios que a empresa\u00a0prov\u00ea para que voc\u00ea realize seu projeto, ou sua meta anual. [Lean: \u201cEmpower the team\u201d]\n<p>At\u00e9 aqui estamos teorizando muito. Esse \u00e9 o intuito, mas daqui para frente vamos falar um pouco da pr\u00e1tica. O que voc\u00ea pode fazer para desenhar efetivamente uma arquitetura.<\/p>\n<h2>O que usar?<\/h2>\n<p>Voc\u00ea deve se perguntar, em algum momento do projeto: O que vou usar? Como\u00a0escolher o melhor design? Quais frameworks, quais padr\u00f5es, quais paradigmas e princ\u00edpios usar?<\/p>\n<p>Bom, seja conservador, na medida do poss\u00edvel. Comece endere\u00e7ando os problemas a pontos da sua arquitetura.<\/p>\n<ul>\n<li>Dif\u00edcil de gerenciar vers\u00f5es: ALM, Ger\u00eancia de Configura\u00e7\u00e3o, Release Management, SemVer<\/li>\n<li>Dif\u00edcil de gerenciar deploy: Continous Delivery, Continous Deployment<\/li>\n<li>Alta quantidade de erros \/ Inseguran\u00e7a ao realizar grandes mudan\u00e7as: Testes<\/li>\n<\/ul>\n<p>Tem receita de bolo para quase tudo. Na discuss\u00e3o foram abordados diversas t\u00e9cnicas: JS para interfaces ricas, ORM para facilitar o acesso a dados, DDD para melhorar a forma de construir o neg\u00f3cio em si, <del>ASP.NET WebForms para aplica\u00e7\u00f5es CRUD<\/del>, ASP.NET MVC quando precisa-se de maior controle na UI, ou mesmo pelo padr\u00e3o, reaproveitamento e testes. Enfim, se voc\u00ea fizer uma matriz com a <em>sopa de letrinhas<\/em>, vai chegar ao seu design, esbarrando hora ou outra em escolhas entre produtos e implementa\u00e7\u00f5es de um mesmo padr\u00e3o, e\u00a0como n\u00e3o poderia deixar de ser, lembre-se:<\/p>\n<blockquote><p>Toda escolha, uma ren\u00fancia.<\/p><\/blockquote>\n<p>Cada cen\u00e1rio denota problemas diferentes, resolva-os primeiro, pois o foco \u00e9 no target. Com os problemas endere\u00e7ados, vamos pensar em otimiza\u00e7\u00e3o.\u00a0Veja quais padr\u00f5es, frameworks, pr\u00e1ticas etc otimizariam a efici\u00eancia ou efic\u00e1cia do seu projeto. Lembre-se sempre de efici\u00eancia e efic\u00e1cia.<\/p>\n<h2>Dando a cara a tapa!<\/h2>\n<p>Saindo um pouco da abstra\u00e7\u00e3o, vamos \u00e0 pr\u00e1tica. Deixa eu explicar um pouco de como eu fa\u00e7o. Primeiro, trabalho como arquiteto h\u00e1 alguns muitos anos, tive projetos bons e projetos ruins, mas alguma coisa aprendi nesse tempo:<\/p>\n<blockquote><p>Seja presente e use o que voc\u00ea desenha.<\/p><\/blockquote>\n<p>Essa hist\u00f3ria de arquiteto ausente, arquiteto astronauta, pra mim n\u00e3o existe. Arquiteto que n\u00e3o codifica \u00e9 cozinheiro que n\u00e3o prova sua comida. Voc\u00ea precisa usar o que produz para\u00a0compreender as dificuldades, as facilidades, e os pontos que mais precisam de\u00a0abstra\u00e7\u00f5es.\u00a0Somente no dia-a-dia descobrimos os maiores gargalos que geralmente aparecem por acaso, quando esbarramos por ele.\u00a0Desde 2008 que n\u00e3o caio nessa furada de n\u00e3o desenvolver sob aquilo que desenho. \u00c9 frustrante! Se n\u00e3o houver\u00a0tempo de codificar, no seu cronograma, h\u00e1 graves problemas com o dimensionamento da\u00a0sua aloca\u00e7\u00e3o, porque boa parte do que voc\u00ea precisar\u00e1 codificar, s\u00e3o mecanismos e facilitadores, quando n\u00e3o, voc\u00ea precisa pegar alguma parte do neg\u00f3cio que use aquilo que voc\u00ea desenhou.<\/p>\n<p><em>Em 2008 pedi demiss\u00e3o de uma empresa que teimou em me alocar como arquiteto de 7 projetos simultaneamente. Se querem que voc\u00ea trabalhe assim, sugiro que vc procure outra empresa, s\u00e9rio! \u00c9 desvalorizar demais o tanto que vc estudou, estuda e precisar\u00e1 estudar.<\/em><\/p>\n<p>Outra dica:<\/p>\n<blockquote><p>O seu Deus te aben\u00e7oou com 2 ouvidos e 1 \u00fanica boca. #ficaDica<\/p><\/blockquote>\n<p>As pessoas que j\u00e1 trabalharam nos projetos, antigos\/atuais, que j\u00e1 vivem uma rotina onde voc\u00ea est\u00e1 chegando, ou mesmo trabalham h\u00e1 anos do teu lado, t\u00eam vis\u00f5es diferentes das tuas. Geralmente essas vis\u00f5es s\u00e3o mega interessantes e ajudam muito a entender dificuldades e gaps, ou das pessoas ou da arquitetura atual, esses papos ajudam na compreens\u00e3o do projeto e na identifica\u00e7\u00e3o de seus principais pontos, positivos e negativos. Endere\u00e7ar as reclama\u00e7\u00f5es comuns e fortalecer os pontos elogiados torna a arquitetura bem interessante e atrativa para quem est\u00e1 desenvolvendo. [Lean: \u201cEmpower the team\u201d]\n<p>E sobre o seus 2 ouvidos e 1 boca, voc\u00ea tamb\u00e9m tem 2 bra\u00e7os, sim, \u00e9 verdade! Al\u00e9m de falar menos, e escutar mais, fa\u00e7a mais! Arregace as mangas e mostre que o que voc\u00ea est\u00e1 propondo \u00e9 poss\u00edvel. Mostre com algo pr\u00e1tico, sempre que necess\u00e1rio. As pessoas precisam entender que voc\u00ea n\u00e3o \u00e9 nem m\u00e1gico, nem charlat\u00e3o.<\/p>\n<p>N\u00e3o se frustre, mudan\u00e7as s\u00e3o bem vindas!<\/p>\n<p>N\u00e3o se frustre com uma verdade universal:<\/p>\n<blockquote><p>N\u00e3o importa o tamanho do projeto, a qualidade da especifica\u00e7\u00e3o, o n\u00edvel de detalhamento, o qu\u00e3o debatido ou esmiu\u00e7ado foi. Em algum momento algo vai mudar!\u00a0Se o projeto, o neg\u00f3cio, ou\u00a0o requisito, n\u00e3o mudarem, no m\u00ednimo sua vis\u00e3o mudar\u00e1!<\/p>\n<p>Em algum momento voc\u00ea pensar\u00e1: Essa parte\u00a0ficaria melhor assim, assado\u2026<\/p>\n<p>Inevitavelmente algum fator interno ou externo demandar\u00e1 mudan\u00e7as, ou no c\u00f3digo de neg\u00f3cio, ou na arquitetura, ou em ambos.<\/p><\/blockquote>\n<p>Assim tento facilitar a vida de quem precisa realizar mudan\u00e7as. Tento desenhar abstra\u00e7\u00f5es para promover o refactoring. A arquitetura deve favorecer nessa tarefa\u00a0para que possa ser estimulada. Nada se mant\u00e9m imut\u00e1vel do in\u00edcio ao fim do projeto, principalmente em projetos grandes. N\u00e3o importa como sua arquitetura est\u00e1 sendo modelada, favore\u00e7a sempre o refactoring, pois o custo de ter de trabalhar em uma solu\u00e7\u00e3o ou um peda\u00e7o do neg\u00f3cio mal modelado \u00e9 alt\u00edssimo.<\/p>\n<blockquote><p>Uma gambiarra \u00e9 igual a uma mentira.<\/p>\n<p>Sempre precisar\u00e1 de novas para justificar a primeira.<\/p><\/blockquote>\n<p>Por isso, evite manter d\u00e9bitos t\u00e9cnicos por muito tempo. Destrua-os! Muitas vezes n\u00f3s mesmos os criamos, quando por algum motivo, deixamos de fazer a coisa certa para fazer o mais r\u00e1pido. Para minimizar esse tipo de ocorr\u00eancia, \u00e9 importante facilitar a mudan\u00e7a e at\u00e9 promov\u00ea-la. Abaixo h\u00e1 uma pequena lista com o que eu j\u00e1 fiz para minimizar esses\u00a0problemas.<\/p>\n<p>Como eu promovo as mudan\u00e7as:<\/p>\n<ul>\n<li>Utilizo muito ORM, e geralmente com c\u00f3digo gerado. As pessoas podem mudar o banco, a qualquer momento, eu garanto que no m\u00ednimo a aplica\u00e7\u00e3o \u00e9 compat\u00edvel com as mudan\u00e7as. Mudan\u00e7as estruturais no banco afetam o build, quebrando-o. A aus\u00eancia ou mesmo o rename de campos no banco, geram quebras de build. Esses erros s\u00f3 apareceriam em runtime, e esse \u00e9 um ganho substancial. Ao resolver a quebra de build, voc\u00ea tem uma minima garantia de que as coisas est\u00e3o coerentes, mas claro, se voc\u00ea adicionar um campo n\u00e3o nulo em uma tabela existente, o build n\u00e3o quebrar\u00e1, mas, como uso linq em quase 100% do projeto, \u00e9 f\u00e1cil identificar quem precisa ser modificado.<\/li>\n<li>Uso muito IoC e abstra\u00e7\u00f5es: Toda a infraestrutura \u00e9 abstra\u00edda. Redis, Spring, MongoDB, SQL Server, MySQL, RabbitMQ, nada \u00e9 feito diretamente manipulando providers nativos. Uma troca de tecnologia \u00e9 muito simples de ser realizada. Ao mesmo tempo, os providers est\u00e3o dispon\u00edveis para utiliza\u00e7\u00e3o,\u00a0mas a utiliza\u00e7\u00e3o direta, por fora da arquitetura \u00e9 desencorajada.<\/li>\n<\/ul>\n<h2>Overdesign<\/h2>\n<p>Lembra do papo sobre efici\u00eancia e efic\u00e1cia?\u00a0Ent\u00e3o, tento sempre garantir o maior n\u00famero de itens n\u00e3o funcionais na arquitetura. Pra isso n\u00e3o abro m\u00e3o de alguns padr\u00f5es, como IoC e DI. Quando falo de abstra\u00e7\u00f5es, penso automaticamente de um dos itens do Lean (<a href=\"http:\/\/en.wikipedia.org\/wiki\/Lean_software_development\">http:\/\/en.wikipedia.org\/wiki\/Lean_software_development<\/a> ) \u201cDecide as late as possible\u201d. Muitas das estrat\u00e9gias de deploy, agrupamento, processamento distribu\u00eddo, deixo para o final do projeto. Mas para isso, preciso ter uma arquitetura que me suporte esse tipo de abstra\u00e7\u00e3o. Muitos consideram Overdesign, eu chamo de adaptabilidade. As coisas mudam!<\/p>\n<p>Enfim, h\u00e1 uma infinidade de pontos que tento abstrair, para garantir uma codifica\u00e7\u00e3o de neg\u00f3cio limpa e ao mesmo tempo com garantias de seguran\u00e7a, escalabilidade e confiabilidade.<\/p>\n<h2>Simples mas n\u00e3o Simplificado<\/h2>\n<p>Mas voc\u00ea pode pensar que a complexidade do c\u00f3digo \u00e9 grande? N\u00e3o, n\u00e3o \u00e9. Tudo isso, que desenho geralmente envolve m\u00e9dia complexidade de infraestrutura, para ter uma alta produtividade na utiliza\u00e7\u00e3o.<\/p>\n<p>Abaixo temos o c\u00f3digo-fonte de um servi\u00e7o, usado por uma aplica\u00e7\u00e3o Web, Windows Services e outros. Para cada cliente o deploy \u00e9 diferente (Inline Wcf, Etc). E n\u00e3o tenho dor de cabe\u00e7a com gest\u00e3o. Esse c\u00f3digo tem garantia de exception replacement, exception management (log em fila RabbitMQ e importa\u00e7\u00e3o futura para banco), suporte a exceptions para WCF (faltas), ainda, abertura autom\u00e1tica de contexto do NHibernate (pode ser v\u00e1rios), inclusive tenho opera\u00e7\u00f5es em 2 bancos (mysql e sqlserver) simultaneamente, com NHibernate, operando da mesma forma e abstra\u00e7\u00e3o de opera\u00e7\u00f5es com MongoDB. Tudo para que o desenvolvedor se preocupe apenas com c\u00f3digo de neg\u00f3cio e n\u00e3o com a infraestrutura.<\/p>\n<div class=\"crayon-pre\">\n<div id=\"crayon-597f4410de312535885591-1\" class=\"crayon-line\">\n<p>&nbsp;<\/p>\n<pre class=\"brush: sql; title: ; notranslate\" title=\"\">\r\npublic class ExemploServico\r\n{\r\n &#x5B;NHContext(&quot;MetaContext&quot;, false)]\r\n public Photo GetOrCreatePhoto(string fileName)\r\n {\r\n if(string.IsNullOrWhiteSpace(fileName)\r\n throw new ArgumentNullException(&quot;fileName&quot;)\r\n \r\n Photo photo = this.PhotoRep.MatchByName(file);\r\n if (photo == null)\r\n {\r\n photo = this.CreatePhoto(file);\r\n }\r\n return photo;\r\n }\r\n \r\n &#x5B;NHContext(&quot;MetaContext&quot;, true)]\r\n public Photo CreatePhoto(string fileName)\r\n {\r\n if(string.IsNullOrWhiteSpace(fileName)\r\n throw new ArgumentNullException(&quot;fileName&quot;)\r\n \r\n Photo photo = new Photo()\r\n {\r\n Src = file\r\n };\r\n this.PhotoRep.Save(photo);\r\n return photo;\r\n }\r\n}\r\n<\/pre>\n<p>&nbsp;<\/p>\n<\/div>\n<\/div>\n<p>Voc\u00ea pode se perguntar e afirmar que \u00e9 chato desenvolver assim, que n\u00e3o h\u00e1 complexidade etc. <em>Bom, quem gosta de ficar repetidamente gerenciando\u00a0complexidade em tudo \u00e9 minha esposa!<\/em><\/p>\n<p>Se o desenvolvedor precisar de algo novo, a tend\u00eancia \u00e9 que ele crie algo gen\u00e9rico, para que possa ser incorporado como mecanismo da arquitetura. E a\u00ed entra o refactoring, novamente. Uma abordagem que uso e que contradiz muitos \u00e9:<\/p>\n<blockquote><p>N\u00e3o considero a op\u00e7\u00e3o ter 2 defini\u00e7\u00f5es de arquitetura ou implementa\u00e7\u00f5es funcionais, id\u00eanticas na aplica\u00e7\u00e3o.Um refactoring do que j\u00e1 estava pronto, \u00e9 parte da tarefa de cria\u00e7\u00e3o do mecanismo. E se sou eu quem fa\u00e7o o mecanismo, eu fa\u00e7o a mudan\u00e7a no c\u00f3digo. Quem quer que fa\u00e7a o mecanismo \u00e9 respons\u00e1vel por rever essas quebras, no m\u00ednimo acompanhando, lado-a-lado, o autor da funcionalidade, o que raramente acontece no meu time atual.<\/p>\n<p>D\u00e9bitos t\u00e9cnicos s\u00e3o revistos sempre, mesmo que fora do hor\u00e1rio do expediente. E morrem sim! Mesmo que eu tenha de dar sangue para que esse d\u00e9bito t\u00e9cnico morra, ser\u00e1 feito! Promessa \u00e9 d\u00edvida!<\/p><\/blockquote>\n<p>Essa arquitetura, esse n\u00edvel de simplicidade s\u00f3 \u00e9 poss\u00edvel com\u00a0abstra\u00e7\u00f5es, e muitas abstra\u00e7\u00f5es. Essa \u00e9 realmente a m\u00e1gica que possibilita construir solu\u00e7\u00f5es robustas. Abstraia o m\u00e1ximo de complexidade do c\u00f3digo de neg\u00f3cio, movendo para pontos centrais de sua arquitetura. Para o desenvolvedor, precisa ser\u00a0algo simples, algo que n\u00e3o o leve a cometer erros, para que ele poss ser mais produtivo.<\/p>\n<p>Mas quem tiver interesse na complexidade, vai te ajudar nas abstra\u00e7\u00f5es, quem n\u00e3o estiver afim de aprender P.N (Porra Nenhuma), n\u00e3o precisa aprender, apenas usar. A escolha \u00e9 de quem desenvolve, mas num time misto, onde 20% \u00e9 interessado e 80% est\u00e1 \u00e0 deriva, voc\u00ea facilmente consegue produtividade e motiva\u00e7\u00e3o dos 2 grupos, e fazer com que entreguem melhor as solu\u00e7\u00f5es.<\/p>\n<p>Bom, meus contatos est\u00e3o aqui no blog, estou dispon\u00edvel (n\u00e3o como consultor, mas como parceiro mesmo.. for free R$) para ajudar e espero poder contribuir um pouquinho com seus projetos.<\/p>\n<blockquote><p>Esse post nasceu em 2013, mas s\u00f3 foi publicado em 2014. Agora no finalzinho de\u00a02016 estou revendo-o para n\u00e3o deix\u00e1-lo t\u00e3o datado. Esse foi um dos posts mais\u00a0vistos desde 2013 e j\u00e1 me rendeu boas\u00a0hist\u00f3rias. Espero que tenha curtido, agrade\u00e7o ter chegado at\u00e9 aqui, eu sei que \u00e9 uma leitura densa, e muitas vezes chata. Mas algu\u00e9m tem de escrever o que precisa ser escrito.<\/p><\/blockquote>\n<p>Obrigado pela extensa leitura.<\/p>\n<p>Fonte: <a href=\"http:\/\/luizcarlosfaria.net\/blog\/como-definir-arquitetura-de-software\/\" target=\"_blank\" rel=\"noopener\">http:\/\/luizcarlosfaria.net\/blog\/como-definir-arquitetura-de-software\/<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"<p>Para que? Legal quando precisamos pensar em arquitetura, mas \u00e9 interessante revisitar os conceitos e definir a fun\u00e7\u00e3o de uma arquitetura ou mesmo de um sistema? Acredito que um sistema possa ser definido como:<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_exactmetrics_skip_tracking":false,"_exactmetrics_sitenote_active":false,"_exactmetrics_sitenote_note":"","_exactmetrics_sitenote_category":0,"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[171],"tags":[],"class_list":["post-1261","post","type-post","status-publish","format-standard","hentry","category-definindo"],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/gianfratti.com\/index.php\/wp-json\/wp\/v2\/posts\/1261","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/gianfratti.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/gianfratti.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/gianfratti.com\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/gianfratti.com\/index.php\/wp-json\/wp\/v2\/comments?post=1261"}],"version-history":[{"count":6,"href":"https:\/\/gianfratti.com\/index.php\/wp-json\/wp\/v2\/posts\/1261\/revisions"}],"predecessor-version":[{"id":1267,"href":"https:\/\/gianfratti.com\/index.php\/wp-json\/wp\/v2\/posts\/1261\/revisions\/1267"}],"wp:attachment":[{"href":"https:\/\/gianfratti.com\/index.php\/wp-json\/wp\/v2\/media?parent=1261"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/gianfratti.com\/index.php\/wp-json\/wp\/v2\/categories?post=1261"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/gianfratti.com\/index.php\/wp-json\/wp\/v2\/tags?post=1261"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}