none
Arquitetura para um ERP RRS feed

  • Pergunta

  • Olá pessoal,

    Gostaria de opiniões sobre arquitetura de software para uma aplicação robusta como um ERP. Estive estudando sobre a arquitetura DDD, e, apesar de entender o porque é recomendada e de saber que vou construir uma aplicação robusta, ainda sim gostaria de uma arquitetura um pouco mais simples. Também estive lendo sobre repositórios e em muitos lugares não se recomendam a utilização, como por exemplo:

    http://stackoverflow.com/questions/14110890/not-using-repository-pattern-use-the-orm-as-is-ef

    http://codetunnel.io/should-you-return-iqueryablet-from-your-repositories/

    Gostaria de uma abordagem simples mas que ao mesmo tempo separasse, no mínimo, a camada de business e que não me causasse muitos problemas ao dar manutenção. Outro requisito técnico é que o sistema faça testes unitários.

    Além disso o back end deve ser totalmente desacoplado do front end, e para isso estou pensando em utilizar AngularJS + Web.api

    Acredito que com o Angular e web api eu iria ganhar em performance, melhoraria a experiência do usuário com uma aplicação single page e ainda conseguiria organizar bem a camada de apresentação.

    O que acham?

    Obrigado desde já.


    domingo, 1 de novembro de 2015 01:40

Respostas

  • Então .NET Developer iniciante (Não sei seu nome, hehe!)

    Vamos partir do princípio que não existe receita de bolo ou bala de prata para fazer um software, certo? Por exemplo, o modelo que o Gilson trabalha, não dá pra dizer que está correto ou errado, no contexto que ele trabalha parece ser o melhor cenário, em outro contexto pode ser um exagero de arquitetura por exemplo. 

    Na minha visão, se você pensa em performance e logo foi comentando sobre o AngularJS por exemplo, acho que é uma preocupação um tanto prematura, antes de chegar "lá em cima", no seu front-end, que por sua vez, se não for bem feito pode sim causar problemas de performance, existe um oceano de camadas e arquitetura para se preocupar. 

    Por exemplo, se você pensa em escalar sua aplicação, ou seja, disponibilizar para "n" clients como um mobile, uma web app, um sistema web, até mesmo um desktop e por que não, aplicações em Java e C++, por exemplo, quanto mais você segregar cada camada gerando o menor acoplamento possível, melhor será para gerenciar suas regras de negócio e junto obter o melhor de performance. 

    Em seu lugar, estudaria DDD, ou pelo menos a base do DDD, acredito que seja um bom caminho nesse cenário que você descreveu.


    terça-feira, 3 de novembro de 2015 03:18

Todas as Respostas

  • Boa noite...

    Uma aplicação moderna, complexa como um ERP e com arquitetura robusta usando DDD...assista essa vídeo aula do Eduardo Pires...vai ajudar você a dar os primeiros passos com DDD e ASP.NET.

    http://eduardopires.net.br/2014/10/tutorial-asp-net-mvc-5-ddd-ef-automapper-ioc-dicas-e-truques/ 

    Espero ter ajudado!


    domingo, 1 de novembro de 2015 04:32
  • Olá Diego,

    Eu assisti esse vídeo... Porém, minha opinião, é que apesar de entender que deve haver uma padronização e uma certa divisão de responsabilidades ainda achei um exagero na quantidade de passos a se tomar para se retornar um objeto qualquer por exemplo. Andei pesquisando na internet e também vi que outras pessoas criticam por exemplo o modelo de repositórios, que é algo tão usado na arquitetura DDD. Teoricamente o DbContext já gerencia transações e também li que há problemas em retornar objetos de maneira assíncrona utilizando repositórios(não entendi muito bem o porquê)... 

    Exemplos do que eu li sobre repositórios e injeção de dependências, e por enquanto concordo:

    Unnecessary Abstraction

    Do you want to create repository just so that in future you can easily replace EF with NHbibernate etc or anything else? Sounds great plan, but is it really cost effective?

    Dependency Injection, IoC

    Wow these are great words, sure they look great in theory, but sometimes you have to choose trade off between great design and great solution. We did use all of that, and we ended up throwing all at trash and choosing different approach. Size vs Speed (Size of code and Speed of development) matters huge in real life. Users need flexibility, they don't care if your code is great in design in terms of DI or IoC.

    Estou pesquisando e gostaria de conhecer outros modelos e opiniões além do modelo DDD. Ou acham que estou errado?

    domingo, 1 de novembro de 2015 14:19
  • Hoje tenho na empresa, um ERP dividido em camadas e não enfrento problemas com manutenção, toda a parte da infra (regra de negócio, banco de dados e demais manipulações do banco de dados) ficam em webservices que são responsáveis por distribuir para diferentes clientes (Web Aplications, Mobile, Windows Forms). Com isso, consigo dar manutenção nas regras de negócio sem ter que republicar a distribuição toda.

    Um exemplo disso, foi a troca de banco de dados, quando fiz a alteração, foi apenas do lado do webservice, o cliente nem sequer soube da troca, continuou trabalhando normalmente após a migração do banco.

    Tive "N" situações que poderiam justificar essa separação.

    Já trabalhei com "Repositórios virtualizados", hoje estou voltando para o banco de dados e melhorando os SQLS para evitar dor de cabeça em função do volume de acesso e volume de dados.

    Utilizo (Entity Framework 6 e WCF) do lado WebService e do lado cliente é bem váriado, (Mobile, asp.Net, asp.Net MVC, Windows Forms, WPF, Delphi, xHarbour, dentre outras tecnologias).

    No cliente MVC, utilizo Bootstrap com AngularJS


    Gilson Joanelo - Desenvolvedor Web


    • Editado Gilson Joanelo domingo, 1 de novembro de 2015 16:51 Citação do AngularJS
    domingo, 1 de novembro de 2015 16:50
  • Olá Gilson,

    Obrigado pela resposta, com certeza vou separar a camada de apresentação e toda parte do servidor será um asp.net web api. A parte da web, inclusive, estou pensando em fazer apenas javascript.

    Porém, minha maior dúvida é quanto a arquitetura na parte do back end. Está bem claro para mim que devo separar a camada de negócios já que é um sistema que tem muita regra de negócio. Mas quando penso nisso, inevitavelmente penso na arquitetura "bolovo" que é tão criticada por aí. Ao mesmo tempo quando leio sobre a arquitetura DDD considero uma arquitetura complexa demais para a velocidade que quero realizar mudanças. 

    Estou buscando algo que seja simples e organizado.

    domingo, 1 de novembro de 2015 17:39
  • Então .NET Developer iniciante (Não sei seu nome, hehe!)

    Vamos partir do princípio que não existe receita de bolo ou bala de prata para fazer um software, certo? Por exemplo, o modelo que o Gilson trabalha, não dá pra dizer que está correto ou errado, no contexto que ele trabalha parece ser o melhor cenário, em outro contexto pode ser um exagero de arquitetura por exemplo. 

    Na minha visão, se você pensa em performance e logo foi comentando sobre o AngularJS por exemplo, acho que é uma preocupação um tanto prematura, antes de chegar "lá em cima", no seu front-end, que por sua vez, se não for bem feito pode sim causar problemas de performance, existe um oceano de camadas e arquitetura para se preocupar. 

    Por exemplo, se você pensa em escalar sua aplicação, ou seja, disponibilizar para "n" clients como um mobile, uma web app, um sistema web, até mesmo um desktop e por que não, aplicações em Java e C++, por exemplo, quanto mais você segregar cada camada gerando o menor acoplamento possível, melhor será para gerenciar suas regras de negócio e junto obter o melhor de performance. 

    Em seu lugar, estudaria DDD, ou pelo menos a base do DDD, acredito que seja um bom caminho nesse cenário que você descreveu.


    terça-feira, 3 de novembro de 2015 03:18