Discussion on: A Arquitetura simples

Boas perguntas Kauan! Vou considerar o disclaimer que você mencionou (não-cruds). Vamos lá:

1. Nesse caso não faz né? Se seu domínio exige entidades ricas por qualquer que seja o motivo eu não vejo razão pra tentar justificar um domínio anêmico. Esse é o principal mote do meu texto: "Os requisitos e o teu problemas que vão guiar o teu design". Se o seu design requer um domínio complexo então as suas entidades não serão anêmicas e logo você vai usar OOP. Se o seu domínio for composto apenas de estrutura de dados indo pra lá e pra cá então você vai ser mais anêmico, menos OO e mais procedural.
2. Concordo, você precisa obedecer as regras do framework. Mas aí fica a pergunta: Por que você precisa do encapsulamento no caso específico de uma entidade anêmica? A vantagem do encapsulamento ali vale mais do que a simplificidade de uso do framework? Se sim, eu diria pra manter os modelos separados, se não então mantém eles juntos.
3. Porque seria ingênuo? O Linhares na thread que originou essa discussão fez um excelente ponto que software complexo de vdd é extremamente difícil de você olhar o futuro e acertar qual vai ser a interface correta. Existem boas chances do nosso serviço que você pensou não encaixar direitinho na interface que você possuia. Tendo dito isso, note que eu descrevo qual foi minha experiência nos últimos 8 anos. Os nossos serviços dependem exclusicamente de um serviço externo que é fornecido por uma equipe específica. Se o fornecedor mudar, provavelmente será a mesma equipe que vai mudar ele, eu só preciso mudar a implementação da minha Facade em 1 único ponto. No nosso caso que você teve que alterar diversos pontos, o que deve ter ocorrido foi uma Facade não ser bem definida e detalhes externos vazaram para dentro do caso de uso. Se você trabalha em um software que dependencias externas mudam ou podem mudar com frequência, uma interface faz sentido, até porque você provavelmente tem os requisitos necessários pra criar uma abstração. Agora, criar uma abstração porque as coisas podem mudar, sem requisitos, só no "eu acho que vai mudar", existem boas chances que a sua interface não vai conseguir abstrair o contrato de fato. Como eu falei, tem software rodando faz 10 anos com os mesmos serviços como dependência, isso cobriu 90% dos casos. Valeria realmente a pena ter gastado energia pros outros 10%? No nosso contexto, não valeu e não vale à pena.

Gostei demais das perguntas, torna a discussão bem rica! obrigado demais por participar.