Arquitetura das Aplicações

A arquitetura das aplicações nativas Elevation é complexa. Os tópicos seguintes descrevem essa arquitetura sob as suas perspetivas mais importantes e descrevem ainda a parte fundamental dos componentes runtime da plataforma que farão parte dessas aplicações.

Tecnologia

A arquitetura base de uma aplicação Elevation é client/server, thin client com um application server, o Web server que executa o Web site da aplicação. Esse Web site é alojado no Microsoft Azure.

Utilizam-se tecnologias Web de última geração como o Angular JS para controlar os componentes de cliente, que executam em qualquer browser e em qualquer dispositivo (porque a tecnologia de apresentação é HTML5).

As views da aplicação são ASP.NET MVC.

Existem duas camadas de serviços, uma interna, usada pela aplicação, própria da sua lógica de interação, e uma pública, via Web API para integração de sistemas externos.

A lógica de negócio principal é implementada pelos business managers.

A camada de dados é gerida pela Entity Framework com um reposítório SQL Azure.

Modularidade

Uma aplicação Elevation é basicamente um Web site (o host) que agrega todas as suas funcionalidades numa “Shell”.

A aplicação é composta por um conjunto de módulos, uns disponibilizados pela plataforma, com funcionalidades transversais a todos os produtos, e outros de negócio. Um módulo pode fazer parte de várias aplicações (produtos).

Os módulos “falam” entre si através de uma API interna e disponibilizam uma API externa (a Web API) para que outros sistemas externos possam interagir com eles.

A composição de módulos é gerida por um sistema de licenciamento e por permissões orientadas ao perfil (role do utilizador). A face visível dessa composição é o menu da aplicação.

A aplicação é multi-tenant, por isso permite hospedar tantos clientes quantos necessários na mesma infraestrutura.

A modularidade é um aspeto crucial das aplicações porque permite a agregação de funcionalidades e o seu desenvolvimento autónomo. É um conceito inerente à Plataforma Elevation.

Por exemplo, no Jasmin, os módulos são os seguintes:

Um módulo só pode referenciar serviços através da API interna de módulos abaixo ou ao mesmo nível no diagrama.

Módulos de Plataforma

A Plataforma Elevation disponibiliza de base os seguintes módulos que são utilizados por todas as aplicações:

Core Patterns

Implementa um conjunto de padrões de negócio transversais a todas as aplicações, para além de vários componentes runtime de negócio (exemplos: audit, schema, etc.).

Identity

Descreve as entidades de gestão de utilizadores e permissões e os componentes cliente do Identity Server, a solução de single sign-on da Plataforma.

Operations

Implementa padrões de negócio de índole mais operacional (notificações, audit, etc.), transversais, e os respetivos componentes runtime.

QueryBuilder

Disponibiliza componentes de gestão e apresentação de listas das entidades da aplicação.

Reporting

Implementa os componentes de impressão de entidades e de documentos disponíveis para as aplicações.

Shell

Disponibiliza o runtime da shell - o ambiente de execução cliente da aplicação. Estes componentes asseguram os comportamentos de apresentação que serão idênticos entre todas as aplicações (o menu, a área de navegação, gestão das views, responsive design, etc.).

Arquitetura de um Módulo

O diagrama seguinte apresenta uma visão sumarizada da arquitetura de cada módulo da aplicação.

Um módulo divide-se em 2 layers físicos:

• Os componentes cliente (que executam no browser).
• Os componentes servidor (que executam no servidor Web).

Esses componentes estão divididos em 4 layers lógicos:

• Presentation – componentes que lidam com o UI da aplicação.
• Services – serviços aplicacionais públicos (API) e internos.
• Domain – componentes que implementam a lógica de negócio.
• Data – componentes que lidam com a persistência dos dados.

O cliente Elevation comunica com o servidor através de uma API interna JavaScript/REST que acede aos serviços do respetivo módulo.

Aplicações externas (de parceiros) comunicarão com o sistema através de uma Web API.

A integração entre módulos é realizada através de application services (uma espécie de versão da Web API com funcionalidades adaptadas à integração).

Layers Lógicos

Estes layers lógicos do módulo podem ser visualizados na seguinte perspetiva:

Api

Esta camada (Company.Module.Api.dll) define os contratos dos application services e os respetivos resources. Esta é a Integration API.

Esses application services são utilizados pelos módulos para comunicarem entre si. Ou seja, o módulo X apenas pode referencias esta livraria do módulo Y e utilizar esses application services e resources para transferir dados.

Domain Entities

Esta livraria (Company.Module.Domain.Entities.dll) define as entidades de negócio (business entities), declaradas como POCO, que são utilizadas pelas camadas Domain e Data para fazer a persistência dos dados.

Entity Context

Este componente (em Company.MOdule.Data.dll) - existe apenas um por módulo - é responsável pela persistência dos dados na base de dados. Utiliza a Entity Framework como ORM.

Business Managers

Os business managers (ou apenas managers) (em Company.Module.Domain.dll) são os componentes que implementam a lógica de negócio principal do módulo. São tipicamente invocados pelos services managers e delegam as operações de acesso a dados no Entity Context.

Services Managers

Estes componentes (em Company.Module.Domain.dll) fazem a adaptação dos serviços para a camada de negócio (os business managers). Tipicamente disponibilizam operações sobre os resources e fazem o seu mapeamento para domain entities que o business manager processa depois.

Services Controllers

Os services controllers (em Company.Module.Services.Controllers.dll) definem a camada de serviços do módulo. São classes que representam a API do módulo, divida em duas:

• Application API é a API usada pela própria aplicação, a partir da shell. Corresponde aos service controllers APP.
• Public API é a API pública do módulo (Web API). Corresponde aos serviços API.

A diferença mais substancial entre as duas API está relacionada com os drafts, disponíveis apenas a partir da primeira.

CoreLib

O runtime da Plataforma, para além dos módulos de plataforma, já referidos, é publicado por dois grandes grupos de componentes: a CoreLib e a Core.

A CoreLib é um conjunto de livrarias com funcionalidades transversais muito genéricas, utilizadas pela Plataforma e pelas aplicações Elevation mas que tem duas particularidades:

• Tem um roadmap autónomo, independente da evolução da plataforma (tipicamente mais estável).
• Pode ser utilizada em qualquer aplicação, mesmo que não utilize nenhum outro componente da Plataforma Elevation.

As funcionalidades disponibilizadas por esta livaria vão desde coisas muito simples como a validação de argumentos de métodos até componentes mais complexos de tracing, storage, telemetria, etc.

Componentes Core

Já os componentes Core são específicos da Plataforma Elevation e estão desenhados para trabalharem em conjunto com os restantes módulos da Plataforma e da aplicação.

Tipicamente, fornecem funcionalidades e comportamentos transversais a todos os módulos e caracter mais básico (como, por exemplo, o arranque da aplicação ou a gestão de application services, assim como modelos de dados usados por componentes implementados nos módulos da Plataforma).

O diagrama seguinte ilustra a organização lógica dos componentes Core:

Identity Server

O Identity Server é a peça da plataforma responsável pela identidade e autorização dos utilizadores e o single sign-on.