¿Es el uso de interfaces uno a uno con entidades de dominio una buena o mala práctica? ¿Por qué?

La mayor razón para especificar siempre los objetos de dominio como interfaces en lugar de directamente como clases es para darle un grado de libertad en la implementación. En su ejemplo solo tiene un tipo de iAccount, por lo que es un poco redunant.

Pero qué pasaría si tuvieras, por ejemplo:

public class Account : IAccount { ... }       // Usual account, persistent
public class MockAccount : IAccount { ... }   // Test mock object
public class TransAccount : IAccount { ... }  // Account, not persistent
public class SimAccount : IAccount { ... }    // Account in a performance sim

Y así sucesivamente?

Al definir los objetos de dominio como interfaces, puede reemplazar las implementaciones sin alterar la definición de su dominio.

En general, si mis clases no van a ser parte de un patrón de diseño como Estrategia o Visitante yo no agregar interfaces.

Agregar interfaces es realmente útil para patrones de diseño como Estrategia y Visitante, pero en esos casos no copio los getters y setters de las clases de dominio. En su lugar, creo interfaces que son específicas para las interfaces de patrón de diseño que creo.

interface SomeStrategy {
   void doSomething(StrategyData data);
}

interface StrategyData {
   String getProperty1();

   String getProperty2();
} 

Que me permite permitir que las clases de dominio implementen esas interfaces, o usar Patrón de adaptador. Me parece que este es un enfoque mucho más limpio que simplemente la creación de interfaces por el bien de la misma.

El diseño siempre debe reducir la incertidumbre. La creación de interfaces por el bien de ella no reduce la incertidumbre, de hecho, probablemente aumenta la confusión, ya que no tiene ningún sentido.

Las interfaces Uno a uno en las entidades son un anti-patrón

James Gregory lo puso mejor que yo aquí .

Estoy de acuerdo contigo. Las interfaces deben actuar como un contrato, por lo que no tiene valor tener interfaces uno a uno con entidades de dominio. Puede ser útil si desea abstraer un cierto comportamiento. Pero, esto funcionará en ciertos casos.

¿Por qué este se ha esfumado?

Encuentro que tener una interfaz para un objeto de dominio, como dijo Charlie Martin, me permite elegir mi implementación.

Un ejemplo fundamental es el identificador (object.Id) para un objeto, esto será diferente dependiendo de dónde almacene ese objeto y la responsabilidad de crearlo puede o no recaer en la implementación de los datos más adelante. En SQL Server puede optar por un autonumber, pero en Azure table storage puede optar por un Guid, pero no quieres tener que cambiar la lógica de negocio de tu aplicación porque cambias dónde almacenas tus datos.

Puedo o no elegir que se mantenga mi objeto de dominio, o incluso usarlo en la capa de presentación; depende del alcance de mi aplicación cuál es el mejor. Pero agregar un conjunto de interfaces de dominio comunes en una capa común me permite escribir servicios en contra de ellos y reutilizarlos una y otra vez.

Repasaríamos el mismo argumento sobre lo que debería ser una dirección si si no tuviera IAddress, los nuevos programadores estarían reescribiendo cosas para tarjetas de crédito si no fuera por ICreditCard.

La etiqueta anti-patrón es un mal uso del lenguaje, es una simplificación excesiva para describir el valor de las soluciones a tareas complejas y variadas.

Hay un lugar para la mayoría de los patrones, incluso el Singleton difamado, lo que significa que no es un "anti-patrón", al menos en lo que el término sugiere.