[1] Dice: "El horror fundamental de este anti-patrón es que es contrario a la idea básica del diseño orientado a objetos; que es combinar los datos y su procesamiento en un mismo lugar.
Fowler llama a estas clases transaction scripts.
Una transacción puede ver cierta información y otra puede hacer cambios sobre ella.
Un Transaction Script organiza todo esta lógica como un procedimiento, realizando invocaciones a la base de datos o a alguna otra clase que se encargue de ello.
Cada transacción tiene su propio Transaction Script, aunque algunas tareas comunes entre ellas pueden ser situadas en subprocedimientos" En su libro "Patterns of Enterprise Application Architecture", Fowler indica que el patrón transaction script puede ser adecuado para pequeñas aplicaciones y evita tener que lidiar con todo lo relativo al mapeo de objetos a base de datos relacional Razones por las que esto puede ocurrir El modelo de dominio anémico puede aparecer en sistemas que están influenciados por arquitecturas orientadas a servicios, donde el comportamiento no se transporta o no tiende a ello.