CADERNO DE ARQUITETURA PODER JUDICIÁRIO DE ......Domain Driven Design, 2018), pois esta baseia-se muito em seus princípios. O caminho definido para a criação de APIs, segue o modelo

1

CADERNO DE ARQUITETURA

PODER JUDICIÁRIO DE MATO GROSSO

Cuiabá – MT

2018

2

REVISÕES

DATA NATUREZA DA REVISÃO RESPONSÁVEIS VERSÃO

23/03/2018 Criação do caderno de arquitetura.

Gustavo Piccin

João Vitor 1.0

3

SUMÁRIO

1 Apresentação ................................................................................................. 1

1.1 Objetivo .......................................................................................................... 1

1.2 Público alvo .................................................................................................... 1

1.3 Aplicação ........................................................................................................ 1

1.4 Atribuições ..................................................................................................... 1

1.4.1 Arquiteto de software ...................................................................................... 1

1.4.2 Desenvolvedor ................................................................................................ 1

2 Ambientes de desenvolvimento ...................................................................... 2

2.1 Infraestrutura .................................................................................................. 2

2.2 Código Fonte .................................................................................................. 2

2.3 Ambientes ...................................................................................................... 3

2.3.1 DESENVOLVIMENTO (Dev) .......................................................................... 3

2.3.2 TESTE (Test) .................................................................................................. 3

2.3.3 HOMOLOGAÇÃO (Pre-production) ................................................................ 4

2.3.4 PRODUÇÃO (Production) .............................................................................. 4

2.4 Testes ............................................................................................................ 4

2.4.1 Ambientes ....................................................................................................... 4

2.4.2 Requisitos padrões de aceitação .................................................................... 4

2.5 Container ........................................................................................................ 5

3 Arquitetura ...................................................................................................... 6

3.1 Autenticação e autorização ............................................................................ 6

3.2 Frontend ......................................................................................................... 7

3.2.1 Conceito ......................................................................................................... 7

3.2.2 Tecnologias .................................................................................................... 7

3.2.3 Teste ............................................................................................................... 7

4

3.3 Backend ......................................................................................................... 8

3.3.1 Conceito ......................................................................................................... 8

3.3.2 Tecnologias .................................................................................................... 8

3.3.3 Arquitetura ...................................................................................................... 8

3.3.4 Teste ............................................................................................................. 10

3.4 Integrações .................................................................................................. 10

4 Ciclo de vida ................................................................................................. 11

4.1 Continuous Integration ................................................................................. 12

4.2 Continuous Delivery ..................................................................................... 13

5 Revisão ......................................................................................................... 13

Figuras 14

Tabelas ..................................................................................................................... 14

Referências Bibliográficas ......................................................................................... 14

PODER JUDICIÁRIO DO ESTADO DE MATO GROSSO COORDENADORIA DE TECNOLOGIA DA INFORMAÇÃO DEPARTAMENTO DE SISTEMAS E APLICAÇÕES CADERNO DE ARQUITETURA – V.1.0

1

1 APRESENTAÇÃO

1.1 Objetivo

Este documento tem por objetivo ilustrar e definir diretrizes para o

desenvolvimento de software no Poder Judiciário de Mato Grosso. Além disto, busca

evidenciar as tecnologias e padrões estabelecidos, tanto para o conhecimento público,

como forma de transparência da produção de software deste órgão, como para a

evolução e discussões tecnológicas a respeito dos variados temas aqui dispostos.

1.2 Público alvo

Este caderno é destinado a todos os colaboradores associados diretamente a

produção de software, em especial aos que contribuem nos aspectos estritamente

técnicos.

1.3 Aplicação

Dada a pluralidade de soluções tecnológicas ativas no Poder Judiciário e a

constante evolução tecnológica vivenciada pela comunidade mundial de software na

última década, este caderno de arquitetura é válido apenas para produtos

desenvolvidos a partir da data de publicação deste. Produtos legados seguem

diretrizes convencionadas em documento interno de Padrões de Desenvolvimento,

publicado em 2013 e atualizado em 2015.

1.4 Atribuições

1.4.1 ARQUITETO DE SOFTWARE

Responsável pela criação dos elementos básicos do projeto e por validar o

softwares produzidos de acordo com as diretrizes aqui dispostas.

1.4.2 DESENVOLVEDOR

Responsável pelo desenvolvimento das soluções, utiliza este material como

diretriz técnica obrigatória.


2

2 AMBIENTES DE DESENVOLVIMENTO

2.1 Infraestrutura

A ferramenta utilizada pelo TJMT para gerenciamento do ciclo de vida de uma

aplicação é o Team Foundation Server (Team Foundation Server, 2018).

Nele é realizada a gestão das necessidades do produto, do processo de

construção, do código-fonte, da homologação, da publicação e das demais etapas

envolvidas no processo de desenvolvimento de software.

2.2 Código Fonte

A gestão do código fonte é realizada pelo mecanismo GIT e o modelo de

trabalho adotado para a gestão das “branches”, ou ramificações do código fonte, é o

GitFlow (Vincent Driessen , 2018).

Neste modelo, as “branches” de desenvolvimento são criadas para atender a

necessidades especificas de mudança no código e possuem, preferencialmente, um

tempo de vida curto. Após a finalização de cada mudança, esta é integrada (“merge”)

na “branch” denominada como “DEVELOP” e posteriormente para a “MASTER”.

A Tabela 1 apresenta as convenções estabelecidas, bem como a relação

entre “branches” e ambientes:

AMBIENTE DESENVOLVIMENTO

ALPHA

TESTE

BETA

HOMOLOGAÇÃO

RC

PRODUÇÃO

STABLE

BRANCH

(Feature branches) DEVELOP

RELEASE-*

ou

HOTFIX-*

(Release branches)

MASTER

BUILD/RELEASE ALPHA-Y BETA RC STABLE

ENDEREÇO DO

AMBIENTE

http://{Projeto}-alpha-

Y.tjmt.jus.br

http://{Projeto}-

beta.tjmt.jus.br

http://{Projeto}-

rc.tjmt.jus.br

http://{Projeto}-

tjmt.jus.br

Tabela 1 - Convenções entre ambientes e endereços


3

2.3 Ambientes

Cada ambiente é utilizado com um propósito específico durante o processo de

desenvolvimento. A Figura 1 representa os ambientes (“enviroments”), as

ações realizadas (“actions”) em cada fase e seus responsáveis (“approvers”).

Figura 1 - Fluxo de ambientes

2.3.1 DESENVOLVIMENTO (DEV)

Ambiente dinâmico criado para o desenvolvedor produzir e testar cada

modificação de forma individual.

2.3.2 TESTE (TEST)

Ambiente dinâmico criado para a execução de testes automatizados,

unitários, de integração, de carga, assim como análises manuais e demais validações

necessárias.


4

2.3.3 HOMOLOGAÇÃO (PRE-PRODUCTION)

Ambiente dinâmico criado para validação de impactos em produção e

aceitação do usuário.

2.3.4 PRODUÇÃO (PRODUCTION)

Ambiente fixo destinado a disponibilização da versão final do produto utilizada

pelos clientes.

2.4 Testes

2.4.1 AMBIENTES

De forma objetiva, a Figura 2 estabelece a relação entre os estágios do

desenvolvimento de software e suas ações de teste e monitoramento.

Figura 2 - Ambientes de teste

2.4.2 REQUISITOS PADRÕES DE ACEITAÇÃO

Os requisitos quanto da qualidade de código seguem os parâmetros

especificados na Tabela 2. Qualquer software produzido fora destes padrões deve ser

justificado e aprovado.

MÉTRICA MÍNIMO

Cobertura de testes unitários 80%

Cobertura de testes de integração 80%

Cobertura de testes de interface 50%


5

MÉTRICA MÍNIMO

Complexidade método Complexidade ciclomática menor que 15

Taxa de duplicações de Igual ou menor que 2%

Taxa de sucesso em testes 100%

Documentação do código 80%

Tabela 2 - Requisitos padrões de testes

2.5 Container

Considerando que o TJMT possui um ambiente orquestrador de “containers”

denominado Kubernetes (Wikipedia, 2018), toda versão de um sistema deve ser

entregue por meio de “container” Docker (Wikipedia, 2018).

Para todos os serviços a serem publicados, deve existir em seu repositório de

código fonte um arquivo de definição do “container” (“dockerfile”), que tem por objetivo

criar uma imagem de “container” em que deverá conter os arquivos do serviço e um

servidor web preparado para rodá-lo.

Cada arquivo de definição do container deve conter minimamente:

1) Processo de compilação

a) Imagem base utilizada para compilar

b) Execução da Compilação do(s) projeto(s)

c) Execução dos Testes Unitários

2) Processo de execução

a) Imagem base contendo servidor web

b) Configuração e Cópia dos arquivos para execução

Também deve existir em seu repositório de código fonte um arquivo (“docker-

compose.yml”), que será utilizado para publicar o serviço em questão em um dos

ambientes do ciclo de vida do software.


6

3 ARQUITETURA

3.1 Autenticação e autorização

Toda aplicação ou serviço que necessite de identificação do usuário ou

controle de acesso, deve utilizar o serviço de gerenciamento de identidade implantado

no TJMT denominado Cerberus e seguir a todos os seus requisitos. Em suas últimas

versões, esta plataforma foi expandida para suportar Single Sign On (Wikipedia, 2018)

com o protocolo OAuth e OpenID Connect.

Cada plataforma de desenvolvimento como .NET, JAVA e Javascript,

possuem bibliotecas que fazem uso de autenticação utilizando os protocolos acima

citados e seguem o fluxo de autenticação apresentado na Figura 3.

Figura 3 - Fluxo de autenticação


7

3.2 Frontend

3.2.1 CONCEITO

Frontend ou interface gráfica do usuário (abreviadamente, o acrônimo GUI, do

inglês Graphical User Interface) é um tipo de interface do utilizador do sistema que

permite a interação com dispositivos digitais por meio de elementos gráficos como

ícones e outros indicadores visuais (Wikipédia, 2018).

3.2.2 TECNOLOGIAS

O framework destinado ao desenvolvimento de interfaces no TJMT é o

Angular (https://angular.io/) com a linguagem Typescript

(https://www.typescriptlang.org/).

Como base para a criação de novos projetos um padrão arquitetural base de

interface foi criado e nomeado como Aurora. Neste projeto existem componentes

reutilizáveis e estilizados com a identidade visual convencionada.

Detalhes da utilização deste projeto, assim como seus componentes estão

detalhados em ambiente interno próprio e podem ser verificados em:

http://alm.tjmt.jus.br/Desenvolvimento/DSA/_wiki?pagePath=%2FPADR%C3%95ES

%2FArquitetura%2FFrontend

3.2.3 TESTE

Assim como definido em “2.4 Testes”, os testes de interface seguem as

mesmas definições lá estabelecidas. No entanto, quando falamos de teste de

interface, o teste de integração é feito em cima dos elementos da interface, que no

caso da web é o DOM (Modelo de Objeto de Documento - DOM, 2018).

Neste caso, foi criado um projeto com o objetivo de se criar e executar os

testes de interface como integração, fazendo uso de um projeto já criado e publicado,

aplicações desta natureza são denominadas como End-To-End (Guru99, 2018).

Os testes End-to-End são descritos usando os conceitos do Behavior-driven

development (Behavior-driven development, 2018) por meio da framework Cucumber

(Cucumber, 2018). Detalhes da criação, desenvolvimento e execução podem ser

verificados em:

https://angular.io/

https://www.typescriptlang.org/

http://alm.tjmt.jus.br/Desenvolvimento/DSA/_wiki?pagePath=%2FPADR%C3%95ES%2FArquitetura%2FFrontend



8

http://alm.tjmt.jus.br/Desenvolvimento/DSA/_wiki?pagePath=%2FPADR%C3

%95ES%2FArquitetura%2FFrontend

3.3 Backend

3.3.1 CONCEITO

Backend é o nome dado à execução de código do lado do servidor. Neste

código, é onde normalmente são criadas e validadas as regras de negócio, acesso à

dados, integrações e demais atividades que o negócio necessite.

O conceito backend é normalmente voltado a serviços web (Web service,

2018), os quais são majoritariamente criados utilizando os modelos REST (REST,

2018) e SOAP (SOAP, 2018).

3.3.2 TECNOLOGIAS

As linguagens permitidas para o desenvolvimento backend no TJMT são

JAVA (JAVA, 2018) e .NET (.NET, 2018).

Em uma criação de novos serviços web (backend), o modelo definido é o

REST, salvo casos que tratam de integração com aplicações legadas ou outras

exceções avaliadas individualmente.

3.3.3 ARQUITETURA

A arquitetura utilizada no TJMT para a criação de novos produtos é a de Micro-

serviços (Microservice Architecture, 2018).

Para se ter uma compreensão de uma arquitetura Micro-serviços, deve-se

antes possuir um conhecimento em Domain Driven Design (DDD – Introdução a

Domain Driven Design, 2018), pois esta baseia-se muito em seus princípios.

O caminho definido para a criação de APIs, segue o modelo de decomposição

por sub-domínio, ou seja, é criado uma API onde esta é responsável por cada sub-

domínio do seu negócio.




9

Exemplo:

A camada de backend segue a abordagem de desenvolvimento de software

denominada Domain-Driven Design (DDD) que tem como premissa a comunicação

por meio de linguagem ubíqua o isolamento da lógica de domínio (DDD Community,

2018).

Nos casos em que há necessidade de registro histórico dos dados

manipulados na aplicação, de forma a restaurar o momento histórico de uma

determinada transação de negócio, devem ser utilizados os padrões Command Query

Responsibility Segregation (CQRS) (Microsoft, 2018) e Event Sourcing (ES) (Fowler,

2018).

Detalhes referente a estes conceitos podem ser verificados em:

http://alm.tjmt.jus.br/Desenvolvimento/DSA/_wiki?pagePath=%2FPADR%C3%95ES

%2FArquitetura%2FBackend

http://alm.tjmt.jus.br/Desenvolvimento/DSA/_wiki?pagePath=%2FPADR%C3%95ES%2FArquitetura%2FBackend

http://alm.tjmt.jus.br/Desenvolvimento/DSA/_wiki?pagePath=%2FPADR%C3%95ES%2FArquitetura%2FBackend


10

3.3.3.1 Qualidade

Existem alguns princípios básicos a serem seguidos para que um serviço

REST possua uma qualidade mínima. Uma das formas de se garantir a qualidade é

por meio do “Modelo de maturidade Richardson” (Fowler, Richardson Maturity Model,

2018).

Seguindo o Modelo de maturidade Richardson, foi instituído que o mínimo

aceitável para a criação de APIs REST é o nível 2. Não só isto, a forma com que a

nomenclatura de operações, recursos e demais itens devem estar condizentes com

as melhores práticas definidas em https://restfulapi.net/resource-naming/. Quanto ao

retorno nas operações da API, esta deve ser no formato JSON (JSON, 2018).

3.3.3.2 Documentação

Toda API criada, deve ter suas definições documentadas utilizando a

“OpenAPI Specification” (OpenAPI Specification, 2018). Também nesta

documentação devem estar contidas as informações necessárias para o consumo do

serviço, tais como autenticação e regras de negócio cabíveis.

3.3.4 TESTE

Assim como definido em “2.4 Testes”, o teste nas APIs (backend) seguem as

mesmas definições. Portanto, os testes unitários e de integração, continuam a ser

requisitos com os parâmetros já estabelecidos.

3.4 Integrações

Integração entre aplicações Micro serviços são realizadas por duas formas

principais: “chamadas entre APIs” e “Mensagem”.

3.4.1.1 Chamadas entre APIs

São as integrações diretas entre os serviços de forma síncrona. Quando

existe uma dependência de outro serviço inerente de sua regra de negócio.

Este modelo de integração nem sempre é recomendado visto que cria uma

dependência entre os serviços e deve ser utilizado somente em casos de leitura de

informação.

https://restfulapi.net/resource-naming/


11

3.4.1.2 Mensagem

A mensagem é utilizado seguindo um padrão de “Publish-Subscribe”

(PubSub, 2018). Neste formato, existe uma API que lança eventos em uma

infraestrutura de Message Broker (Message Broker, 2018) e os interessados que

queiram fazer alguma atividade se registram para receber essa notificação. Este

modelo é o preferido para a integração entre APIs, pois não cria

acoplamento/dependência entre os serviços.

A infraestrutura de mensagens implantada no TJMT é a RabbitMQ (RabbitMQ,

2018), a qual fornece múltiplas bibliotecas para diferentes linguagens, principalmente

as quais são utilizadas no desenvolvimento backend.

4 CICLO DE VIDA

Todo produto ou serviço desenvolvido deve possuir as etapas de Continuous

Integration e Continuous Delivery devidamente configuradas e devem seguir o fluxo

estabelecido na Figura 4. Tais configurações são de atribuição dos arquitetos de

software.

As etapas do ciclo de vida são:

1. Ambiente de Desenvolvimento

a. Ambiente restrito à equipe de desenvolvimento;

b. Execução de testes unitários a cada modificação.

2. Ambiente de Teste

a. Ambiente restrito à equipe de desenvolvimento;

b. Integra diferentes “branches” da equipe para uma nova release;

c. Execução de testes de integração e carga.

3. Ambiente de Homologação

a. Ambiente disponibilizado para análise pelo cliente;

b. Verificação preliminar do impacto da publicação em produção.

Aprovações: Analista de Teste, Controlador da Equipe e Gestão

Estratégica.


12

4. Ambiente de Produção

a. Ambiente onde a versão é disponibilizado ao cliente em

definitivo;

Aprovações: Gestão Estratégica.

Figura 4 - Fluxo de produção

4.1 Continuous Integration

Continuous Integration (Continuous Integration, 2018) é uma prática no

desenvolvimento de software com o objetivo de se garantir a qualidade de um código

produzido. Neste processo, múltiplos testes (principalmente unitário e de integração)

são executados e aferidos para que assim seja encaminhado para a próxima fase do

processo.

No Team Foundation Server (Infraestrutura), este processo é executado

mediante um processo de compilação (Build) para teste unitário e posteriormente no

ambiente beta para os testes de integração.


13

4.2 Continuous Delivery

Continuous Delivery (Continuous Delivery, 2018) é uma prática utilizada para

se obter uma maior velocidade de entrega. Uma necessidade cada vez mais solicitada

pelos clientes de TI.

No Team Foundation Server (Infraestrutura), este processo é executado

mediante a publicação (Release) da aplicação. Este processo é todo automatizado e

passa por etapas para então se entregue aos usuários em ambiente de produção.

5 REVISÃO

Este caderno de arquitetura possui revisão formal a cada 12 meses.


14

FIGURAS

Figura 1 - Fluxo de ambientes ..................................................................................... 3

Figura 2 - Ambientes de teste ..................................................................................... 4

Figura 3 - Fluxo de autenticação ................................................................................. 6

Figura 4 - Fluxo de produção .................................................................................... 12

TABELAS

Tabela 1 - Convenções entre ambientes e endereços ................................................ 2

Tabela 2 - Requisitos padrões de testes ..................................................................... 5

REFERÊNCIAS BIBLIOGRÁFICAS

.NET. (30 de 07 de 2018). Fonte: Microsoft: https://www.microsoft.com/net

Behavior-driven development. (30 de 07 de 2018). Fonte: Wikipedia:

https://en.wikipedia.org/wiki/Behavior-driven_development

Continuous Delivery. (30 de 07 de 2018). Fonte: Continuous Delivery:

https://continuousdelivery.com/

Continuous Integration. (30 de 07 de 2018). Fonte: GAEA:

https://gaea.com.br/entenda-o-que-e-continuous-integration/

Cucumber. (30 de 07 de 2018). Fonte: Wikipedia: https://cucumber.io/

DDD – Introdução a Domain Driven Design. (30 de 07 de 2018). Fonte: AgileAndArt:

http://www.agileandart.com/2010/07/16/ddd-introducao-a-domain-driven-

design/

DDD Community. (23 de 03 de 2018). What is Domain-Driven Design. Fonte: DDD

Community: http://dddcommunity.org/learning-ddd/what_is_ddd/

Fowler, M. (23 de 3 de 2018). Event Sourcing. Fonte: Martin Fowler:

https://martinfowler.com/eaaDev/EventSourcing.html

Fowler, M. (30 de 07 de 2018). Richardson Maturity Model. Fonte: Martin Fowler:

https://martinfowler.com/articles/richardsonMaturityModel.html


15

Guru99. (30 de 07 de 2018). End-To-End Testing. Fonte: Guru99:

https://www.guru99.com/end-to-end-testing.html

JAVA. (30 de 07 de 2018). Fonte: JAVA: https://java.com

JSON. (30 de 07 de 2018). Fonte: JSON: https://www.json.org/json-pt.html

Message Broker. (30 de 07 de 2018). Fonte: Wikipedia:

https://en.wikipedia.org/wiki/Message_broker

Microservice Architecture. (30 de 07 de 2018). Fonte: Microservice Architecture:

http://microservices.io/patterns/microservices.html

Microsoft. (23 de 03 de 2018). CQRS Journey. Fonte: Microsoft Developer Network:

https://msdn.microsoft.com/en-us/library/jj554200.aspx

Modelo de Objeto de Documento - DOM. (30 de 07 de 2018). Fonte: Mozilla:

https://developer.mozilla.org/pt-BR/docs/DOM/Referencia_do_DOM

OpenAPI Specification. (30 de 07 de 2018). Fonte: Swagger:

https://swagger.io/specification/

PubSub. (30 de 07 de 2018). Fonte: Wikipedia:

https://en.wikipedia.org/wiki/Publish%E2%80%93subscribe_pattern

RabbitMQ. (30 de 07 de 2018). Fonte: RabbitMQ: https://www.rabbitmq.com/

REST. (30 de 07 de 2018). Fonte: Wikipedia: https://pt.wikipedia.org/wiki/REST

REST. (30 de 07 de 2018). Fonte: Wikipedia: https://pt.wikipedia.org/wiki/REST

SOAP. (30 de 07 de 2018). Fonte: Wikipedia: https://pt.wikipedia.org/wiki/SOAP

Team Foundation Server. (30 de 07 de 2018). Fonte: Microsoft:

https://visualstudio.microsoft.com/pt-br/tfs

Vincent Driessen . (30 de 07 de 2018). Git branching model. Fonte: Vincent Driessen

Blog: https://nvie.com/posts/a-successful-git-branching-model/

Web service. (30 de 07 de 2018). Fonte: Wikipedia:

https://pt.wikipedia.org/wiki/Web_service


16

Wikipedia. (04 de 04 de 2018). Continuous Delivery. Fonte: https://en.wikipedia.org/:

https://en.wikipedia.org/wiki/Continuous_delivery

Wikipedia. (30 de 07 de 2018). Docker. Fonte: Wikipedia:

https://pt.wikipedia.org/wiki/Docker_(software)

Wikipedia. (30 de 07 de 2018). Kubernetes. Fonte: Wikipedia:

https://pt.wikipedia.org/wiki/Kubernetes

Wikipedia. (30 de 07 de 2018). Single Sign On. Fonte: Wikipedia:

https://en.wikipedia.org/wiki/Single_sign-on

Wikipédia, C. d. (23 de 03 de 2018). Interface gráfica do utilizador, 51329793. Fonte:

Wikipédia: https://pt.wikipedia.org/wiki/Interface_gr%C3%A1fica_do_utilizador

Documents

CADERNO DE ARQUITETURA PODER JUDICIÁRIO DE ......Domain Driven Design, 2018), pois esta baseia-se muito em seus princípios. O caminho definido para a criação de APIs, segue o modelo