2009-08-24 16 views
5

Según this definition, el concepto de Anémica modelo de dominio de Fowler es: modelo de dominio¿Un modelo de dominio anémico significa que no puede usar clases de utilidad/soporte como "ayudantes" para su modelo de dominio?

un software donde la lógica negocio se lleva a cabo fuera de el dominio objetos

y

Con este patrón, la lógica es típicamente implementada en clases separadas que transforman el st de los objetos de dominio . Fowler llama a tales clases de secuencias de comandos de transacción.

Si tomamos el ejemplo de un carrito de compras, el objeto Cart sería el objeto de dominio. Pero procesar el carrito hasta el pedido final y el recibo implica verificar el inventario del pedido y procesar el pago con tarjeta de crédito. Muchas de estas cosas requieren clases de utilidad ya que hacer todo dentro del objeto Cart significaría que la clase Cart sería enorme y engorrosa. Entonces, ¿eso significa que el carro en este ejemplo sería un modelo de dominio anémico y estas clases de utilidad serían "secuencias de comandos de transacción" según la definición anterior?

Respuesta

4

Un concepto clave del diseño impulsado por dominio es crear un diseño rico que transmita y refleje la jerga de sus expertos de dominio (usuarios de negocios). Luego, desea que su código se convierta en una expresión de ese modelo de dominio. (vea "Lenguaje ubicuo" y "Diseño impulsado por modelo" en el DDD Patterns summaries).

Al hacer esto, creará nombres para sus entidades (clases) que reflejen cómo un usuario de negocios podría describirlos. Además, creará métodos en esas clases que también reflejen el dominio.

Teniendo esto en cuenta, puede ser útil considerar cómo piensa acerca de sus clases de "ayuda" o "utilidad". El uso de algunas de sus descripciones, es posible que tenga clases y método tales como:

product = GetProduct(data.productId); 
shoppingCart.add(product); 
receipt = customer.Purchase(shoppingCart); 

Su método Customer.Purchase podría hacer cosas como:

creditCard = this.getCreditCart(creditCardNumber); 
purchaseNumber = creditCard.Charge(shoppingCart.Total); 

que se dan cuenta de estos ejemplos no están completos o incluso totalmente exacta , pero espero que la idea sea útil.

En respuesta a su pregunta original: Sí, está bien tener la utilidad y las clases de soporte. Sin embargo, desea crear esas clases de soporte y asignarlas a entidades de dominio real. Después de trabajar con sus usuarios, es probable que pueda crear entidades de dominio significativas que sean más que entidades de script de transacción.

Espero que esto ayude. ¡Buena suerte!

+1

Perdóneme la curiosidad, pero la pregunta, tal como lo entendí, era sobre el modelo de dominio neutral, que prohíbe por completo métodos como el anterior Comprar() en las clases de dominio. Con el modelo de dominio anémico las clases de dominio no tienen nada más que getters/setters y terminarías con todo el comportamiento (!) Implementado fuera de las clases de dominio. Por lo tanto, con las suposiciones anteriores, la adopción del modelo de dominio anémico te obligará a usar clases de ayuda/utilidad, ¡ya que no tienes otra opción! ¿Por qué no utilizar lo mejor de ambos mundos: algoritmos universales en el modelo de dominio y el resto afuera! Stefan – struppi

+1

@struppi - ¿Por qué dices que métodos como el anterior Comprar() estarían prohibidos? Este método probablemente sería más que "get/setting", ya que contendría lógica de negocios para realizar la compra. –

1

Como dijo Chris, está bien tener una utilidad y clases de soporte si esas clases de soporte se asignan a entidades de dominio real descubiertas del lenguaje del usuario. A veces, muchas "clases de ayuda" son un síntoma de un modelo anémico si están relacionadas con clases que tienen principalmente setters & getters (en esos escenarios, los helpers crecen a partir de un comportamiento que no está asignado correctamente a objetos de dominio).

Cuestiones relacionadas