Você provavelmente já ouviu falar sobre tokens. Em muitos casos, ao acessar sistemas ou aplicativos bancários, você precisa gerar senhas por meio de um token. No entanto, hoje vamos discutir outro tipo de token, especificamente no contexto dos criptoativos. Esses tokens representam ativos digitais, mas você sabe exatamente como funcionam? Vamos explorar mais sobre esse fascinante mundo da tokenização.

O que são tokens?

Em termos simples, um token é uma unidade digital que representa um ativo ou utilidade em uma rede específica. Enquanto criptomoedas como Bitcoin e Ethereum funcionam como moedas digitais nativas em suas próprias redes, os tokens são construídos em cima dessas redes e podem ter uma variedade de finalidades.

Como funcionam?

Os tokens funcionam dentro de uma rede blockchain, que é um registro distribuído de transações imutáveis. Eles são criados através de contratos inteligentes, que são programas de computador autoexecutáveis que gerenciam a lógica dos tokens. Esses contratos inteligentes definem as regras para criação, transferência e destruição dos tokens, garantindo transparência e segurança nas operações.

Como são criados os tokens?

Os tokens são criados através de um processo chamado de “Tokenização”. Isso envolve a definição das características do token, como quantidade total, divisibilidade e outras propriedades específicas. Em seguida, um contrato inteligente é escrito para implementar essas características na blockchain. Assim que o contrato inteligente é implantado, os tokens podem ser distribuídos e negociados dentro da rede.

O que pode se tornar um token?

Praticamente qualquer ativo ou utilidade pode ser tokenizado. Desde moedas fiduciárias, como dólares e euros, até ativos físicos, como imóveis e obras de arte, podem ser representados por tokens. Além disso, serviços digitais, direitos de propriedade intelectual e até mesmo tempo e habilidades de trabalho podem ser transformados em tokens.

Tipos de tokens

Existem vários tipos de tokens, cada um com suas próprias características e finalidades. Alguns dos tipos mais comuns incluem:

– Tokens de Utilidade: Estes tokens concedem acesso a produtos ou serviços em uma plataforma específica. Eles são frequentemente usados em ICOs (Ofertas Iniciais de Moeda) como uma forma de arrecadar fundos para projetos de blockchain.

– Tokens de Segurança: São tokens que representam a propriedade de um ativo, como ações em
uma empresa ou participação em um fundo de investimento. Eles são regulados por leis de valores mobiliários e geralmente oferecem direitos aos detentores, como dividendos e voto em decisões corporativas.

– Stablecoins: São tokens projetados para manter um valor estável em relação a uma moeda fiduciária, como o dólar americano. Eles são úteis para proteger contra a volatilidade das criptomoedas e são
geralmente garantidos por reservas em moeda fiduciária ou outros ativos.

– Tokens Não Fungíveis (NFTs): Estes são tokens únicos e indivisíveis que representam ativos digitais
exclusivos, como obras de arte digitais, colecionáveis e itens de jogos. Eles são usados para comprovar a autenticidade e a propriedade exclusiva desses ativos na blockchain.

– Outro exemplo são os fan tokens: Tokens digitais emitidos por organizações esportivas, como clubes
de futebol, para envolver os torcedores e proporcionar a eles uma experiência mais interativa com o time. Geralmente são usados para conceder aos torcedores acesso a votações sobre decisões do clube, recompensas exclusivas, experiências VIP, entre outros benefícios.

Em resumo, os tokens são elementos fundamentais do ecossistema de criptoativos, proporcionando uma maneira flexível e eficiente de representar uma ampla gama de ativos e utilidades na blockchain. Com a
crescente adoção e inovação nesse espaço, podemos esperar ver ainda mais aplicações criativas e emocionantes para os tokens no futuro.

Leia também:

Explorando o mundo digital: como imóveis, obras de arte e outros se tornam emojis mágicos

O que são criptomoedas?

The post Tokens: definição, funcionamento e variedades appeared first on Blog do Banco do Brasil.

Nesta série de artigos pretendo mostrar sobre o estado atual da gestão de dívida técnica do Banco do Brasil e nossos próximos passos para amadurecer nosso processo. Mas para começarmos, vamos nivelar os entendimentos sobre o que é a dívida técnica.

Dívida é algo tratado de forma negativa em diversas culturas, mas compreender os mecanismos de funcionamento do capitalismo, ajuda-nos a entender que dívida é algo não só necessário, como bom. A dívida é um artifício de alavancagem econômica, ou seja, se você ou sua empresa precisam atingir um objetivo de curto prazo tem duas opções: (a) Poupar dinheiro pelo tempo necessário para então cumprir este objetivo ou; (b) Tomar um empréstimo para atingir este objetivo imediatamente e então seguir pagando este empréstimo ao longo dos meses seguintes, antecipando assim o início do retorno sobre o investimento. Sim, dívida é um artifício para melhorar o chamado “time to market”.

Com software temos o mesmo cenário. A dívida técnica é uma métrica usada para mensurar aspectos entendidos como negativos de um software e que “cobram seu preço” até que sejam extintos (pagos). É uma medida do quanto um software desvia de uma implementação ideal, gerando com isso alguma consequencia que pode ser estimada como custo ou risco, portanto ela irá aparecer em um software mesmo que o time não tenha decidido tomá-la; neste artigo Mark Schwartz inclusive sugere que seja usado o termo “Technical Delta”. Porém, antes de abordar sua correlação com alavancagem, vamos explorar as definições de dívidas técnicas existentes.

O que afinal é uma dívida técnica em software?

Há vários tipos de dívidas técnicas, como as facilmente detectáveis e mensuráveis, muitas vezes através de seus sintomas, como por exemplo: Uma má prática no código, como a chamada de uma API antiga ou uso de uma técnica que reduz a performance. Ferramentas de análise de código e dependências detectam e mensuram estas dívidas facilmente. Outro exemplo é uma fragilidade de segurança ou um defeito que podem ser detectados em produção ou em testes, antes mesmo do software ser implantado em produção. Em ambos os casos a detecção é clara e a mensuração dos custos para suas correções também. Em alguns casos estamos falando de apenas sintomas de uma dívida mais complexa (de design/arquitetura) e, portanto, de difícil detecção, ou simplesmente um sintoma da passagem do tempo e mudança do ambiente em torno do software.

Há também dívidas técnicas de difícil detecção e mensuração, como por exemplo: Uma arquitetura defasada, por defasada refiro-me a arquitetura de uma solução que já foi útil, mas que em determinado momento deixou de atender plenamente as necessidades do negócio ou cliente. É algo mais complexo do que simplesmente usar uma biblioteca defasada. Este exemplo de dívida aparece de forma sintomática, como por exemplo a queda de performance do software, o aumento de indisponibilidades ou até mesmo a queda da produtividade da equipe de desenvolvimento. A detecção deste tipo de dívida técnica dificilmente ocorre por meio de uma solução automatizada e muitas vezes não é clara, pois exige análise de especialistas, podendo até mesmo não haver consenso, tanto com relação a causa (identificação da dívida) quanto a solução (proposta para amortização da dívida).

Dívidas técnicas comprometem a capacidade do software em evoluir para continuar a atender as necessidades do cliente e do negócio, bem como comprometem a capacidade do software ser facilmente mantido/sustentado, tornando seu custo total elevado (TCO). Grande parte das decisões relacionadas a implementação de um software geram implicações que resultam em uma dívida técnica, como por exemplo a escolha de uma arquitetura ou um software de middleware pode ser adequada para o momento da aplicação, mas invariavelmente irá resultar em uma dívida técnica maior ou menor, em um futuro próximo. O objetivo do time e dos arquitetos de software de uma empresa deve ser tomar decisões que resultem em dívidas técnicas boas, ou seja, baratas e que resultem em riscos baixos.

Este artigo também aborda a dívida técnica como alavancagem e detalha 6 tipos de dívidas técnicas.

Dívida técnica é ruim?

No mundo empresarial uma dívida não é algo ruim, muito pelo contrário, há indicadores para determinados segmentos que mensuram o nível de endividamento de uma empresa. Estes indicadores podem ser interpretados de forma negativa caso seu endividamento esteja muito elevado ou muito baixo. Isso mesmo, uma dívida muito baixa ou inexistente é indicadora de que a empresa pode estar perdendo oportunidades de mercado e deixando de crescer, expondo-se a riscos como o de novos entrantes. A dívida é um mecanismo de alavancagem que empresas devem usar de forma a adquirir capacidade de atuar a frente de sua concorrência.

Uma boa gestão financeira é composta por uma boa capacidade de decisão com relação a quais dívidas devem ser tomadas, quais devem ser evitadas, quais são aquelas que precisam ser quitadas o mais rápido possível e quais devem ser roladas. Deve-se analisar aspectos como o risco que uma dívida impõe as finanças da empresa bem como seu “custo total”, frente aos ganhos esperados ao adquiri-la. Muitas vezes decide-se por rolar uma dívida, barata que representa baixo custo ou risco, outras vezes decide-se quitar rapidamente uma dívida cara, através da aquisição de outra dívida, mais barata. Para aproveitar uma oportunidade de mercado, uma empresa pode fazer uma dívida que parece ser cara e arriscada, mas que torna possível um negócio com retornos certos e fartos.

Os mesmos conceitos devem ser aplicados para a administração de dívida técnica, através do seu entendimento como um mecanismo de alavancagem de software ou um componente de seu custo. Isso ocorre no dia a dia de todos os times de desenvolvimento. Temos que saber identificar as dívidas técnicas de nossos softwares, saber administrá-las e compreender que um software sem nenhuma dívida técnica é um sinal tão ruim quanto um software tomado por dívidas.

Este artigo explora em mais detalhes a dívida técnica e propõem abordagens para seu “pagamento.”

Como gerenciar a dívida técnica em grandes corporações?

A clareza a este respeito é muito importante não só aos times de desenvolvimento, mas também áreas de governança e gestão de processos de TI que disciplinam a atuação destes times em grandes organizações, além dos líderes de negócio. Este conceito influencia fortemente regras que deverão ser seguidas por equipes de desenvolvimento de software. Para tornar este impacto mais claro, vamos trabalhar com alguns exemplos:

Uma dívida avaliada com estas premissas não deve ter data fixa para ser paga. O que precisamos é disciplinar indicadores que informam se um dado defeito de software é causado por uma dívida cara ou de alto risco ou barata e de baixo risco. O defeito deve ser corrigido, esta correção pode ser através do pagamento da dívida ou uma solução de contorno, rolando-se a dívida. Uma dívida que represente baixo risco e impacto para o funcionamento da aplicação, pode ser tolerado por anos, talvez seus efeitos, após uma solução de contorno sejam imperceptíveis.

Da mesma forma ao avaliar uma fragilidade de segurança sob esta ótica, precisamos identificar os fatores que as tornam arriscada e tomar a decisão a respeito de sua “quitação” baseada nestes fatores, e não quanto ao tempo decorrido de sua detecção. Fragilidades que colocam em elevado risco a sobrevivência e reputação da empresa naturalmente serão compreendidas originadas de dívidas a serem rapidamente quitadas e até mesmo inaceitáveis, ou seja, o software não deveria ser implantado com sua ocorrência. Mas esta não é uma decisão estritamente técnica, e sim de quem administra o negócio. É importante salientar que a fragilidade de segurança não é a dívida, podendo e geralmente devendo ser resolvida, com por exemplo uma solução de contorno, a exemplo do caso do defeito. A dívida geralmente é a causa raiz.

Modelar processos e indicadores que obrigam resolução (pagamento) de dívidas técnicas, baseados somente em tempo decorrido de sua detecção irá prejudicar a gestão desta dívida, gerando efeitos nocivos à saúde do software e da empresa, ao invés de benefícios. A temporalidade deve ser levada em consideração, mas ela não precisa e possivelmente não deve ser uma dimensão considerada para dívidas técnicas que representem baixo risco. O ponto polêmico será determinar em qual grau a análise do nível de risco de uma dívida, deve passar a desconsiderar sua data de detecção.

A dívida técnica de software é algo tão novo e obscuro para a administração de empresas, que precisa ser detectada, ou seja, administradores de empresas tomam estas dívidas inconscientemente! Faltam modelos de governança corporativa e disciplinas de gestão que incorporem estas dimensões nas práticas de gestão empresarial.

Ao compreender o funcionamento da sociedade capitalista, passamos a entender que uma dívida boa nós mantemos e dívidas ruins nós pagamos. A manutenção de uma dívida boa muitas vezes dá-se através do pagamento de seus juros, que muitas vezes são baixos, pagando-se o mínimo necessário do montante. Ao pagamento do montante chamamos de amortização. O mesmo pensamento deve ser aplicado a gestão de dívida técnica de um software. Pois estão presentes também, alguns conceitos como pagamento de juros e amortização. Vou fazer este paralelo a seguir.

As dívidas técnicas de um software geram dois efeitos: (a) risco, onde ela pode ou não comprometer severamente a sobrevida do software, gerando por exemplo uma indisponibilidade e causando prejuízos financeiros graves a empresa; ou (b) “juros” que se manifesta pelo aumento do TCO (custo total de propriedade) do software, este tipo de efeito pode ser visto em dívidas relativas ao uso de um arquitetura ou tecnologia obsoleta que prejudica a produtividade do time, ou que geram maior consumo de infraestrutura. Assim ao pagar esta conta não estamos amortizando a dívida, apenas convivendo com ela. Este pagamento de juros ocorre ao pagar uma conta mais elevada do seu provedor de nuvem ou adquirir um servidor mais potente, para dívidas que se manifestam na forma de performance; ou através de aumento do time de desenvolvimento, para aquelas que se manifestam como perda de produtividade.

Podemos decidir trocar uma dívida mais cara por outra que pareça mais barata, como por exemplo quando decidimos implementar uma solução “criativa” para reduzir o consumo de infraestrutura. Criamos assim uma outra dívida a ser paga, para com ela poder reduzir os juros da primeira dívida mais cara. Na maioria das vezes não eliminamos a primeira dívida, apenas aliviamos seus efeitos; ou seja, pagamos apenas seus juros ou amortizamos parcialmente, sem realizar a quitação. É uma troca de dívidas; esta implementação pode manifestar-se como perda da produtividade do time, ou aumento de instabilidade, ou seja, é uma dívida diferente com juros diferentes.

Não é melhor ficar sem dívida técnica?

Um software sem dívidas técnicas também significa um problema, este pode ser um sintoma de superdimensionamento do time que mantem este software, geralmente vejo como um sintoma de que a estratégia de negócio por trás deste software não está se alavancando o suficiente para atuar de forma arrojada no mercado em que ele é usado. Da mesma forma uma organização que persegue o zeramento das dívidas técnicas de seus softwares, está estrangulando a capacidade de alavancagem de sua estratégia de negócio.

Por outro lado, empresas com um elevado grau de dívidas técnicas em seus softwares, podem estar sofrendo do subdimensionamento de seu time, o que leva a seu corpo técnico a recorrer continuamente ao endividamento. Isso é conhecido como a temida “Death Spiral” (Espiral da Morte), se quiser conhecer mais sobre a espiral da morte, recomendo este artigo.

Todo gestor, seja empreendedor ou não, precisa administrar muito bem alguns indicadores chaves operacionais de sua empresa, como os indicadores de pessoas ou os financeiros. Neste artigo exploramos um conjunto de indicadores de software que deveriam fazer parte do portfólio estratégico de qualquer organização que possua produtos baseados em software. Indicadores de saúde na gestão de pessoas são modelados e liderados por especialistas na gestão de pessoas, porém são gerenciados por todos os administradores da organização, assim como os indicadores financeiros. No Banco do Brasil iniciamos um trabalho para termos um modelo de maturidade de gestão de dívida técnica, bem como processos organizacionais para a gestão desta dívida, incluindo aí a modelagem de indicadores. Nos próximos meses eu e outros colegas traremos novidades a respeito deste trabalho que envolve diversas áreas da TI do BB.

Está interessado em saber mais sobre o assunto? Alguns dos aspectos deste artigo são abordados de forma mais profunda e detalhada no livro Managing Technical Debt: Reducing Friction in Software Development, incluindo aí as analogias de montante e juros de dívida e a comparação com um financiamento imobiliário.

Leia também:

Kodiak: a nova tecnologia por trás do aplicativo do BB

APIs: o uso da documentação das APIs

Movimentos estratégicos: explorando o tabuleiro de xadrez do Domain-Driven Design

The post Como o BB está tratando Dívida Técnica – Parte 1 appeared first on Blog do Banco do Brasil.

A good rating in the app stores reflects the quality of the application and the value perceived by customers. This involves many factors, beyond relevant functionalities for the customer and a good experience, it is important to keep everything always working. I must say that it is not an easy mission.

With the large number of new things and adjustments that we put into the app every week; some bug will end up passing. There are many teams and developers making adjustments. In the last survey, there were more than 400.

In addition, it is important to know that the application update process is not trivial. The first challenge is to put all these changes together in one build of the app. Then make sure that all these changes are working properly. That nothing that has been changed breaks something that is already working. Then we must pass through the scrutiny of the stores (App Store and Play Store). And finally, we need the customer to update the app on their device so that the changes take effect – there is a significant portion of customers who do not update very frequently (it’s worth a dedicated article just to talk about our Mobile Deployment Process, note).

Always seeking to offer the best application on the market to our customers, in 2019 we began to seek new solutions to better deal with this scenario.

After a brilliant idea from Paula Moura, we started building Kodiak, which was named much later.

But what is this Kodiak?

Kodiak is a no-code/low-code solution fully developed internally at BB (patent pending). The main problem it sought to solve was to speed up mobile deliveries while ensuring security and quality.
To solve this problem, an architecture based on screen templates that could be dynamically parameterized to organize navigation flow and perform API consumption was conceived.

As a bonus, the fact that we use screen templates reduces development effort as well as standardization of interfaces, application of visual components, and accessibility.

But how does all this work?

Let’s explore Kodiak a bit. And for that, understanding how the template mechanics work is already halfway to understanding how this platform works.

Understanding the Templates

To facilitate the explanation, let’s talk a little about the process of creating a template until its use within the application. The following image illustrates some phases of this process.

1. Identifying a practical application case

The first step in having a template is to identify a practical use scenario. This step is the most important. We do not create templates based on hypothetical needs. Once we have the case in hand, we evaluate the existing templates and explore other approaches to solve the same scenario. Once identified that the best approach is to create a new template, we look for other possible application cases to make it as flexible as possible and move on to specification.

2. Template specification

The specification is still a design stage and therefore conducted by our UX team. In this stage, the components of our visual component library are identified – this is another important point, only components from our library can be used in templates and app screens. All font sizes, spacing, colors, and component application on the screen are also defined according to our Design Language System and, most importantly, accessibility guidelines.

3. Template available

Once specified, the template is built and made available on our Platform to be used in building screen flows. Recently we also started making available a Figma component that represents the template, thus facilitating the design process of new services that use Kodiak. Then it is just a matter of identifying the templates that best fit the needs of the product being built.

4. Configuration process

When using the template there is a “trick”. It is not necessary to use all components provided in the template, only those that make sense for the screen in question. This brings a lot of flexibility and several possibilities for applying the same template. The image above illustrates exactly this scenario where only part of the components provided are being used to instantiate the screen.

Enough with the small talk, I want to know about the technologies.

Let’s take a look under the hood. To make it easier, let’s use this diagram below, a simplified version of the system architecture.

We talked a little about the logic of how templates work, now let’s look at some of the technology that makes it work.

Kodiak SDK

Our app is built in React Native and naturally our templates are too, mainly because of the ease of integration and mastery we have of the technology. These templates along with the module that controls screen instantiation and communication with the Engine (our backend) are packaged into a library we call Kodiak SDK – using poetic license since Kodiak doesn’t produce code, but we’ll get there. This SDK is embedded in the apps we’re integrated with.

Engine, our orchestrator

With each screen navigation in the app, the SDK communicates with the Engine to find out which screen to display next. The Engine – which is built in JavaScript and runs on NodeJS – in turn retrieves the screen configuration, identifies which APIs to consume, consumes them and returns to the App a JSON containing the identification of the template to be instantiated and the data that will be shown to the client. The Engine is our screen and API orchestrator.

This architecture has some interesting gains:

• our APIs no longer need to be directly exposed on the internet.
• the fact that the App does not interact directly with the APIs makes them difficult to reverse engineer.
• only the data that will be used on the screen is returned, reducing unnecessary data traffic.
• it is possible to monitor more easily and clearly what is happening in the customer’s journey.
• the app becomes lighter.
• and most importantly, changes in flows do not depend on updating the app, they occur instantly.

Monitor, focus on availability and performance

One of the gain points mentioned was monitoring. This is a topic worth exploring a little further.
Every Service (the way we call screen flows that represent a functionality in the app) implemented in Kodiak is born monitored by default. Since every screen navigation ends up generating a call to our backend, we can observe these interactions.

We chose to use the Prometheus and Grafana stack to provide our developers with a panel where they can monitor their screen flows. This panel shows information such as:

• number of screen views.
• screen loading time (average and 99th percentile, which is important to highlight possible problems that affect only part of users).
• success rate in loading screens (today mainly affected by errors in interaction with APIs).
• number of errors.

All this data is collected per screen and per consumed API, which allows for a very rich monitoring of the whole environment.

OK, I understood how the runtime works. But what about development?

Every user interacting with Kodiak for the first time will go through our Hotsite that contains some basic information and will be directed to our “Get Started”.

The Get Started is a step-by-step tutorial in which the goal is to set up the development environment and finish the process with a small flow of screens running on the App (our Hello World).

Launcher, manager of the development environment

But don’t think that setting up the environment is a bunch of installation instructions for various tools. Here the Launcher comes into play. It is our installer that makes everything ready to use and is compatible with Windows, Linux and Mac. In addition to installing the Android emulator and all the necessary tools to run it, it keeps a process on the user’s computer. This process is what manages all the communication between our web interface of development and management and other tools installed on the user`s computer. It is also responsible for opening the emulator, installing and updating the versions of the App for developers and automating/abstracting whatever possible to make life easier for people – #dx.

Once everything is installed and the dev is minimally familiar with our systems we offer a self-instructional material in video lesson format, the “Kodiak 101: From zero to production”. In this training, which consists of about 20 topics with approximately 3.5 hours of video, we build a real product flow, from start to finish. The goal is to enable our devs to make their deliveries as soon as possible using the Platform.

Launchpad, the Godfather

In the previous paragraphs, when I mentioned our “web interface of development and management”, I didn’t call it by name. Many of you should have guessed that I was referring to Launchpad (React) and its backend, Launchpad API (JavaScript + NodeJS).

This is the guy who controls everything. He provides the interface for development and parameterization of flows, version control, deployment and rollback management, processes of approval, management of apps and development, testing and production environments.

Developing on Kodiak

Let’s look at the development process to see if it helps us understand the mechanics behind the scenes.
To develop something on Kodiak the first step is to have the Service created (which represents a product flow). Next, you need to select an SDK version (the newer the more features and templates available).
Now it’s time to add the screen template. After selecting the template, the dev assigns an identifier for the screen and can continue performing the parameterization of the APIs and components provided in the template. All this is done in a web form and the result, which is the screen configuration, is saved in a JSON document in our database.

Build and Deploy, making changes effective

Once all screens have been configured (their APIs, components and links from one to another), a package (our build) containing all the flow settings is generated. A version number is assigned to this package, which will be used to identify the package and to promote it to the testing and production environments.
In the end, the screen flow is a set of JSON documents (configurations) saved in a database. Promoting changes from one environment to another consists of copying this set of configurations from one database to another.

And here’s an important point that I haven’t talked about yet. The Engine is not a single element. For each application and processing environment (development, testing and production) there is an instance of the Engine running. This is very important so that there is no interference from one environment to another and so that the runtime environment is independent of the management/development environment.
In general, this is how Kodiak works.

Generating value for our customers and for the business

Imagine identifying an opportunity for improvement in a transactional flow and having this adjustment distributed to 100% of customers in less than 2 hours? I’m talking about the time between identifying the opportunity for improvement, making the adjustment and deploying it to all customers in this 2-hour window.

This is a real example that happened recently in our Prepaid Cell Phone Recharge service. An improvement in the screen flow doubled the conversion rate of one of the payment methods instantly.
More important than delivering new features is not breaking what is working, especially if it’s PIX =) (our primary money transferring method in Brazil). As much as we have all the care and various processes implemented to minimize the risk of bugs, it will happen sooner or later. With Kodiak, besides making adjustments very quickly we can undo changes instantly.

This is the kind of potential we are unlocking. To allow product teams to deliver solutions to customers very quickly. Evaluate the results and decide how to proceed.

We have cases where the complete flow was built and deployed in less than 10 days. This would not be feasible in a traditional mobile development process, counting all the quality steps we follow.

In addition, being a no-code/low-code solution, Kodiak allows developers without mobile experience to make deliveries on the app, greatly increasing the autonomy of product teams.

This is how we are transforming BB’s app.

The post Kodiak: The new technology behind the BB app appeared first on Blog do Banco do Brasil.

Uma boa nota nas lojas de aplicativos é reflexo da qualidade do aplicativo e do valor percebido pelos clientes. Isso envolve muitos fatores, além de funcionalidades relevantes para o cliente e de uma boa experiência é importante manter tudo sempre funcionando. Já adianto que não é uma missão fácil.

Com a grande quantidade de coisas novas e ajustes que colocamos todas as semanas no app, algum bug pode acabar passando. São muitos times e desenvolvedores fazendo ajustes. No último levantamento eram mais de 400.

Além disso é importante dizer que o processo de atualização do aplicativo não é algo trivial. O primeiro desafio é juntar todas essas alterações numa versão do app. Depois garantir que todas essas mudanças estejam funcionando direitinho. Que nada do que foi alterado quebre algo que já está funcionando. Aí temos que passar pelo crivo das lojas (App Store e Play Store). E por fim precisamos que o cliente atualize o app em seu dispositivo para que as alterações tenham efeito – existe uma parcela significativa dos clientes que atualiza com pouquíssima frequência.

Buscando sempre oferecer o melhor aplicativo do mercado para os nossos clientes, em 2019, começamos a buscar novas soluções para lidar melhor com esse cenário.

Mas o que é esse tal de Kodiak?

Kodiak é uma solução no-code/ low–code totalmente desenvolvida internamente no BB. Dar velocidade para as entregas do mobile, garantindo segurança e qualidade, era o principal problema que ela buscava resolver.

Para resolver esse problema foi concebida uma arquitetura baseada em templates de tela que pudessem ser parametrizados de forma dinâmica, para organizar o fluxo de navegação e realizar o consumo de APIs.

De quebra, o fato de utilizarmos templates de tela, diminui o esforço de desenvolvimento bem como de padronização das interfaces, aplicação de componentes visuais e acessibilidade.

Mas e na prática, como isso tudo funciona?

Vamos explorar um pouco do Kodiak. E para isso, entender como funciona a mecânica dos templates já é meio caminho andado para entender como funciona essa plataforma.

Entendendo os Templates

Para facilitar a explicação vamos falar um pouco do processo de criação de um template até o seu uso dentro de aplicativo. A imagem a seguir ilustra algumas fases desse processo.

1 – Identificando o caso prático de aplicação

O primeiro passo para termos um template é identificar um cenário prático de uso. Esse passo é o mais importante. Não criamos templates baseados em necessidades hipotéticas. Uma vez que temos o caso em mãos, avaliamos os templates e existentes e exploramos outras abordagens para resolver o mesmo cenário. Identificado que a melhor abordagem é criar um template, buscamos outros casos possíveis de aplicação para deixá-lo o mais flexível possível e partimos para a especificação.

2 – Especificação do template

A especificação ainda é uma etapa de design e por isso conduzida pelo nosso time de UX. Nessa etapa são identificados os componentes da nossa biblioteca de componentes visuais – esse é outro ponto importante, só componentes da nossa biblioteca podem ser utilizados nos templates e telas do app. Também são definidos todos os tamanhos de fonte, espaçamento, cores e aplicação dos componentes na tela conforme o nosso Design Language System e o mais importante, as diretrizes de acessibilidade.

3 – Template disponível

Uma vez especificado o template é construído e disponibilizados na nossa Plataforma para ser utilizado na construção dos fluxos de tela. Recentemente passamos a disponibilizar também um componente do Figma que representa o template, facilitando assim o processo de design de novos serviços que utilizem o Kodiak. Aí é só identificar os templates que melhor se encaixam com a necessidade do produto sendo construído.

4 – Configuração para uso

Na hora de utilizar o template existem um “pulo do gato”. Não é necessário utilizar todos os componentes previstos no template, apenas os que fazem sentido para a tela em questão. Isso traz muita flexibilidade e diversas possibilidades de aplicação de um mesmo template. A imagem acima ilustra exatamente esse cenário em que apenas uma parte dos componentes previstos está sendo utilizada para instanciar a tela.

Chega de conversa fiada, quero saber das tecnologias

Vamos dar uma espiada embaixo do capô. Para facilitar, vamos usar esse diagrama abaixo, uma versão simplificada da arquitetura do sistema.

Falamos um pouco sobre a lógica de funcionamento dos templates, agora vamos ver um pouco da tecnologia que faz isso funcionar.

SDK do Kodiak

Nosso app é construído em React Native e naturalmente nossos templates também, principalmente pela facilidade de integração e domínio que temos da tecnologia. Esses templates, juntamente com o módulo que controla a instanciação das telas e a comunicação com o Engine (nosso backend), são empacotados em uma biblioteca que chamamos de SKD do Kodiak – usando de licença poética uma vez que o Kodiak não produz código, mas vamos chegar lá. Essa SKD é embarcada nos apps com os quais estamos integrados.

Engine, o nosso orquestrador

A cada navegação de tela no aplicativo o SDK se comunica com o Engine para descobrir qual a próxima tela a ser exibida. O Engine – que construído em JavaScript e roda em NodeJS – por sua vez recupera a configuração da tela, identifica as APIs a serem consumidas, realiza o consumo das APIs e retorna para o App um JSON contendo a identificação do template a ser instanciado e os dados que serão mostrados para o cliente. O Engine é o nosso orquestrador de telas e APIs.

Essa modelo de execução tem alguns ganhos interessantes:

– nossas APIs não precisam mais ficar diretamente expostas na internet;

– o fato de o App não interagir diretamente com as APIs dificulta a engenharia reversa;

– são retornados apenas os dados que serão utilizados na tela reduzindo o tráfego de desnecessário de dados;

– é possível monitorar de forma mais fácil e clara o que está acontecendo na jornada do cliente;

– o app fica mais leve;

– o mais importante de todos, a alteração nos fluxos não depende de carga do app e ocorre de forma instantânea.

Monitor, foco na disponibilidade e performance

Um dos pontos de ganho citados foi a monitoração. Esse é um tópico que vale a pena explorar um pouco mais.

“Todos Serviços” (a forma como chamamos os fluxos de tela que representam uma funcionalidade no app) implantado no Kodiak nasce monitorado por padrão. Como toda navegação de tela acaba gerando uma chamada para o nosso backend conseguimos observar essas interações.

Optamos por utilizar a stack Prometheus e Grafana para fornecer aos nossos desenvolvedores um painel em que ele consegue acompanhar seus fluxos de tela. Nesse painel são mostradas informações como:

– quantidade de exibições de tela;

– tempo de carregamento das telas (média e percentil 99, que é importante para evidenciar possíveis problemas que afetam apenas parte dos usuários);

– taxa de sucesso nos carregamentos das telas (hoje afetado principalmente por erros na interação com as APIs);

– quantidade de erros;

Todos esses dados são coletados por tela e por API consumida, o que possibilita um acompanhamento muito rico do ambiente como um todo.

Ok, entendi como funciona o runtime. Mas e o desenvolvimento?

Todo usuário que está chegando no Kodiak pela primeira vez vai passar pelo nosso Hotsite que contém algumas informações básicas e direciona para o nosso “Get Started”.

O Get Started é um tutorial com o passo a passo em que o objetivo é configurar o ambiente de desenvolvimento e sair com um pequeno fluxo de telas executando no App (nosso Hello World).

Launcher, gerente do ambiente de desenvolvimento

Mas não pense que a configuração do ambiente é um monte de instruções de instalação de diversas ferramentas. Aqui entra o Launcher na história, nosso instalador que deixa tudo prontinho e é compatível com Windows, Linux e Mac. Além de instalar o emulador Android e todas as ferramentas necessárias para executá-lo, ele também mantém um processo no computador do usuário. Esse processo é quem faz toda a comunicação da nossa interface web de desenvolvimento e gerenciamento com as ferramentas instaladas no computador do usuário. Também é o responsável por abrir o emulador, instalar e atualizar as versões do App para os desenvolvedores e automatizar/abstrair o que for possível para facilitar a vida do pessoal – #dx.

Uma vez que tudo esteja instalado e o dev esteja minimamente familiarizado com os nossos sistemas, oferecemos um material autoinstrucional em formato de vídeo aula, o “Kodiak 101: Do zero a produção”. Nesse treinamento, que consiste em cerca de 20 tópicos com aproximadamente 3,5h de vídeo, construímos um fluxo real de um produto, do início ao fim. O objetivo é habilitar nossos devs a fazerem suas entregas o quanto antes utilizando a Plataforma.

Launchpad, o poderoso chefão

Nos parágrafos anteriores, quando citei nossa “interface web de desenvolvimento e gerenciamento”, não chamei ela pelo nome. Muitos de vocês dever ter sacado que eu estava me referindo ao Launchpad (React) e seu backend, Launchpad API (JavaScript + NodeJS).

Esse é o cara que controla tudo. Ele prova a interface de desenvolvimento e parametrização dos fluxos, controle de versão, gestão de implantações e rollbacks, fluxos de aprovação, gestão dos aplicativos e ambientes de desenvolvimento, homologação e produção.

Desenvolvendo no Kodiak

Vamos olhar um pouco para o processo de desenvolvimento para ver se nos ajuda a entender a mecânica por baixo dos panos.

Para desenvolver algo no Kodiak o primeiro passo é ter o Serviço criado (que representa um fluxo de um produto). Na sequência é preciso selecionar uma versão de SDK (quanto mais novo mais funcionalidades e templates disponíveis).

Agora chegou a hora de adicionar o template de tela. Após selecionar o template o dev atribui um identificador para a tela e já pode seguir realizando a parametrização das APIs e componentes previstos no template. Tudo isso é feito em um formulário web e o resultado é a configuração da tela, salvo em um documento JSON na nossa base de dados.

Build e Deploy, implantando as alterações

Uma vez que todas as telas tenham sido configuradas (suas APIs, componentes e links de uma para a outra), é gerado um pacote (nosso build) contendo todas as configurações do fluxo. A esse pacote é atribuído um número de versão que será utilizado para identificar o pacote e para promovê-lo para os ambientes de homologação e produção.

No final das contas o fluxo de telas é um conjunto de documentos JSON (configurações) salvo em um banco de dados. Promover as alterações de um ambiente para o outro consistem em copiar esse conjunto de configurações de uma base de dados para outra.

E aqui tem um ponto importante que não falei ainda. O Engine não é um elemento único. Para cada aplicativo e ambiente de processamento (desenvolvimento, homologação e produção) existe uma instância do Engine rodando. Isso é muito importante para que não haja interferência de um ambiente no outro e para que o ambiente de runtime seja independente do ambiente de gerenciamento/ desenvolvimento.

De modo geral é assim que o Kodiak funciona.

Gerando valor para os clientes e para o negócio

Imagine identificar uma oportunidade de melhoria em um fluxo transacional e ter esse ajuste distribuído para 100% dos clientes em menos de duas horas? Estou falando do tempo entre a identificação da oportunidade de melhoria, a realização do ajuste e a implantação para todos os clientes nessa janela de tempo de duas horas.

Esse é um exemplo real que aconteceu recentemente no serviço de Recarga de Celular. Uma melhoria no fluxo de telas dobrou a taxa de conversão de um dos meios de pagamento instantaneamente.

Mais importante que entregar novidades é não quebrar o que está funcionando, principalmente se for o PIX. Por mais que tenhamos todo o cuidado e diversos processos implantados para minimizar o risco de bugs, uma hora vai acontecer. Com o Kodiak, além de fazer ajustes de forma muito rápida conseguimos desfazer as alterações de forma instantânea.

Esse é o tipo potencial que estamos destravando. Permitir que os times de produto entreguem soluções para os clientes de forma muito rápida. Avaliem os resultados e decidam como prosseguir.

Temos casos em que o fluxo completo foi entregue em menos de 10 dias. O que não seria viável em um processo tradicional de desenvolvimento mobile, contanto todas as etapas de qualidade que seguimos.

Além disso, por ser uma solução no-code/low-code, o Kodiak permite que desenvolvedores sem experiência em mobile realizem entregas no app, aumentando muito a autonomia dos times de produto.

É dessa forma com que estamos transformando o aplicativo do BB.

The post Kodiak: a nova tecnologia por trás do aplicativo do BB appeared first on Blog do Banco do Brasil.

Documentar um software sempre foi um desafio no desenvolvimento de sistemas. Uma documentação incompleta gera uma experiência negativa em consumo de nossos serviços, com um maior número de erros, maior tempo para a compreensão das funcionalidades.

Em tempos não tão remotos, para se integrar com um serviço fornecido pelo banco era necessário ler PDFs com uma documentação extensa. Lembro quando trabalhei com desenvolvimento em Visual Basic 6 em uma fábrica de software, existia um manual apostilado que parecia com uma bíblia sobre integração de arquivos com bancos, mas felizmente hoje temos o Open API.

O que é o OpenAPI?

OpenAPI é uma linguagem padrão de mercado que é agnóstica de linguagem de programação, utilizada para descrever APIs REST e que permite de forma simples que máquinas e pessoas entendam quais serviços são oferecidos sem a necessidade de documentações extensas.

Por possuir informações essenciais para o negócio, esse é o primeiro documento que o desenvolvedor deverá analisar para entender quais serviços são oferecidos, o que deverá ser informado e o que será entregue.

Qual a diferença do OpenAPI e do Swagger?

Até 2015 a especificação foi renomeada de Swagger para OpenAPI. Essa mudança de nome gerou muita confusão, alguns chamavam de Swagger, outros de Open API e outros achavam que eram coisas diferentes.

Para entender melhor a diferença:

OpenAPI

É a especificação  originalmente baseada no Swagger e que foi doada pela SmartBear Software e hoje é mantida pela OpenAPI Iniciative, formado por um grupo de especialistas e organizações de diferentes áreas da tecnologia e que foca na criação, evolução e promoção de um formato neutro em relação a fornecedores.

Swagger

É o nome de algumas ferramentas utilizadas para implementar a especificação OpenAPI, sendo muito conhecido o SwaggerUI (utilizado para editar um e visualizar uma especificação), SwaggerHUB (utilizado para design e documentação de APIs). Apesar do Swagger possuir uma das ferramentas mais famosas, elas não são as única para escrever uma especificação OpenAPI.

Estrutura do OpenAPI

Basicamente uma especificação OpenAPI bem escrita nos fornecerá as seguintes informações:

– nome e descrição da API e de seus endpoints;

– informações de contato;

– endpoints e método de cada recurso oferecido pela API;

– forma de autenticação para acesso aos recursos;

– códigos de retorno na resposta;

– informações sobre campos e parâmetros, como nome, tipo, formato, obrigatoriedade e exemplos.

Abaixo vemos o exemplo de uma documentação OpenAPI

Benefícios

Por ser uma linguagem simples, ela é compreensível por pessoas não técnicas, facilitando o alinhamento entre áreas técnicas e áreas de negócio e ajudando a mitigar problemas de comunicação entre as áreas.

O OpenAPI também facilita os testes das APIs, visto que é importado facilmente em ferramentas como Postman e Insomnia e já traz os testes quase prontos, necessitando somente alguns ajustes como inclusão de credenciais.

Também é possível gerar bibliotecas em dezenas de linguagem de programação diferentes, reduzindo o tempo de desenvolvimento.

Como fazemos no BB

No BB, a especificação OpenAPI é o primeiro documento a ser escrito quando está sendo desenvolvido um serviço. A concepção de Contract First que é possível ao realizar a criação da especificação nesse momento ajuda o entendimento dos envolvidos do que será oferecido, informações necessárias e formato dos dados.

É um documento criado pelo time  de desenvolvimento com a área de negócio, com curadoria e apoio do Time de Gestão de APIs da Diretoria de Tecnologia e Diretória de Negócios Digitais.

Após a homologação por todos os envolvidos, o time de desenvolvimento inicia a construção dos serviços. Isso garante um menor tempo de construção e disponibilização aos parceiros, visto que o desenvolvedor já sabe o que será desenvolvido com base no OpenAPI e os times de negócio já iniciam a oferta dos serviços a parceiros, sabendo o que será disponibilizado.

Como se trata de uma linguagem de amplo conhecimento no mercado, percebemos uma melhora de experiência do cliente ao usar nossos serviços, diminuindo consideravelmente o tempo necessário para integração.

Assim vemos o OpenAPI como um meio de geração de negócios e entrega de valor para os nossos clientes e parceiros.

Mais informações sobre a especificação OpenAPI podem ser obtidas através do site oficial https://www.openapis.org/.

Leia também:

O BB onde você nem imagina: conheça as APIs do Banco do Brasil

O que é Banking as a Service (BaaS)?

Banking as a Service: perspectivas para o futuro do sistema bancário

Movimentos estratégicos: explorando o tabuleiro de xadrez do Domain-Driven Design

The post APIs: o uso da documentação das APIs appeared first on Blog do Banco do Brasil.

Felipe Windmoller, with more than 20 years of IT experience, is a specialist at Banco do Brasil, focusing on mainframe, cloud, microservices, integration, DDD, SRE and observability.

Software development and a game of chess. At first, it might not be obvious to compare these two subjects and they might seem fundamentally different for you; however, these two topics are based on navigating an abundance of possibilities and choices and have more similarities than you could anticipate. In this article, I will take you through the strategic and tactical principles of Domain-Driven Design (DDD) comparing it to strategies and tactics of a chess match.

Chess Strategy

The objective of chess is very clear: we want to win the game! However, this is challenging. Let’s imagine the beginning of a game: each Pawn can move one or two squares and each Knight can also make two different moves. So, there are twenty different options to make the first chess move. To make things more complicated, after our first move it’s our opponent’s turn and then we must come up with a new decision. The number of possibilities increases exponentially as we try to calculate the movements that can be done depending on our opponent’s decision. Some great masters are reputed to predict 15 to 20 moves ahead.

So, how do we know what is a good opening movement? Chess strategy can guide us. In the chess strategy the game is divided into three phases: opening, middle and end game. In the opening, we must follow these principles: control the center of the board, develop our minor pieces – the Knights and Bishops – castling to protect our King and move our Queen to connect our Rooks. After accomplishing these principles, we finish the opening phase and enter the middle game. Studies have proved that following these principles improve our chances of winning the game.

Having the opening strategy clarified it looks easier to choose our first move. For example, we can move our Queen Pawn to d4, and it seems perfect according to strategy principles and it meets two strategy objectives. First, the Pawn now is in position to control c5 and e5 squares and so we are in the center of the board and one step closer to get control of it. Second, it gives space for our Bishop and Queen to move.

Strategy and Heuristics

 As stated before, the number of possible moves in a chess game can be overwhelming and strategy helps us find faster and better ones. The mental technique of taking shortcuts to solve complex problems fast is called heuristic. It provides us with results that are good enough for our immediate goals. This is useful when we need to make a decision, but we would take too much time analyzing all the information and possibilities. Bringing this to our discussion here imagine it is your turn to make a move in the game and there are around 20 different possibilities, however now you know there are strategies you can follow and reduce this number to 5. The idea is that heuristic would help you choose within these 5 possibilities, making it possible for you to make a good move, not necessarily the best, but fast since you had less options.

Domain-Driven Design Strategy 

It has been said that the objective of a chess game is to win. In comparison, what is our goal in an IT project? The simplest answer is that we must resolve a business problem with a software solution. Therefore, the most important element in a software project is to understand the problem, because no matter how good our implementation is, if we don’t understand the business requirements it will be impossible to achieve our purpose.

Furthermore, as in chess, in the IT world we are also overwhelmed with information and different possibilities. For example: how do we evaluate our options and choose the best one to build a software that can suit the business problem? Depending on the domain complexity the number of options is huge and it’s difficult to make a decision.

Domain-driven design (DDD) is a technique which was created by Eric Evans in 2003 to help us improve the communication between businesspeople and IT and give us heuristics to decide the best software implementation. In the same way which chess strategy helps us choose what piece we should move to start the game, DDD strategies also help us make choices to build a software that serves the business needs.

The strategies, simplifying, are to identify the business domain and its subdomains, build the ubiquitous language and design the bounded contexts. We should first understand these concepts and then see how they can help us build software projects.

Business Domain and Subdomains 

The business domain is the market in which a company is inserted such as investments, credit card, marketing. It is divided into subdomains which are the business building blocks working together and allowing the company to exist. Let’s take a retail company for example, some subdomains could be customers, accounting, and stocking.

There are three types of subdomains: core, generic and supporting. Core subdomains are the important ones because they differentiate a company from others and it’s what makes the company special and successful. They are complex and are always changing to generate improvements.

Supporting subdomains are the simple ones, they don’t change too much and don’t make the company unique. However, we must build them ourselves because there are no pre-made solutions available, or it’s just an easier solution rather than developing the integration with a ready-made one.

Generic subdomains are complex but not unique and so they don’t make the company special. They are problems that have been solved before, even by other industries, and there are solutions out there that we can use, as software you can buy or use for free. For instance, think about encryption, unless this is the core business of the company it is smarter to use something that is already made instead of developing it from scratch.

In chess we wonder which piece we should move first. In a software project we ask what type of architecture we should use. Perhaps, layered architecture? Hexagonal architecture? Command and query responsibility segregation (CQRS)? Strategic DDD gives us some heuristics to decide. Depending on the subdomain type we can pick the best architecture. For a simple supporting subdomain, we can go with layered architecture but for a core subdomain, which is complex and changes often, hexagonal architecture could be a better option.

Ubiquitous Language and Bounded Contexts

As mentioned earlier, communication between businesspeople and IT is challenging. Often, there are two separate languages: one understood by domain experts, and another used by software programmers. This issue increases the cognitive load on teams and makes misunderstandings more likely. It’s a bit like the telephone game kids play. The requirements from businesspeople need to go from the language domain experts use to the one programmers understand, and, frequently, this translation is far from perfect.

The strategy proposed by domain-driven design to tackle this problem of communication is to adopt the same terminology used by the business specialists in everywhere in a software project. This means that the same terms used in the meetings between the domain experts and IT people will show up in domain models, tables, and programs. That’s why the name of this pattern is ubiquitous language, which is a single language used everywhere to keep things clear and consistent.

However, when people talk, some words can have different meanings depending on the situation. For instance, in a sales context, “customer” might refer to someone who purchases goods, while in a support context, it could refer to someone seeking assistance. This dubiousness isn’t a problem for human conversations, but software programs don’t admit ambiguities, everything must have one clear definition.

To overcome this problem, strategic DDD has the bounded context pattern. The idea is just like the name suggest, we delimit a context to the meaning of our terms. In our previous example of the term “customer”, we would have a bounded context named “sales” and another one called “support”. Therefore, inside de “sales” bounded context, the word “customer” is going to have exactly one meaning.

Microservices and Domain-Driven Design

In a microservices architecture, getting the size of our services right is very important. If they are too big, they become individually very complex and difficult to maintain. On the other hand, if they are too small, the global complexity of lots of tiny microservices communicating between them is going to be high. DDD helps us with some heuristics: a service shouldn’t be bigger than the bounded context, or else our language won’t be clear, and the software could get really complicated. Usually, the size of a microservice fits well with a subdomain. The application boundaries will follow how the business works, and new features from businesspeople typically get added to a single microservice, without causing a ripple effect where multiple microservices will need to be changed and deployed together.

Strategies and Tactics

Strategies serve as guiding principles that steer us towards optimal choices, offering a roadmap to attain overarching objectives. Whether aiming to triumph in a chess match or excel in a software project, strategies outline the trajectory for long-term success. In contrast, tactics are more about quick results. They focus on getting things done in a short amount of time.

Chess Tactics

Chess tactics are clever tricks that players use to catch their opponents off guard or win quickly. One famous tactic is the double attack. This happens when a single move creates two problems for the opponent, and they can’t solve both. Look at the picture below: the Knight is attacking both the King and the Rook at the same time. The opponent must move the King, and in the next turn, he will lose the Rook.

Domain-Driven Design Tactics

While strategic DDD provides us with guidance for comprehending business requirements and crafting software solutions aligned with company objectives, tactical domain-driven design operates within the practical realm of coding programs. The three most recognized tactical patterns of DDD are value objects, entities, and aggregates.

Value objects are important components in programming that help us represent specific pieces of information, like dates or money amounts, in a clear and consistent way. They’re like little containers for data and rules that make our code easier to understand and maintain. Value objects are special because once we create them, we can’t change them, which keeps our data reliable. They’re like building blocks that help us create strong and reliable software. Value objects can be identified by the composition of their values.

Entities are essential in programming as they represent the core elements in a system that have unique identities and behaviors. Just like characters in a story, entities hold important information and can interact with each other. These objects help us model real-world concepts, like customers or orders, making our software more reflective of the actual situation. Because entities have individual identities, they’re crucial for tracking and managing data accurately. In programming, entities act as the main characters that drive our applications.

Aggregates are vital in programming because they group together related entities and value objects, creating a more organized structure for our code. Think of them as containers that hold everything needed to handle a specific part of our system. Aggregates help us manage complex data and interactions by providing a clear boundary for operations. This makes our code more understandable and reduces the chances of errors. In programming, aggregates act as the guardians of consistency and integrity, ensuring that our data stays accurate and dependable.

Final Words

To wrap things up, both DDD strategy and chess strategy guide our choices. Imagine strategy as a big plan for the long run, and tactics as practical steps for right now. It’s like having a map for the journey and tools for the adventure. Despite the differences between chess and IT, they both share a common goal: a desire for success. In chess, we aim to win the match, and in IT, we strive to succeed in our projects.

The post Strategic Moves: Exploring the Chessboard of Domain-Driven Design appeared first on Blog do Banco do Brasil.

Desenvolvimento de software e um jogo de xadrez. À primeira vista, pode não ser óbvio comparar esses dois assuntos, e eles podem parecer fundamentalmente diferentes para você; no entanto, esses dois tópicos baseiam-se em percorrer uma abundância de possibilidades e escolhas e têm mais semelhanças do que você poderia imaginar.

Neste artigo, apresentarei os princípios estratégicos e táticos do Domain-Driven Design (DDD), comparando-os às estratégias e táticas de uma partida de xadrez.

Estratégias no xadrez

O objetivo do xadrez é muito claro: queremos ganhar o jogo! No entanto, isso é um desafio. Imaginemos o início de uma partida: cada peão pode mover uma ou duas casas, e cada cavalo também pode fazer dois movimentos diferentes. Portanto, existem vinte opções diferentes para fazer o primeiro movimento de xadrez. Para complicar ainda mais as coisas, depois do nosso primeiro movimento, é a vez do nosso adversário, e então devemos tomar uma nova decisão. O número de possibilidades aumenta exponencialmente à medida que tentamos calcular os movimentos que podem ser feitos, dependendo da decisão do nosso adversário. Alguns grandes mestres têm a reputação de prever de 15 a 20 movimentos.

Então como sabemos qual é um bom movimento de abertura? A estratégia do xadrez pode nos guiar. O jogo é dividido em três fases: abertura, meio e fim. Na abertura, devemos seguir estes princípios: controlar o centro do tabuleiro, desenvolver nossas peças menores (cavalos e bispos) fazer o roque para proteger o nosso rei e mover a nossa dama para conectar as nossas torres. Após cumprir esses princípios, finalizamos a fase inicial e entramos no meio da partida. Estudos provaram que seguir esses princípios aumenta as nossas chances de ganhar o jogo.

Tendo a estratégia de abertura esclarecida, parece mais fácil escolher o nosso primeiro movimento. Por exemplo, podemos mover nosso peão da rainha para d4, e ele parece perfeito de acordo com os princípios estratégicos e atende a dois objetivos estratégicos. Primeiro, o peão agora está em posição de controlar as casas c5 e e5 e, portanto, estamos no centro do tabuleiro e um passo mais perto de controlá-lo. Em segundo lugar, dá espaço para o nosso bispo e rainha se moverem.

Estratégia e heurística

Como afirmado anteriormente, o número de movimentos possíveis num jogo de xadrez pode ser esmagador, e a estratégia nos ajuda a encontrar movimentos melhores e mais rápidos. A técnica mental de tomar atalhos para resolver problemas complexos rapidamente é chamada de heurística. Ela nos fornece resultados bons o suficiente para nossos objetivos imediatos. Isso é útil quando precisamos tomar uma decisão, mas demoraríamos muito tempo analisando todas as informações e possibilidades. Trazendo isso para a nossa discussão aqui, imagine que é a sua vez de fazer uma jogada e existem cerca de 20 possibilidades diferentes, porém agora você sabe que existem estratégias que pode seguir e reduzir esse número para 5. A ideia é que a heurística ajudaria você escolher dentro dessas 5 possibilidades, possibilitando que você faça uma boa jogada – não necessariamente a melhor, mas mais rápida, já que você teria menos opções.

Estratégias do Domain-Driven Design

Já foi dito que o objetivo de um jogo de xadrez é vencer. Em comparação, qual é o nosso objetivo em um projeto de TI? A resposta mais simples é que devemos resolver um problema de negócios com uma solução de software. Portanto, o elemento mais importante em um projeto de software é entender o problema, pois, por melhor que seja a nossa implementação, se não entendermos os requisitos de negócio, será impossível atingir o nosso propósito.

Além disso, como no xadrez, no mundo da TI também estamos sobrecarregados de informações e possibilidades diversas. Por exemplo: como avaliamos nossas opções e escolhemos a melhor para construir um software que atenda ao problema do negócio? Dependendo da complexidade do domínio, o número de opções é enorme, e é difícil tomar uma decisão.

Domain-Driven Design (DDD) é uma técnica criada por Eric Evans em 2003 para melhorar a comunicação entre a área de negócio e a de TI e nos dar heurísticas para decidir a melhor implementação de software. Da mesma forma que a estratégia do xadrez nos ajuda a escolher que peça devemos mover para iniciar o jogo, as estratégias do DDD nos ajudam a fazer escolhas para construir um software que atenda às necessidades do negócio.

As estratégias, simplificando, consistem em identificar o domínio de negócio e seus subdomínios, construir a linguagem ubíqua e modelar os contextos delimitados. Devemos primeiro entender esses conceitos e depois ver como eles podem nos ajudar a construir projetos de software.

Domínio de negócio e subdomínios

O domínio de negócio é o mercado em que uma empresa está inserida, como investimentos, cartão de crédito, marketing. Ele está dividido em subdomínios, que são os blocos de construção do negócio que trabalham em conjunto e permitem a existência da empresa. Tomemos como exemplo uma empresa de varejo. Alguns subdomínios podem ser clientes, contabilidade e estoque.

Existem três tipos de subdomínios: core, genérico e de suporte. Os subdomínios core são importantes porque diferenciam uma empresa das outras e é o que torna a empresa especial e bem-sucedida. São complexos e estão sempre mudando para gerar melhorias.

Os subdomínios de suporte são simples, não mudam muito e não provêm um diferencial competitivo para a empresa. No entanto, devemos construí-los nós mesmos, porque não existem soluções pré-fabricadas disponíveis ou porque é apenas mais fácil desenvolvê-los do que implementar uma integração com uma solução já pronta.

Os subdomínios genéricos são complexos, mas não únicos e, portanto, não tornam a empresa especial. São problemas que já foram resolvidos antes, até mesmo por outras indústrias, e existem soluções que podemos usar, como softwares que você pode comprar ou usar gratuitamente. Por exemplo, pense na criptografia: a menos que este seja o negócio principal da empresa, é mais inteligente usar algo que já foi feito em vez de desenvolvê-lo do zero.

No xadrez nos perguntamos qual peça devemos mover primeiro. Num projeto de software, perguntamos que tipo de arquitetura devemos usar. Talvez arquitetura em camadas? Arquitetura hexagonal? Segregação de responsabilidade de comando e consulta (command and query responsibility segregation – CQRS)? O DDD estratégico nos dá algumas heurísticas para decidir. Dependendo do tipo de subdomínio, podemos escolher a melhor arquitetura. Para um subdomínio de suporte simples, podemos optar pela arquitetura em camadas, mas para um subdomínio core, que é complexo e muda frequentemente, a arquitetura hexagonal pode ser uma opção melhor.

Linguagem ubíqua e contextos delimitados

Conforme mencionado anteriormente, a comunicação entre a área de negócio e a TI é um desafio. Frequentemente, existem duas linguagens distintas: uma compreendida por especialistas no domínio de negócio e outra usada por programadores de software. Esse problema aumenta a carga cognitiva das equipes e incrementa a probabilidade de mal-entendidos. É um pouco como o jogo do telefone sem fio que as crianças jogam. Os requisitos das áreas de negócio precisam ir do domínio da linguagem que os especialistas de negócio usam até aquele que os programadores entendem e, frequentemente, essa tradução está longe de ser perfeita.

A estratégia proposta pelo Domain-Driven Design para resolver esse problema de comunicação é adotar a mesma terminologia usada pelos especialistas de negócio em todos os aspectos de um projeto de software. Isso significa que os mesmos termos usados nas reuniões entre os especialistas do domínio de negócio e os times de TI aparecerão em modelos, tabelas e programas. É por isso que o nome desse padrão é linguagem ubíqua, que é uma linguagem única usada em todos os lugares para manter as coisas claras e consistentes.

Porém, quando as pessoas falam, algumas palavras podem ter significados diferentes dependendo da situação. Por exemplo, num contexto de vendas, “cliente” pode referir-se a alguém que compra bens, enquanto num contexto de suporte pode referir-se a alguém que procura assistência. Essa dúvida não é problema para conversas humanas, mas os programas de software não admitem ambiguidades, tudo deve ter uma definição clara.

Para superar esse problema, o DDD estratégico possui um padrão chamado de “contexto delimitado”. A ideia é exatamente como o nome sugere: delimitamos um contexto ao significado dos nossos termos. No nosso exemplo anterior do termo “cliente”, teríamos um contexto delimitado denominado “vendas” e outro denominado “suporte”. Portanto, dentro do contexto delimitado de “vendas”, a palavra “cliente” terá exatamente um significado.

Microsserviços e Domain-Driven Design

Em uma arquitetura de microsserviços, definir corretamente o tamanho dos nossos serviços é muito importante. Se forem muito grandes, tornam-se individualmente muito complexos e difíceis de manter. Por outro lado, se forem demasiadamente pequenos, a complexidade global de muitos microsserviços minúsculos comunicando-se entre eles será elevada. O DDD nos ajuda com algumas heurísticas: um microsserviço não deve ser maior que um contexto delimitado, ou então a nossa linguagem não será clara, e o software poderá ficar muito complicado. Normalmente, o tamanho de um microsserviço se adapta bem a um subdomínio. As fronteiras do tamanho do aplicativo estarão em harmonia com o funcionamento do domínio de negócio, e as novas demandas de mudanças no sistema normalmente serão direcionadas a um único microsserviço, sem causar um efeito cascata em que vários microsserviços precisarão ser alterados e implantados juntos.

Estratégias e táticas

As estratégias servem como princípios orientadores que nos guiam para as melhores escolhas, oferecendo um roteiro para atingirmos objetivos globais. Seja com o propósito de triunfar em uma partida de xadrez ou de ter êxito em um projeto de software, as estratégias traçam a trajetória para o sucesso a longo prazo. Em contraste, as táticas nos direcionam a resultados rápidos. Elas se concentram em realizar ações em um curto espaço de tempo.

Táticas do xadrez

As táticas de xadrez são truques inteligentes que os jogadores usam para pegar seus oponentes desprevenidos ou vencer rapidamente. Uma tática famosa é o ataque duplo. Isso acontece quando um único movimento cria dois problemas para o oponente, e ele não consegue se defender de ambos. Veja a imagem abaixo: o cavalo está atacando o rei e a torre ao mesmo tempo. O adversário deve mover o rei e, no turno seguinte, perderá a torre.

Táticas do Domain-Driven Design

Embora o DDD estratégico nos forneça uma orientação para compreender os requisitos de negócios e criar soluções de software alinhadas com os objetivos da empresa, o Domain-Driven Design tático opera dentro do domínio prático da codificação dos programas. Os três padrões táticos mais reconhecidos do DDD são value objects (objetos de valor), entidades e agregados.

Value objects são componentes importantes na programação que nos ajudam a representar informações específicas, como datas ou valores monetários, de forma clara e consistente. Eles são como pequenos contêineres para dados e regras que tornam nosso código mais fácil de entender e manter. Os value objects são especiais porque, uma vez criados, não podemos alterá-los, o que mantém nossos dados confiáveis. Eles são como blocos de construção que nos ajudam a criar um software resiliente e confiável. Value objects podem ser identificados pela composição de seus valores.

As entidades são essenciais na programação, pois representam os elementos centrais de um sistema que possui identidades e comportamentos únicos. Assim como os personagens de uma história, as entidades contêm informações importantes e podem interagir umas com as outras. Esses objetos nos ajudam a modelar conceitos do mundo real, como clientes ou pedidos. Como as entidades têm identidades individuais, elas são cruciais para rastrear e gerenciar os dados com precisão. Na programação, as entidades atuam como os personagens principais que impulsionam nossas aplicações.

Os agregados são vitais na programação porque agrupam entidades relacionadas e value objects, criando uma estrutura mais organizada para o nosso código. Pense neles como contêineres que agregam tudo o que é necessário para lidar com uma parte específica do nosso sistema. Os agregados nos ajudam a gerenciar dados e interações complexas, fornecendo limites claros para as operações. Isso torna nosso código mais compreensível e reduz as chances de erros. Na programação, os agregados atuam como guardiões da consistência e integridade, garantindo que nossos dados permaneçam precisos e confiáveis.

Palavras finais

Para finalizar, tanto a estratégia do DDD quanto a estratégia do xadrez guiam nossas escolhas. Imagine a estratégia como um grande plano para o longo prazo e as táticas como etapas práticas para o momento. É como ter um mapa para a jornada e ferramentas para a aventura. Apesar das diferenças entre xadrez e TI, ambos compartilham um objetivo em comum: o desejo de sucesso. No xadrez o nosso objetivo é vencer a partida; na TI nos esforçamos para ter sucesso em nossos projetos.

The post Movimentos estratégicos: explorando o tabuleiro de xadrez do Domain-Driven Design appeared first on Blog do Banco do Brasil.