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?
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.
Tags architecture rest mvc