patrón implementing example español driving driven domain ddd data c# java domain-driven-design bdd

c# - implementing - ¿Es posible usar DDD y BDD juntos?



implementing domain driven design español (5)

Me gusta el desarrollo medio que se logra con DDD. El desarrollo es impulsado por el dominio, la parte más sólida de la aplicación. No dependemos de la infraestructura, la persistencia y la presentación. Eso suena bien. Pero no tiene valor comercial.

Aquí viene el BDD centrado en el negocio con desarrollo externo. No tenemos un diseño de dominio inicial (elección de entidades, objetos de valor, agregados). Tomamos historias de usuarios, escribimos algunos escenarios y los implementamos uno por uno. Comenzamos el desarrollo desde la parte más cambiante de la aplicación, desde la presentación. Odio escribir pruebas de aceptación frágiles. ¿Vos si?

Entonces, si alguien aquí tiene historias exitosas sobre la aplicación de DDD al estilo de BDD, por favor, comparta algunas conmigo :)

  1. ¿Escribes esas frágiles pruebas para su presentación?
  2. ¿Tiene algún diseño por adelantado antes de crear parte del dominio para la historia de usuario que se implementa? ¿O te refieres a los patrones de DDD después de implementar la historia?

Cualquier ayuda será apreciada. ¡Gracias!

¿No puedo ver por qué no debería funcionar? BDD es un desarrollo impulsado por el comportamiento, es decir, sobre su proceso de desarrollo, que podría (debería) impactar su diseño. DDD es un diseño controlado por dominio y se trata más sobre el diseño general de su sistema. Para resumir, en BDD (o en cualquier otro xDD) usted define cómo debería funcionar algo y luego depende de su dominio cumplir esos requisitos. Si implementa esos requisitos utilizando DDD o algo más no debería importar ... aún necesita una marca verde al lado de esa prueba.

ACTUALIZACIÓN: No creo que DDD sea sobre dirección, para mí DDD es sobre mantener su código limpio. Yo diría que usar BDD es una manera de ayudar a mantener su código limpio, si comienza con solo implementar su dominio, puede terminar con un dominio que sea demasiado complejo. La forma en que me gustaría hacerlo es usar BDD para definir mis características (como la funcionalidad de inicio de sesión) y diferentes escenarios (como el inicio de sesión exitoso y no exitoso). Después de eso no escribiría algunas pruebas unitarias, así que tengo algo que prueba el código y no el comportamiento. Cuando lo he implementado, las pruebas de unidad pasan con suerte la prueba de BDD también. Después de eso, es el momento de la refactorización y durante la refactorización todas las pruebas deben permanecer en verde. Puede verlo como dos ciclos, un ciclo externo que prueba el comportamiento (BDD) y un círculo interno que prueba la implementación (TDD). Esto no debería impedirle utilizar los principios de DDD; en cambio, diría que sería más fácil mantener limpio su dominio y resolver su problema real.

Actualización 2 (enlaces):

Ofrezco a Dan North y a mí mismo (por favor, disculpe el aspecto de los conejos, fue mi primer video), entrevistado por uno de los colegas de Eric Evans en BDD y DDD.

También puede tener una vista previa de un segmento del borrador del primer capítulo de un libro de BDD que estoy escribiendo (espero que con Dan también):

Como otro efecto, discutir los escenarios sin ninguna palabra técnica, en lenguaje de negocios, permitió que los desarrolladores aprendieran ese lenguaje. Luego llevaron ese lenguaje a su base de código, implementando clases con nombres de elementos del dominio de negocios, métodos con nombres de capacidades de esos elementos, y propiedades y variables con nombres de sus propiedades y subelementos de la vida real.

Este uso de la terminología de negocios en el código se conoce como el lenguaje ubicuo en el libro de Eric Evans, "Diseño dirigido por dominio". Eric sugiere que cuando los desarrolladores comienzan a codificar en un lenguaje que coincida con la terminología de las partes interesadas de negocios, las conversaciones se vuelven fluidas, sin la necesidad de que los desarrolladores (o los analistas como proxy) se traduzcan de los detalles técnicos a los conceptos de dominio. El código se vuelve más legible y más fácil de entender para los recién llegados. El valor de cada objeto en el sistema se vuelve más obvio, así como la ruta por la cual devuelve su valor al usuario para que el usuario pueda proporcionar valor a la empresa.

JBehave ha introducido algo nuevo. No solo los desarrolladores usaban el lenguaje de dominio de negocios; ahora utilizaban un lenguaje que la empresa entendía para describir la terminología del software. En lugar de palabras como prueba , prueba de aceptación , actuar , organizar , afirmar , barra roja y barra verde , los desarrolladores hablaron sobre ejemplos , escenarios , contextos , eventos , resultados y comportamiento .

JBehave, y BDD, habían introducido un lenguaje ubicuo para el desarrollo de software en sí.

Espero que esto muestre que BDD y DDD funcionan muy bien juntos de hecho. Todos los comentarios son bienvenidos, excepto en mi sentido del vestido.

Edit: Tienes razón, el dominio es bastante sólido. Es por eso que nos enfocamos en las cosas más riesgosas, como la presentación y la infraestructura, y hablamos sobre nuestra comprensión del dominio utilizando escenarios. No podemos obtener comentarios sobre nuestra comprensión del dominio hasta que tengamos algo con lo que podamos obtener información, pero eso no nos impide buscar la comprensión de todos modos.

Permítanme agregar el precursor a mi respuesta de que no soy de ninguna manera un experto en BDD, TDD o primera prueba. Digressing ...

He encontrado que todas las metodologías de desarrollo de primera prueba requieren una premonición clarividente a nivel de bola de cristal cuando se inicia desde cero para un alto nivel de éxito. Dado que eso es completamente impráctico, creo que este nivel de pruebas solo tiene sentido después del período de creación de prototipos en el que se ha desarrollado el DDD principal. Junto con otras decisiones centrales de la arquitectura, se establece que existe un proceso de pensamiento claro sobre cómo lograr el éxito.

Al ser un arquitecto empresarial, mis pensamientos # 1 en el desarrollo de proyectos son siempre un éxito repetible. Esto siempre es mucho más factible cuando la arquitectura central será consistente entre proyectos, y lo que es más importante aún, en el mismo proyecto.

Ahora, para responder a su pregunta directamente, en mi libro DDD siempre vendría primero. Sin la DDD, es mi opinión que básicamente estás acuchillando en la oscuridad cuando se trata de decisiones de diseño de arquitectura clave que podrían volverse enormemente dolorosas más adelante. DDD es también mucho más un concepto de nivel superior en mi opinión que se expresa en diagramas de bloques de alto nivel. Con muchas historias de BDD que comprenderán la interacción de nivel DDD entre sistemas.

En lo que respecta a la pregunta sobre si escribiría historias para la interacción de UI, definitivamente hay valor en ellas. Sin embargo, podrían fácilmente omitirse en lugar del tiempo necesario para otros esfuerzos, ya que las restricciones del proyecto tienden a surgir siempre antes de lo esperado. Las pruebas de IU codificadas que escriba no tienen que ser frágiles. Sin embargo, si son frágiles, para empezar no tienen ningún propósito. Si sigue una convención clara de la denominación de elementos HTML, además de escribir HTML semántico, puede crear pruebas de unidad de IU muy confiables. Esto se expresa mucho más fácilmente en MVC que en formas web (en ASP.NET, java probablemente tiene algún tipo de paralelo similar).

RE: ¿sugieres crear un rasguño de dominio antes de implementar las historias?

En general, incluso iría un poco más lejos al definir los conceptos de clase de modelo y las interfaces de servicio. En ese momento, cuando se inicia la implementación de interfaces, es cuando yo comenzaría a trabajar en las historias. Esto también conduciría a cambios en los modelos o interfaces a medida que surjan. Dejar las interfaces de servicio completas y los modelos que se diseñarán a medida que evolucionen a partir de historias que creo que producirían demasiada visión de túnel. Que comenzarás a hacer modelos y / o interfaces que resuelvan una historia específica pero que tengan poco o ningún sentido para el panorama general.

Entonces, para resumir realmente en tu pregunta de media-out, vs-in-in. Creo que son muy capaces de desarrollarse mutuamente, más aún si empiezas con DDD a la mitad de los conceptos generales, y luego trabajas desde afuera para los detalles. Siento que hacer ese proceso a la inversa llevaría a una mayor refactorización de la necesaria, y una refactorización mucho más difícil, ya que estaría intentando extraer su dominio central de una colección de historias relacionadas que probablemente se desarrollaron en un silo.

Tuve la suerte de poder hacer uno de los talleres de ''Especificación por ejemplo'' de Gojko Adzic en junio de este año.

Gojko hizo referencia a Eric Evans y DDD a lo largo de la clase.

El momento de la bombilla para mí fue cuando el ejercicio que estábamos haciendo nos llevó a refactorizar el modelo de dominio ''para un conocimiento más profundo''. Es decir, a medida que obtuvimos una visión más profunda del dominio, refactorizamos el modelo y con ello las pruebas de BDD para reflejar eso. visión.

El ejemplo en la clase fue un juego de Blackjack en el que inicialmente modelamos una mano de cartas como un valor entero basado en la suma total de las cartas. A medida que llegamos a una comprensión más profunda de cómo funcionaba el juego de Blackjack, presentamos el concepto de una mano que es una mano de ''Blackjack'', por lo que dejamos de usar un valor entero para representar que la mano es un valor entero o un ''Blackjack la mano

En mi práctica busco evolucionar el Modelo de Dominio y su lenguaje ubicuo. Luego uso ese lenguaje ubicuo en mis pruebas de BDD.