design patterns - patterns - ¿El script de transacción es antipattern?
design patterns software (2)
No es un anti-patrón. De hecho, la mayoría de las aplicaciones empresariales (todo lo que he visto) utilizan un script de transacción y no un patrón de modelo de dominio enriquecido.
El patrón de registro activo que mencionó solo es útil cuando tiene una asignación uno a uno bastante simple de entidades de dominio a agregados de tienda persistentes (tablas RDBMS).
El mapeador de datos es algo así como ORM (Hibernate y amigos). Si la lógica de su negocio reside dentro de las entidades de dominio, estas entidades deben mutarse. En mi opinión, esta lógica de parejas que muta el estado (que es inherente cuando se usa ORM) con el estado mismo. Es más sencillo mirar el modelo de su dominio desde el exterior y poner la lógica de su negocio en servicios (scripts de transacción). Además, si su volumen de lógica de negocios es grande, es más difícil encontrar un código relevante cuando está disperso entre las entidades de dominio (es como tener sus scripts de transacciones combinados).
Pero no tiene que terminar con un enfoque completamente procesal ya que puede (y debe) descomponer sus servicios en ''contenedores procesales'' altamente cohesivos independientes.
Bueno, hay un tema similar sobre el script de transacción con la base de datos NoSQL, pero este es sobre el patrón en general. De lo que encuentro sobre el script de Transacción, no está orientado a objetos en absoluto. Es un código básicamente de procedimiento a pesar del hecho de que puede usar objetos en cada línea de su código.
La mejor solución es utilizar un modelo de dominio en su lugar, junto con un registro activo o un mapeador de datos con unidad de trabajo / mapa de identidad / carga perezosa / objeto de consulta y tal. El script de transacción puede ser fácil de usar, pero en realidad es una programación procesal y, por lo tanto, debe considerarse un antipatterno en el mundo orientado a objetos.
¿Qué piensas? ¿Está de acuerdo con que el script de transacción sea antipattern? ¿O realmente tiene una forma de diseñar un script de transacción que esté orientado a objetos en lugar de a un procedimiento disfrazado? Aunque dudo que esto sea posible.
Transaction Script definitivamente no es un anti-patrón.
De lo que encuentro sobre el script de Transacción, no está orientado a objetos en absoluto.
Tienes razón, no lo es, por cierto. Ese hecho, sin embargo, no lo convierte en un anti-patrón. Si bien es un enfoque de procedimiento, de hecho, todavía tiene su lugar adecuado en la serie de patrones de arquitectura de lógica empresarial: solo debe saber en qué caso es una práctica recomendada utilizarlo, y en ese caso no lo es. En pocas palabras: si el dominio de su problema es muy simple, no vale la pena utilizar un patrón más complejo en la lógica de su negocio.
O, como escribe Fowler :
Cuando usarlo
La gloria de Transaction Script es su simplicidad. Organizar la lógica de esta manera es natural para las aplicaciones con solo una pequeña cantidad de lógica, e implica muy poca sobrecarga, ya sea en el rendimiento o en la comprensión.
El anti-patrón en el que podrías pensar se llama Modelo de Dominio Anémico . Este es el caso cuando piensa y crea que está construyendo un Modelo de Dominio, porque su dominio problemático es lo suficientemente complejo para eso, pero en realidad termina en un Script de Transacción, debido a las malas habilidades de organización de código / OO.