Problemas com Repository e ORM

Em um post anterior eu evidenciei uma tendência de se encapsular frameworks em classes da própria aplicação. Dei uma atenção especial ao padrão Repository utilizado com ORM’s, e nesse post resolvi  destacar outros problemas que podem ocorrer com esse padrão.

Nem sempre é fácil identificar a responsabilidade

Quando estamos definindo os métodos do repositório os métodos básicos são fáceis de definir:

1. GetById;
2. Save (InsertOrUpdate);
3. Delete;
4. GetBy(Filter filters);

Vamos pegar um cenário onde você tenha um classe Customer e a classe Sale tendo cada uma delas a sua devida implementação do Repository.
Agora imagine um item do seu dashboard onde você exibe o total de vendas dos clientes:

Em qual repository você colocaria a implementação dessa consulta? Customer ou Sale?

Funcionalidades que requerem consultas e escritas no banco de dados que cruzam as fronteiras estabelecidas pelo padrão é algo muito comum. Quando surgem cenários desse tipo alguns utilizam estrategias que podem degradar a performance da aplicação como o Select N+1.

Dificuldade para resolver problemas de Performance

O Select N + 1 significa que você foi mais de uma vez no banco de dados para obter dados, no exemplo acima tivemos as seguintes requisições no banco de dados.

1. Obtém todos os clientes;
2. Quando acionada a propridade Sales de o sistema foi no banco para obter as respectivas vendas, ou seja, se tivermos 10 clientes o sistema irá 10 vezes no banco buscar as vendas de dos clientes;

Até aqui esses problemas reportados não é culpa do padrão + ORM mas só do padrão. Com os repositories nós não conseguimos customizar o retorno do banco de dados para necessidades especificas, até por que isso foge um pouco das responsabilidades do padrão.

Como uma solução pra esses tipos de problemas muitos preferem expor recursos do ORM pelo Repository, como exemplo:

• Enable/Disable Lazy Loading;
• Multi Queries;
• Operações em Batch;

O problema que isso se torna um “vazamento” da abstração que o Repository se propõe a fazer, se chegamos nesse ponto por que precisamos do padrão?

Organização e reaproveitamento de código

Alguns programadores ainda defendem a utilização do Repository por questões de organização e reaproveitamento de código e realmente processos de escrita e leituras duplicados não é legal. Pra resolver esses problemas já existem outros padrões bem interessantes pra ser utilizado (QueryObjects e CQRS).

Conclusão

Encapsular frameworks não é uma boa idéia, isso não significa que você não possa criar "facilitadores" para melhorar ou até mesmo contextualizar os frameworks para sua necessidade. Acredito que o ideal é sempre permitir que esses frameworks sejam utilizados diretamentes se necessário, assim todo o potencial dessas ferramentas sempre estará disponível.

Validando datas para envio ao banco de dados SQL Server

É muito comum achar validação de dados para envio ao banco de dados da seguinte forma:

O problema de validar desta forma é que o DateTime.MinValue retorna 00:00:00.0000000, January 1, 0001  enquanto a data minima aceita pelo SQL Server é 1/1/1753.

Para que a validação seja valida para o envio a um banco de dados SQL Server você pode fazer como abaixo:

Ícones Sprite, só usar!

Ícones sprite com o css prontinho, só chegar e usar!

https://github.com/eduardosilva/icons-silk-sprite
https://github.com/eduardosilva/icons-fugue-sprite
https://github.com/eduardosilva/icons-farm-fresh-sprite

Carregando dinamicamente as configurações do Entity Framework Code First

Abaixo um exemplo de como carregar as configurações customizadas de mapeamentos para o Entity Framework Code First.

Postmon - API para consultar CEP

O Postmon é uma api REST construída em Python e MongoDB para consulta de CEP e encomendas.
Nessa apresentação do InfoQ Alê Borba conta a história da criação da API.

Site da API: http://postmon.com.br/

Templates free para o Bootstrap

Pra quem ainda não conhece o Bootstrap, ele é um dos mais famosos frameworks de interface web.
Amplamente difundido entre designers e programadores, sua utilização tem sido cada vez mais utilizadas principalmente devido a recursos bem interessantes como recurso de layout reponsive.

Um dos sites mais famosos de vendas de layout, o ThemeForest tem em vários de seus produtos o Bootstrap como base. Mas pra quem não esta afim de gastar em torno U$30,00 (em média) para ter um layout pronto com o Bootstrap, você pode baixar layouts free (bem mais simples) no Start Bootstrap ele tem alguns templates prontos como:

• Shop Homepage: http://startbootstrap.com/shop-homepage;
• Admin: http://startbootstrap.com/sb-admin;
• Blog: http://startbootstrap.com/blog-home;
• E vários outros para Business: http://startbootstrap.com/home-page-templates

WCF com Log4Net

Galera,

Pra quem precisa utilizar o Log4Net com o WCF disponibilizei uma biblioteca bem simples de integração entre os dois:
http://eduardosilva.github.io/Trinity.Wcf.Log4Net/

Endereço do NuGet:
https://www.nuget.org/packages/TrinityWcfLog4Net/

ASP.Net MVC: Muito código nas Controllers

Eu tenho utilizado muito o ASP.Net MVC e sem dúvida é uma grande tecnologia, mas resolvi colocar nesse post alguns problemas que eu passei e como resolvi.

Com o ASP.Net Web Forms, por padrão, temos um code behind (*.aspx.cs) por página (*.aspx) isso significa que temos tem uma classe, que podemos de certa forma caracterizar como uma controller, responsável por uma View. Já no ASP.Net MVC podemos ter um Controller responsável por varias views. Ex.: ProdutoController  responsável pelas view Pesquisar, Detalhe, Edicao. Nesta mesma controller podemos potencializar a sua aplicação deixando-a responsável por responder chamadas de json.

Bom com isso acabamos tendo muito código nas nossas controllers (consultas, escritas, conversões de tipos etc). E isso não é culpa da tecnologia é apenas uma questão de como organizar as idéias e responsabilidades.

Com essa quantidade de código nas Controller fica dificil de dar manutenção, mesmo refatorando em métodos você acaba vendo um código muito extenso na sua controller o que de cara parece ser um mal sinal (ou um mal cheiro).

Não precisamos "reinventar a roda" para resolver esses problemas, grandes mentes já tem várias sugestões sobre isso e quero apenas apresentar algumas delas que eu estou utilizando e tem me agradado.

CQRS (Command Query Responsibility Segregation) é um padrão que tenho utilizado para organizar esse tipo de coisa, não vou entrar em detalhes sobre o padrão, isso vai ficar para outro post, vou focar apenas em como estou aplicando nos meus projetos.

Consultas

O primeiro problema que eu resolvi foi referente a consultas. Se você utiliza um OR/M como o Entity Framework ou NHibernate com o ASP.Net MVC você pode acabar tendo muito código de consulta dentro da sua controller.

OBS.: Eu não costumo encapsular os frameworks de OR/M com DAOs ou Repositories. Se estiver interessando no motivo leia o artigo abstração da abstração. Só pra reforçar que isso também não é coisa da minha cabeça, Ayende Rahien é um grande defensor da idéia de que abstrair OR/M é um erro.

Eu utilizo para as consultas o Query Object Pattern (link), com isso consigo encapsular as consultas nessas classes. Isso também evita a questão de trazer todas as propriedades das entidades relacionadas na consulta, eu consigo criar consultas espeficidas para fins específicos de uma View, o que traz um grande ganho de performance. (uma coleção de uma determinada entidade para popular um combobox pode te dar muito dor de cabeça. Acredite!).

Escritas

Para as escritas estou utilizando o Command Pattern, com ele eu consigo refatorar o processo de escrita em várias blocos de comando, afinal nem sempre nossas telas só precisamos executar um salvar correto? Como utilizo muito o Entity Framework, também fica fácil seperar esses comandos utilizando uma única instancia de context e controle de transação quando necessário.

Se você pesquisar sobre esse padrão verá outros padrões relacionados como o Tasks e Events, porém os meus projetos até o momento não precisou desse potencial todo.

Basicamente estou organizando os meus projetos da seguinte forma:

• Entities
• Commands
• QueryObjects
• Controllers
• Views
• Models

É claro que isso pode variar de projeto a projeto, mas no geral os projetos que tenho trabalhado esse tipo de organização tem atendido muito bem, sendo bastante produtivo mas sem perder a organização e flexibilidade do código.

Até a próxima!

Extensions Methods e Namespaces

Eu utilizo Extensions Methods para praticamente duas finalidades:

• Implementar uma funcionalidade não existente para um objeto;
• Dar uma maior coesão a um trecho de código;

Como exemplo de coesão, veja o trecho de código abaixo:

Para deixar o código um pouco mais coeso pode implementado da seguinte forma:

Para criar uma classe que implemente o código que queremos é muito simples:

Agora pra utiliza-lo basta fazer o seguinte:

Pois é, o Visual Studio já me avisou que não encontrou o meu método de extensão. Isso se dá por que esqueci de fazer o using para o namespace onde esta a extensão, e isso aconteceu por que o intellisense  não me deu essa opção.
Quando criamos um extension method dentro de uma namespace precisamos lembrar de fazer o using manualmente toda vez que queremos utiliza-lo, o que nem sempre é legal.

O que podemos fazer nesse caso?

Duas opções:

• Não definir uma namespace para a sua classe que contém os métodos de extensão;
• Definir o namespace igual ao objeto ao qual o método esta atrelado.

Fica ai a dica, agora é só mandar bala nos extensions methods.

O Inferno do Utils, Tools e afins!

Quando estamos pensando nas “camadas” da nossa solução, principalmente no começo do projeto, de uma forma geral temos grandes preocupações com assuntos como por exemplo coesão de responsabilidades, baixos acoplamentos, performance e segurança.
Se você esta em um projeto onde o pessoal diagrama tudo antes de começar a programar, se for criado uma classe diferente do que estava no diagrama os alarmes de incêndio são disparados.

De repente surge uma necessidade de enviar e-mail em mais de um ponto do sistema. Nós como “bons programadores”  que somos não vamos duplicar o código, então o que fazemos? Criamos um projeto chamado Utils (tools e seus primos).
Se precisamos encapsular uma transferência de arquivo via ftp agora não temos mais a “dor de cabeça” de decidir onde colocar esse tipo de funcionalidade, muito simples vai para o Utils.
Encapsulamento de leitura e gravação de um xml também não é mais problema, é só colocar no Utils que fica “tudo certo”.

Se pegarmos esse exemplo em particular fica claro que todos os cuidados que estávamos tomando na criação da solução foram totalmente ignorados quando passamos a ter o projeto Utils. E o pior é que fica tendencioso, se aparecer qualquer funcionalidade que não sabemos onde colocar, ela possivelmente irá parar no Utils.

Existem vários problemas com essa abordagem sendo alguns deles:

1. O projeto fica dependendo de vários Assemblies, das mais diversas finalidades: E-mail, FTP e acesso a banco são dependências claras no exemplo citado.
2. Se você tiver vários projetos que utiliza o seu Utils, cada alteração que você faça no seu Utils, recompila todos os projetos dependentes.
3. O projeto vira um “saco de lixo” de código. Lixo mesmo, por que é incrível como a grande maioria das vezes a qualidade do código cai em classes que são colocadas nesses projetos.

Precisa realmente encapsular o envio de e-mail? Precisa mesmo? Será que você não esta sendo motivado em fazer isso simplesmente para facilitar o envio de e-mail? Será que você não esta criando uma abstração da abstração?

Caso seja realmente necessário encapsular o envio de e-mail minha sugestão é que faça isso de verdade, crie uma projeto com essa funcionalidade com um nome sugestivo para o que ele se propõe a fazer. Assim fica claro o que assembly fará, inclusive podemos prever possíveis dependências que isso pode trazer na hora de utilizá-lo.

A Abstração da Abstração

Eu acho engraçado como somos condicionados a tentar encapsular tudo o que é externo a nossa aplicação em nossas próprias classes. Muitas vezes baixamos um framework para um determinado trabalho e o encapusalmos por inúmeros motivos, para tornar o código um pouco mais aderente com que a funcionalidade se propõe a fazer, para facilitar uma determinada operação do framework que estamos utilizando, e por ai vai.

O problema é que muitas vezes limitamos a utilização da ferramenta a aquilo que estamos diexando disponível nas nossas classes. O quanto isso vale a pena?

Vou pegar como exemplo os nossos Repositories, geralmente o utilizamos como uma abstração de acesso a dados, e deixamos disponíveis em nossos repositories os famosos métodos Save, GetById, GetAll, etc…
Bom, hoje em dia é muito comum utilizarmos um framework ORM para facilitar as implementações de banco de dados, mas perceba, o ORM é uma abstração de acesso a dados, claro, não igual ao Repository, porém não deixa de ser uma abstração de acesso.

Quando encapsulamos os métodos do ORM nos nossos repositories estamos perdendo poderosas features como por exemplo o Multiquery e e Future do NHbernate.
Não tenho a pretensão de classificar quando isso é bom ou ruim, mas cada caso precisa ser analisado com calma.

Fica ai a bandeira levantada.
Até a próxima.

Compilando para Silverlight

Essa dica eu ja mandei para o MUGSP mas resolvi deixar registrado aqui também.

Não sei se alguém algum dia vai precisar disso, mas se estiver tentando gerar um dll com código C# compilado “na mão” para Silverlight, tem que fazer o seguinte:

1. Todas as referencias devem ser feitas para as dlls compiladas para Silverlight (System.dll, mscorlib.dll e assim por diante). No meu caso faço referencias as dlls que estão na pasta  c:\Arquivos de programas\ReferenceAssemblies\Microsoft\Framework\Silverlight\v4.0\
2. Para o compilador (csc.exe) é necessário informar os argumentos /nostdlib+ /noconfig. Isso é necessário para que não seja gerado referencia para as bibliotecas padrões do .Net Framework.
3. No caso de utilizar o CodeDom (que foi o meu caso), é necessário passar esses argumentos para CompilerParameters:

new CompilerParameters
    {
        OutputAssembly = Path.Combine(outputDir, baseNamespace + ".Silverlight.dll"),
        CompilerOptions = @"/noconfig /nostdlib"
    };

Fica ai a dica pra quem precisar.

Até a próxima.

DDD: Melhorando a forma de carregar as Views utilizando Modelo Rico.

DDD sem dúvida é uma excelente ferramenta para auxiliar a resolver problemas que surgem em domínios complexos porém, como todo mundo diz, não é bala de prata. Mas o problema que eu vou expor aqui não é exclusivo de quem utiliza DDD e sim de qualquer solução que se utiliza de Modelo de Domínio Rico.

Quando você tem um Modelo de domínio rico as operações de escrita ficam mais coesas, as responsabilidades ficam mais claras além de outros benefícios, no entando, você pode ganhar alguns problemas nas operações de leitura.
Imagine uma tela onde você tenha três combobox, cada combobox populada com uma entidade diferente. Agora imagine essas entidades com um número significativo de propriedades (não vou definir aqui o quanto seria esse número, essa discussão não vem ao caso agora) e uma cadeia de relacionamento complexa (A relacionada com B que se relaciona com C e assim por diante). Como faríamos para popular esses combos da tela?

Certamente você utilizaria o repositorio especifico para cada uma das entidades e faria a consulta apropriada para popular os combos.

Você conseguiu identificar alguma problema nisso? Não? Então deixa eu ajudar.

Você percebeu quantas chamadas ao banco de dados você teve que fazer? Se você tiver utilizando alguma forma de serviço (WCF, WCF Data Services, ou qualquer outro tipo de serviço) você teve que chamar no mínimo três chamadas de serviço e cada chamada de serviço resultou em uma chamada de banco de dados.

Pronto, ta ai o pretesto que o seu companheiro de trabalho ou o seu gerente de projetos precisava para falar que DDD não presta! Mas esse tipo de problema também tem solução.

Primeira coisa: Pelo amor de Deus, use um ORM. Se você é daqueles programadores que ainda tem resistência a um ORM (como eu tinha) pare com isso agora antes que a coisa fique feia!
Com a utilização de ORM podemos utilizar recursos que nos ajudam na performance da aplicação como Lazy Loading, Cache, operações em Batch. O NHibernate tem funcionalidades excelentes para esses tipos de caso, por exemplo, com o Future poríamos popular os três combobox com uma única chamada para o banco de dados.

Segundo: Popule sua View somente com dados que ela precisa. Se para um combobox só precisamos de um Id e Descrição, pra que vamos trazer todos os dados da entidade? Novamente ferramentas como o NHibernate nos ajudam com esse tipo de situação.

De onde eu tirei essas soluções? CQRS.

Pretendo colocar algumas soluções práticas para esse tipo de situação, mas ja adianto as dicas apresentadas aqui é apenas uma das várias formas que temos para resolver esse problema. O importante é reconhecer que o problema esta lá e ter a mente aberta para as muitas formas de resolve-lo.

Até mais.

Silverlight: Dica de performance

Essa semana resolvi um problema interessante de uma aplicação feita em Silverlight.

Estava investigando por que uma determinada aplicação estava lenta e atacamos nas coisas mais óbvias: acesso a banco, chamadas de serviço, tamanho de objetos e por ai vai. Aparentemente não havia que justificasse a lentidadão da aplicação.

Resolvemos então verificar se não havia algum recurso que estavamos usando do silverlight para causar o problema. Procurando no Google por pessoas que passaram pelo mesmo problema, vimos várias dicas referentes ao uso de transparencia e os problemas que isso pode causar quando não utilizado com moderação.
A nossa aplicação não estava utilizando transparencia mas sim sombra (DropShadow), quando removemos o efeito: Bingo!

Não estou querendo dizer que o DropShadow causa problema de performance, tanto que continuamos usando, mas removemos esse efeito em alguns pontos para ter a melhoria necessária sem prejudicar o layout, ou seja, é importante ficar atento ao uso desse tipo de recurso e o quanto ele pode onerar o desempenho da aplicação.

Abraços!

HTTPS no IIS Express

Recentemente comecei a utilizar o IIS Express para conferir as suas funcionalidades.

Um dos recursos que eu achei interessante é a utilização do HTTPS local. Para utiliza-lo basta clicar com o botão direito sobre o projeto e selecionar a opção “Use IIS Express…”

Será exibido uma janela pedindo confirmação para a criação de um diretório virtual para o seu projeto.

Depois de criado o diretório virtual você deve acionar o botão F4 sobre o projeto e habilitar a opção “SSL Enable”.

Prontinho, agora basta você rodar a sua aplicação através do endereço mesmo endereço só que utilizando https ao invés do http.

Baixar o IIS Express.

Site sobre CQRS

Você pode encontrar vídeos, documentos e exemplos sobre CQRS no http://cqrsinfo.com/. Vale a pena conferir.

Contextualizando os seus testes

O Giovanni Bassi postou em seu blog sobre a técnica AAA (Arrange, Act, Assert) para criação de testes. Ele aproveita para abordar o principio de que cada teste só deve testar uma única coisa, e o quanto isso pode ser complicado.

Aproveitando o gancho, partindo do exemplo que ele apresentou da calculado, vamos implementar o método de divisão:

[TestClass]
public class TestCalculadora
{
    private Calculadora _calculadora;
    private int _resultado;

    [TestInitialize]
    public void Inicializar()
    {
        Arrange();
        Act();
    }

    private void Arrange()
    {
        _calculadora = new Calculadora();
    }

    private void Act()
    {
        _resultado = _calculadora.Dividir(10, 5);
    }

    [TestMethod]
    public void Resultado2()
    {
        Assert.AreEqual(2, _resultado);
    }
}

public class Calculadora
{
    public int Dividir(int a, int b)
    {
        return a / b;
    }
}

Legal, mas também precisamos testar a divisão por zero para saber como o método irá se comportar. Como podemos fazer isso?

É nesse momento que precisamos contextualizar nossos testes, isso significa que vamos testar a mesma rotina em cenários diferentes, no exemplo da calculadora precisamos gerar o cenário do dividir com o divisor maior que zero e divisor zero. Podemos testar conforme abaixo:

public abstract class TestarCalculadora
{
    protected Calculadora Calculadora { get; private set; }
    protected int Resultado { get; set; }

    [TestInitialize]
    public void Inicializar()
    {
        Arrange();
        Act();
    }

    private void Arrange()
    {
        Calculadora = new Calculadora();
    }

    protected abstract void Act();

}

[TestClass]
public class TestarDivisaoComDivisorMaiorQueZero : TestarCalculadora
{

    protected override void Act()
    {
        Resultado = Calculadora.Dividir(10, 5);
    }

    [TestMethod]
    public void ResultadoIgual2()
    {
        Assert.AreEqual(2, Resultado);
    }
}

[TestClass]
public class TestarDivisaoComDivisorZero : TestarCalculadora
{
    private bool _divisaoPorZeroGerada = false;

    protected override void Act()
    {
        try { Resultado = Calculadora.Dividir(10, 0); }
        catch (DivideByZeroException) { _divisaoPorZeroGerada = true; }
    }

    [TestMethod]
    public void ExcecaoDivisaoPorZeroGerada()
    {
        Assert.IsTrue(_divisaoPorZeroGerada);
    }

    [TestMethod]
    public void ResultadoIgualZero()
    {
        Assert.AreEqual(0, 0);
    }
}

Contextualizar os testes em cenários nos permite realizar várias verificações em vários cenários de uma mesma transação.
Essa é uma técnica muito simples, porém muito poderosa. Se você utiliza BDD com certeza já conhecia.

Grupo de estudos: Referências de DDD

Pro pessoal do grupo de estudos e para todos os outros que se interessarem por DDD, abaixo segue uma série de links que considero interessante para ficar por dentro do assunto (Lembrando que o livro do Evans é leitura obrigatória ok?).

http://domaindrivendesign.org/
http://www.infoq.com/minibooks/domain-driven-design-quickly
http://www.infoq.com/presentations/greg-young-unshackle-qcon08
http://www.infoq.com/presentations/Value-Objects-Dan-Bergh-Johnsson
http://www.infoq.com/articles/ddd-in-practice
http://devlicious.com/blogs/casey/archive/tags/DDD/default.aspx
http://codebetter.com/blogs/gregyoung/archive/tags/DDD/default.aspx
http://jimmynilsson.com/blog/
http://elegantcode.com/category/ddd/
http://www.vimeo.com/7838858

Permitir que faça errado!!

Você já tomou uma bronca por ter feito uma chamada de um método em um lugar errado? (Ex.: gravar um log, abrir ou fechar uma conexão ou transação).
Geralmente quando tomamos uma bronca dessa, do arquiteto responsável por exemplo, abaixamos a cabeça e vamos arrumar o "erro". Mas hoje, quando me deparo esse tipo de coisa eu levanto a questão: O método só foi chamado do lugar errado por que a aplicação deixou que isso fosse feito.

Desenhar uma aplicação de forma que seja fácil fazer o que é certo e difícil fazer o errado é um grande desafio, mas o fato de ser difícil não significa que não deva ser tentado. Ter um conhecimento mais profundo de OO e das ferramentas que utilizamos com certeza nos ajudam a alcançar esse objetivo.

Por tanto, da próxima vez que você passar por esse tipo de situação independente do seu papel, do cara que esta dando ou recebendo a bronca, reflita sobre como esta desenhado a aplicação, isso pode fazer uma grande diferença.

Desvendando o Application Layer

Sabemos que o coração do DDD esta no domínio, dedicamos grande parte da nossa atenção a ele.
Mas gostaria de destacar o papel do application layer e tentar esclarecer algumas confusões sobre ele.

Se você já procurou sobre application layer na internet, que vou chamar aqui de camada de aplicação, com certeza deve ter encontrado várias definições e aplicabilidades diferentes sobre o mesmo, por exemplo, "Application Layer é o mesmo que Service Layer" ou até mesmo relacionar com tecnologias como Web Services e WCF.

Essa confusão de certa forma se justifica pelo fato de que, a responsabilidade da camada de aplicação é de coordenar (ou delegar) os trabalhos realizados pelo domínio, o que é muitas vezes encarado como um façade, o que não esta errado, mas é nessa comparação que começa os problemas, por que o service layer também pode ser um façade.

Devido a esses problemas de definições e comparações, como você não tem um Service Layer em todos os projetos, você pode encarar que talvez não precise de uma camada de aplicação, e é ai que ao meu ver chegamos no ápice do engano.

Para entender bem as diferenças entre eles é necessário destacar uma frase da definição do Evans sobre o application layer: "The tasks this layer is responsible for are meaningful to the business"

Ou seja, não é simplemente chamar métodos de objetos de domínio em uma ordem específica, mas coordenar as tarefas de forma significativa ao negócio. Se você vê semelhanças entre a camada de aplicação e o controller do MVC elas param na palavra coordenar, ok? A controller coordena as interações entre a View e a Model, não é disto que estamos tratamos nesse momento.

Nós, desenvolvedores, geralmente pensamos nas funcionalidades essencialmente como CRUD, fazemos isso por vários motivos, mas talvez o principal se refere a comodidades de interações com banco de dados. O problema desse pensamento é que para o negócio nem sempre o CRUD atende, o cliente não deleta um recebimento ele provavelmente faz um estorno, o cliente não faz um insert de ordem ele abre uma ordem de produção.

A função da camada de aplicação é expor operações realizadas pelo domínio de forma que façam sentido ao domínio, por tanto, se o seu domínio abre uma ordem de produção não faz sentido eu ter SaveProductionOrder() na minha camada de aplicação mas sim OpenProductionOrder().

Isso não quer dizer que os famosos métodos Save, Delete e similires não devam existir na sua camada de aplicação, devido ao fato de que, em alguns casos, não é possível determinar um termo de negócio para essas ações.

Outro ponto importante é a questão da leitura de dados, no DDD nós obtemos os dados através do repositório, faz sentido criar métodos no Application Layer para ler dados? Eu respondo, nenhum. Enquanto em um serviço nós geralmente o utilizamos para operações de leitura e/ou escrita, a camada de aplicação só coordena as operações realizadas pelo meu domínio, quando eu preciso ler alguma coisa eu peço direto para o repositório.

Você deve estar se perguntando: Mas eu preciso de um acesso único ao domínio, não preciso?
Essa busca por um caminho linear é herança do BOLOVO onde você tinha UI > BL > DL > BL > UI.
Essa idéia de que tudo tem que passar pelo domínio gera grandes transtornos para identificar as responsabilidades de cada coisa ou de até mesmo um alto acoplamento entre o domínio e outros recursos da minha aplicação, afinal, tudo passa pelo meu domínio.

No desenho apresentado pelo Evans vemos claramente que isso não é necessário e nem deve ser praticado. Se precisamos de uma funcionalidade que se encontra na camada de infraestrutura podemos acessar diretamente dessa camada.


Concluíndo, apesar das semelhanças que a camada de aplicação tenha com outras funcionalidades precisamos ter em mente que ela precisa estar totalmente comprometida com o negócio.