Considerações para desacoplar e refatorar a lógica de negócios para uma API REST

5

Temos uma solução .NET que consiste em um site do MVC e várias bibliotecas para lógica de negócios e dados. No passado, o site era a única maneira de interagir com nossa lógica de negócios, mas estamos descobrindo que precisamos compartilhar essa lógica entre vários sistemas e decidimos expor isso por meio de uma API REST.

O fluxo típico de informações entre a arquitetura atual é:

UI -> Model (Controller) -> Model (Business Logic) -> Entity (Data Logic) -> DB

Se eu fosse mover a biblioteca de lógica de negócios para uma API REST, obviamente eu precisaria reformar o site do MVC para consumi-la, para continuarmos os negócios normalmente.

Devo deixar as assinaturas de método existentes na lógica de negócios como estão, com os objetos de modelo como parâmetros, ou devo considerar a refatoração disso?

public List<ClaimSearchEntity> Search(ClaimSearchRequest request)

Aqui está algo para dar uma ideia das dependências entre as camadas:

MVC.App                   -> Application.Logic

Application.Logic         -> Application.BusinessLogic

Application.BusinessLogic -> Application.Data
                          -> Application.Models

Application.Data          -> Application.DataLogic
                          -> Application.Entities
                          -> Application.Mappings

Outra coisa que achei que poderia ser útil nesse sentido é a devolução de metadados para as solicitações da API, expondo os campos do modelo como JSON. Algo como o JIRA faz.

Eu preciso encontrar um equilíbrio entre fazer o trabalho rapidamente e fazê-lo corretamente. Você tem alguma sugestão ou alternativa para minha abordagem?

    
por Daniel Minnaar 25.05.2016 / 09:52
fonte

1 resposta

3

Sua lógica de negócios deve permanecer intocada. A API Rest é uma exibição. A interface do usuário é uma exibição. No máximo, o controlador deve mudar para acomodar essa mudança. Em um design ideal, o controlador não teria conhecimento de nenhuma visão e não mudaria nada.

Em vez de mostrar o fluxo de informações, seria útil ver as direções das dependências desses componentes. Todos os nomes me dizem quais são as responsabilidades. Não como eles podem ser separados.

    
por 25.05.2016 / 11:16
fonte