domain driven design - quickly - Extensibilidad con DDD: Módulo V Contexto delimitado en DDD con MEF

implementing domain-driven design

Question

Eric en su libro toca muy poco el tema de los módulos . Tampoco habla sobre la relación de la estructura de los módulos con contextos limitados con ejemplos. ¿Los Contextos limitados contienen módulos o los módulos contienen los Contextos limitados? Cuando una aplicación tiene DDD, ¿qué tan fácil se puede extender?

La estructura de la aplicación es muy importante cuando diseñamos aplicaciones extensibles. El marco de Microsoft MEF puede descubrir automáticamente módulos / componentes desde una dll.

Tomemos un ejemplo. En una aplicación de comercio electrónico, podemos tener un contexto acotado para el procesamiento de pagos . El procesamiento de pagos puede ser abstracto, por lo que luego puedo extender la aplicación con más procesadores de pago como Paypal o Payflow. Actualmente solo tengo Paypal, y pocos meses después quiero integrar Payflow. Para integrar Payflow, puedo tener un ensamblaje (una dll) que implemente la interfaz del Procesamiento de pagos . Puedo colocar esa dll en la aplicación, y el MEF la descubrirá automáticamente.

El desafío aquí es que la dll creada para el procesamiento de pagos de PayFlow es un módulo, no un Contexto delimitado (BC). Si lo creé como un BC, tenemos dos BC para el procesamiento de pagos . (El BC creado para Paypal y el BC para el Payflow). Si estructuramos la aplicación con módulos dentro de un Contexto delimitado y el Contexto delimitado como un ensamblaje (dll), los módulos pueden residir en la BC como carpetas y no como ensamblajes (se puede considerar una biblioteca de C # creada en Visual Studio).

¿Cómo podemos manejar este problema de extensibilidad con DDD? ¿Está el procesamiento de pagos , una BC y diferentes carpetas debajo de él como módulos, una para Paypal, etc ... O necesitamos sub-BC dentro de otra BC?

Answer 1

Eric en su libro toca muy poco el tema de los módulos. Tampoco habla sobre la relación de la estructura de los módulos con contextos limitados con ejemplos.

Sí, estoy de acuerdo en que el módulo y la estructura de BC no reciben suficiente cobertura en el libro. Recomiendo la implementación de diseño impulsado por dominio por Vaughn Vernon para más información sobre esto.

¿Los Contextos limitados contienen módulos o los módulos contienen los Contextos limitados?

BCs contienen módulos. Un módulo es como un BC liviano y también pertenece al lenguaje ubicuo.

Cuando una aplicación tiene DDD, ¿qué tan fácil se puede extender?

Eso depende de cómo lo diseñes. Nada sobre la DDD en sí evitaría la extensibilidad.

¿Está el procesamiento de pagos, una BC y diferentes carpetas debajo de él como módulos, una para Paypal, etc ... O necesitamos sub-BC dentro de otra BC?

Yo modelaría cada integración del procesador de pagos como un módulo dentro de un único Procesamiento de pagos a. Además, cada integración es una ACL entre su modelo de procesamiento de pagos y un tercero, como PayPal.

¿O necesitamos sub-BC dentro de otro BC?

No, pero esto toca una noción interesante de sub-BC. No creo que una sub-BC sea una buena idea porque creo que las organizaciones jerárquicas pueden ser peligrosas, lo que lleva a diseños rígidos (ver POO con jerarquías de tipos explícitos, por ejemplo) puede ser problemático. En su lugar, opta por un modelo más plano con potencialmente más BC. Además, en su caso, la estructuración deseada puede lograrse con módulos.