Domain-Driven Design: Refatorando a arquitetura de aplica��es

Artigo no estilo: Curso[rotulo-mentoring/] [lead-mentoring] A divis�o do projeto de software em camadas � uma pr�tica que vem sendo utilizada h� v�rios anos e, em boa parte dos casos, atende �s necessidades iniciais dos sistemas. No entanto, � medida que a aplicaç�o cresce, a utilizaç�o apenas das camadas DAL (Data Access Layer) e BLL (Business Logic Layer) acaba por n�o suportar adequadamente a expans�o das funcionalidades, levando � sobrecarga de responsabilidades em alguns componentes. O Domain-Driven Design, apesar de ter sido proposto h� mais de uma d�cada, vem ganhando bastante atenç�o da comunidade t�cnica nos �ltimos anos e sendo usado tanto em novos projetos, quanto na refatoraç�o de aplicaç�es legadas. A sua utilizaç�o, juntamente com a correta aplicaç�o dos principais conceitos de orientaç�o a objeto e padr�es de projeto, garante � aplicaç�o uma arquitetura com baixo acoplamento e adequada divis�o de responsabilidades entre os componentes. [/lead-mentoring]

Muitas vezes, por partirem de um conjunto de requisitos pequeno e sofrerem a comum press�o por entregas r�pidas em prazos curtos, os desenvolvedores constroem seus sistemas com pouco ou nenhum projeto. Geralmente s�o utilizadas soluç�es de arquitetura e tecnologia simples que apenas atendem �s necessidades daquele momento. Por�m, naturalmente esses sistemas crescem e novas funcionalidades precisam ser implantadas, enquanto o tempo para atender �s novas solicitaç�es dos clientes continua resumido. Apesar de consciente da necessidade de refatoraç�o no projeto, a equipe (principalmente quando � pequena e com pouca experi�ncia) acaba por postergar essa tarefa, em alguns casos, at� que ela seja imprescind�vel para a continuaç�o da vida do software.

Aplicaç�es legadas, constru�das com tecnologias e arquiteturas pouco flex�veis, tendem a representar dificuldades para a equipe de desenvolvimento quando grandes manutenç�es s�o necess�rias. Em certos casos � importante que a arquitetura da aplicaç�o seja refatorada, bem como as tecnologias utilizadas sejam alteradas ou atualizadas para atender a novos requisitos do neg�cio.

Neste artigo veremos como realizar o refactoring completo de uma aplicaç�o desenvolvida com a estrutura em tr�s camadas mais comum em projetos .NET para uma arquitetura mais escal�vel atrav�s do DDD (Domain-Driven Design). Posteriormente o leitor poder� utilizar essa soluç�o como template para migrar seus projetos para o DDD, inclusive visando outras arquiteturas evolutivas como microservices, e disponibilizar seus m�dulos em forma de serviços consum�veis.

Como cen�rio temos uma aplicaç�o web de gerenciamento de tarefas desenvolvida com ASP.NET Web Forms, Entity Framework Code First e as seguintes camadas:

DAL (Data Access Layer), que cont�m as entidades e a persist�ncia, com acesso direto � base de dados;
BLL (Business Logic Layer), a camada de neg�cios na qual colocamos todos os requisitos (regras de neg�cio) do sistema esperados pelos usu�rios;
Camada de apresentaç�o contendo o ASP.NET Web Forms. Nessa parte, no entanto, foi utilizado o Bootstrap para a construç�o de uma interface de usu�rio agrad�vel e responsiva, o que far� com que a maior parte do nosso trabalho seja direcionada �s camadas inferiores.

Utilizaremos ainda o Entity Framework Fluent API, padr�es SOLID, DRY, mantendo assim algumas das melhores pr�ticas de programaç�o. J� na camada de apresentaç�o vamos utilizar o ASP.NET MVC 5 com AngularJS, tudo alinhado ao que prega o DDD, com foco no dom�nio da aplicaç�o.

Sistema legado: Diagrama e camadas

O sistema de gerenciamento de tarefas � legado e foi desenvolvido atrav�s de um projeto de refactoring de uma aplicaç�o desktop diretamente para a web. O sistema estava funcionando perfeitamente e de forma est�vel at� que os clientes começaram a solicitar alteraç�es pertinentes, mas a arquitetura que havia n�o comportava tamanha evoluç�o. Na Figura 1 temos o diagrama arquitet�nico da aplicaç�o.

Essa figura demonstra bem como ficam distribu�das as camadas no projeto e como � o fluxo de depend�ncias entre estas. Nossa tarefa � refatorar para uma nova arquitetura, mais escal�vel e moderna.

Figura 1. Diagrama arquitet�nico do sistema legado

Fazendo um levantamento de como o sistema poderia ser evolu�do, chegamos ao que vemos na Figura 2, um diagrama comparativo de como ficar� o sistema e como redistribuiremos as regras de neg�cios existentes.

Figura 2. Diagramas de camadas conceituais

Nessa figura a diferença entre os modelos pode ser discreta e pode parecer que pouco ir� mudar na arquitetura. Por�m, ser� de grande valia para a manutenibilidade do sistema, pois a organizaç�o do projeto e do c�digo que o DDD nos sugere far� toda a diferença.

Soluç�o e ferramentas envolvidas

Para desenvolver o novo sistema utilizaremos o Visual Studio 2013, o .NET Framework 4.5, banco de dados SQL Server 2008 R2 Express, Entity Framework 6 (pacote EntityFramework), ASP.NET MVC 5 e o AngularJS 1.4.7 (pacote AngularJS). Esses �ltimos podem ser baixados via Nuget, bastando pesquisar pelos seus respectivos nomes e instalar os primeiros pacotes resultantes da busca.

Os c�digos fontes completos, tanto do sistema legado quanto do novo, est�o dispon�veis para download, separados por solution, para que o leitor possa acompanhar melhor o artigo. Para manter o artigo conciso mostraremos aqui apenas os pontos principais e apontaremos onde fica cada novo trecho comparado com o equivalente no sistema legado.

Modelagem da nova estrutura

� importante que saibamos de onde partiremos e onde chegaremos a partir de cada elemento do projeto atual, para isso, veremos nas pr�ximas seç�es o comparativo do c�digo do sistema legado com o novo que ser� criado. Inicialmente podemos ver no diagrama da Figura 3 em qual local da nova arquitetura ser�o realocadas as antigas camadas utilizadas na arquitetura antiga.

Figura 3. Organizaç�o do c�digo legado no novo projeto

Para facilitar e agilizar o processo de refatoraç�o, trabalharemos para reaproveitar boa parte do c�digo existente e reorganiz�-lo nas camadas do novo sistema, agora de forma aderente ao que sugere o DDD.

Camada DAL: Entidades

No projeto original as entidades eram dispostas na camada DAL e estavam mapeadas atrav�s de anotaç�es do Entity Framework Code First nas classes e propriedades, como vemos na Listagem 1. No novo projeto, as entidades ficam na camada de Dom�nio, porç�o central do projeto que segue o Doman Driven Design.

Listagem 1. Entidades no projeto legado


  01 [Table("TB_USUARIO")]
  02 public class Usuario
  03 {
  04     [Key]
  05     [Column("cod_usuario")]
  06     [DatabaseGenerated(DatabaseGeneratedOption.Identity)]
  07     public virtual int Id { get; set; }
  08 
  09     [Column("nomecompleto")]
  10     [MaxLength(100)]
  11     [Required(AllowEmptyStrings = true, ErrorMessage = "� necess�rio que se entre com o nome completo.")]
  12     public virtual String NomeCompleto { get; set; }
  13      
  14      //...demais propriedades
  15 }
  16 
  17 [Table("TB_TAREFA")]
  18 public class Tarefa
  19 {
  20     [Key]
  21     [Column("cod_tarefa")]
  22     [DatabaseGenerated(DatabaseGeneratedOption.Identity)]
  23     public virtual int Id { get; set; }
  24 
  25     [Column("nome")]
  26     [Required(AllowEmptyStrings = false, ErrorMessage = "� necess�rio que a tarefa tenha um nome.")]
  27     [MinLength(6, ErrorMessage = "Minimo de 6 caracteres para o nome.")]
  28     [MaxLength(100, ErrorMessage = "Maximo de 100 caracteres para o nome.")]
  29     public virtual String Nome { get; set; }
  30 
  31     [Column("dataEntrega")]
  32     [Required(AllowEmptyStrings = false, ErrorMessage = "� necess�rio que a tarefa contenha uma data de entrega.")]
  33     public virtual DateTime DataDeEntrega { get; set; }
  34
  35     //...demais propriedades
  36 }

Para simplificar a listagem omitimos algumas propriedades das duas entidades, mas � poss�vel observar que temos as classes e propriedades decoradas com atributes, alguns contendo regras de validaç�o. No novo projeto as regras de validaç�o ficar�o na camada de apresentaç�o, dentro da pasta Models do projeto ASP.NET MVC, enquanto que os atributes referentes � configuraç�o do Entity Framework ser�o colocados na camada de infraestrutura.

Na Listagem 2 vemos como essas mesmas entidades estar�o na nova soluç�o, mais limpas e respeitando o princ�pio da responsabilidade �nica. Al�m disso, elas agora ser�o tamb�m Persistent Ignorants, ou seja, desconhecem detalhes inerentes � persist�ncia das informaç�es no banco de dados. Dessa forma, essas classes n�o dependem do mecanismo de acesso ao banco de dados, estando livres para serem persistidas e recuperadas por qualquer framework/biblioteca. Desta forma, a escolha por qual utilizar (ADO.NET, Entity Framework, NHibernate) n�o interferir� naquilo que tem maior valor no DDD: o dom�nio da aplicaç�o.

Listagem 2. Entidades refatoradas


  01 [Serializable]
  02 public class Tarefa
  03 {
  04     private Nullable<long> id;
  05     private string nome;
  06     private Nullable<DateTime> dataDaEntrega;
  07     private string descricao;
  08     private EstadoTarefa estado;
  09     private Nullable<long> idUsuario;
  10     private Usuario usuario;
  11 
  12     //...propriedades e m�todos sobrescritos
  13 }
  14 
  15 [Serializable]
  16 public class Usuario
  17 {
  18     private Nullable<long> id;
  29     private string nomeCompleto;
  20     private string login;
  21     private string senha;
  22     private Status status;
  23     private ICollection<Tarefa> tarefas;
  24 
  25     //...propriedades e m�todos sobrescritos
  26 }

Na Figura 4 vemos a posiç�o das entidades dentro da camada de dom�nio do novo sistema, que foi constru�da como uma biblioteca de classes, apta a ser reaproveitada em outros projetos.

Figura 4. Entidades na camada de dom�nio na nova arquitetura

A configuraç�o das entidades para o acesso do Entity Framework, por sua vez, foi colocada na camada de infraestrutura (tamb�m uma Class Library), em uma pasta espec�fica para o ORM. A Figura 5 mostra como ficar�, ao fim, essa camada.

Figura 5. Camada de infraestrutura

O mapeamento com a Fluent API utiliza convenç�es de nomenclatura e m�todos que a partir de express�es lambda podem definir diversas caracter�sticas da entidade quando ela for persistida no banco de dados. Entre essas propriedades est�o o nome da coluna (HasColumnName), comprimento (HasMaxLength) e obrigatoriedade do preenchimento (IsRequired). As classes respons�veis por realizar esse mapeamento podem ser vistas na Listagem 3.

Listagem 3. Configuraç�o


  01 public class UsuarioMapeamento : EntityTypeConfiguration<Usuario>
  02 {
  03     public UsuarioMapeamento()
  04     {
  05         ToTable("TB_USUARIO");
  06 
  07         HasKey(u => u.Id);
  08 
  09         Property(u => u.Id).HasColumnName("cod_usuario");
  10         Property(u => u.Login).HasColumnName("login").HasMaxLength(20).IsRequired();
  11         Property(u => u.NomeCompleto).HasColumnName("nomecompleto").HasMaxLength(100).IsRequired();
  12         Property(u => u.Senha).HasColumnName("senha").HasMaxLength(500).IsRequired();
  13         Property(u => u.Status).HasColumnName("estado");            
  14 
  15     }
  16 }
  17
  18 public class TarefaMapeamento : EntityTypeConfiguration<Tarefa>
  19 {
  20     public TarefaMapeamento()
  21     {
  22         ToTable("TB_TAREFA");
  23 
  24         HasKey(t => t.Id);
  25         Property(t => t.Id).HasDatabaseGeneratedOption(DatabaseGeneratedOption.Identity).HasColumnName("cod_tarefa");
  26         Property(u => u.IdUsuario).HasColumnName("cod_usuario");
  27         Property(t => t.Nome).HasColumnName("nome").HasMaxLength(100).IsRequired();
  28         Property(t => t.DataDaEntrega).HasColumnName("dataentrega").IsRequired();
  29         Property(t => t.Descricao).HasColumnName("descricao").HasMaxLength(100);
  30         Property(t => t.Estado).HasColumnName("estado");
  31 
  32         HasRequired(t => t.Usuario).WithMany(u => u.Tarefas).HasForeignKey(t => t.IdUsuario);
  33     }
  34 }

A migraç�o das entidades apenas n�o possui grande complexidade, a parte que requer maior trabalho s�o as classes de persist�ncia, pois se comparado ao projeto original, essa tarefa ser� fragmentada na nova soluç�o para garantir a flexibilidade do projeto.

Camada DAL: Persist�ncia

Nessa camada mudaremos o paradigma que fora implementado at� ent�o, devido ao objeto de acesso a dados funcionar de maneira diferente de um objeto de infraestrutura. Ent�o veremos inicialmente como est� organizada a classe DAO (Data Access Object) de tarefas (Listagem 4) e como seu equivalente foi implementado na nova arquitetura. O mesmo � v�lido para os usu�rios, que segue a mesma l�gica e sintaxe e, portanto, ser� omitido aqui para fins de simplificaç�o do artigo.

Listagem 4. Classe TarefaDao


  01 public class TarefaDao : IDisposable
  02 {
  03     private ConexaoDeDados conexao;
  04 
  05     public void Criar(Tarefa tarefa)
  06     {
  07         try
  08         {
  09             using (ConexaoDeDados conexao = new ConexaoDeDados())
  10            {
  11                 conexao.TbTarefa.Add(tarefa);
  12                 conexao.SaveChanges();
  13             }
  14         }
  15         catch { throw; }
  16     }
  17 
  18     public void Editar(Tarefa tarefa)
  19     {
  20         try
  21         {
  22             using (ConexaoDeDados conexao = new ConexaoDeDados())
  23             {
  24                 conexao.Entry(tarefa).State = EntityState.Modified;
  25                 conexao.SaveChanges();
  26             }
  27         }
  28         catch { throw; }
  29     }
  30 
  31     public void Excluir(int id)
  32     {
  33         try
  34         {
  35             using (ConexaoDeDados conexao = new ConexaoDeDados())
  36             {
  37                 Tarefa tarefa = new Tarefa();
  38                 tarefa.Id = id;
  39                 conexao.TbTarefa.Remove(tarefa);
  40                 conexao.SaveChanges();
  41             }
  42         }
  43         catch { throw; }
  44     }
  45 
  46     public Tarefa BuscarPorId(int id)
  47     {
  48         try
  49         {
  50             using (ConexaoDeDados conexao = new ConexaoDeDados())
  51             {
  52                 var tarefaPorId = (from t in conexao.TbTarefa.AsNoTracking()
  53                                    where t.Id == id
  54                                    select t).FirstOrDefault<Tarefa>();
  55                 if (tarefaPorId != null && tarefaPorId.Id > 0)
  56                     return tarefaPorId;
  57                 else
  58                     return null;
  59             }
  60         }
  61         catch { throw; }
  62     }
  63 
  64     public ICollection<Tarefa> BuscarTodos()
  65     {
  66         try
  67         {
  68             using (conexao = new ConexaoDeDados())
  69             {
  70                 var tarefas = conexao.TbTarefa.AsNoTracking().ToList();
  71                 if (tarefas != null && tarefas.Count > 0)
  72                     return tarefas;
  73                 else
  74                     return null;
  75             }
  76         }
  77         catch { throw; }
  78     }
  79 }

No sistema legado essa classe � respons�vel por lidar com uma entidade para persisti-la e recuper�-la da base de dados, o que � bastante pr�tico e adequado � arquitetura atual da aplicaç�o. No entanto, isso n�o se aplica ao DDD, onde a persist�ncia tem uma import�ncia secund�ria e � feita atrav�s de contratos entre a camada de dom�nio e a camada de infraestrutura. Nesta segunda � onde s�o codificadas as operaç�es de inserç�o, exclus�o, alteraç�o e busca propriamente ditas." [...] continue lendo...

Domain-Driven Design: Refatorando a arquitetura de aplica��es

Neste artigo veremos como refatorar uma aplicação completa desenvolvida com as camadas DAL e BLL, alterando sua arquitetura de acordo com o Domain-Driven Design, entendendo como e onde realocar cada componente do projeto legado na nova solução.

Artigos relacionados