python - qué - que es un lenguaje de programacion web

¿Por qué el diseño controlado por dominio parece ser solo popular en lenguajes estáticos como C#y Java?

Question

El diseño basado en dominios se ha convertido en mi arquitectura preferida. He podido encontrar una gran cantidad de libros y tutoriales para aplicar los principios de DDD en el marco de ASP.net. En su mayoría, parece inspirado en lo que los desarrolladores de Java han estado haciendo durante un buen rato.

Para mis proyectos personales, estoy empezando a inclinarme más hacia Python a pesar de que me resulta difícil abandonar la escritura estática. Esperaba encontrar mucha ayuda para aplicar DDD utilizando un lenguaje dinámico. No parece haber nada por ahí sobre Python y DDD. ¿Porqué es eso? Obviamente, DDD puede aplicarse bastante bien a Python. ¿La gente no asume proyectos tan grandes en Python? ¿O es más fácil aplicar DDD en Python dada la escritura dinámica, por lo tanto, reduce la cantidad de aprendizaje requerido?

Quizás mi cuestionamiento se deba a mi falta de experiencia con Python. Cualquier consejo que pueda tener para mí será apreciado.

Answer 1

Creo que es definitivamente popular en otros lugares, especialmente en lenguajes funcionales. Sin embargo, ciertos patrones asociados con el Big Blue Book no son tan aplicables en lenguajes dinámicos y marcos como Rails tienden a alejar a las personas de las ideas de contexto acotado.

Sin embargo, el verdadero empuje de DDD es el lenguaje ubicuo ciertamente prevalece en los lenguajes dinámicos. Los rubyistas disfrutan especialmente la construcción de lenguajes específicos de dominio. Piense en cómo las características de pepino terminan apareciendo, ¡eso es lo más DDD que hay!

Tenga en cuenta que DDD no es una idea nueva en absoluto, solo se volvió a empaquetar de una manera que obtuvo una buena aceptación de C # y Java. Esas mismas ideas están en otros lugares bajo diferentes pancartas.

Answer 2

Esta pregunta me molesta durante bastante tiempo, así que decido recopilar todos los datos valiosos sobre este tema. Finalmente termino con este repositorio de github .

Hay algunos ejemplos de código también:

1) En Django

2) En el matraz

3) En Ruby

Y algo más. Pero definitivamente no es suficiente.

Answer 3

La mayoría de los libros sobre técnicas de diseño / codificación, como TDD y patrones de diseño, están escritos en Java o C #, ya que actualmente es el lenguaje de denominador común más bajo y tiene la base de usuarios más amplia, o al menos la base más grande de personas que pueden leer y entender el idioma. Esto se hace en gran parte por razones de mercadeo para que sean atractivas para el grupo demográfico más grande.

Eso no significa que las técnicas no sean aplicables o utilizadas en otros idiomas. Por lo que sé de DDD, la mayoría de los principios son independientes del lenguaje y AFAICR, el libro original de DDD no tenía casi ninguna muestra de código (pero es un par de años desde que lo leí, por lo que puedo estar equivocado).

Answer 4

Pondré mis dos centavos aquí ...

Creo que es perfectamente posible escribir buenos proyectos DDD en lenguajes dinámicos, pero es más difícil de mantener que en los estáticos. ¿Por qué?

Estampación

Con lenguajes tipográficos estáticos, las herramientas son generalmente más fuertes. Es por eso que algunas personas usan TypeScript lugar de JS simple, porque le ayuda a escalar su código al hacer que las refactorizaciones sean más fáciles. La refactorización es algo presente en todo momento cuando se mantiene un código DDD porque la empresa a veces cambia y su conocimiento sobre el modelo evoluciona todos los días; con este conocimiento, su código también debe evolucionar. La mayor parte de mi experiencia ha sido con C # y he construido muchos proyectos DDD con ella. Ahora estoy trabajando en un proyecto de DDD escrito en Ruby y una de las cosas que más extraño es la falta de un IDE fuerte. En Ruby o Python, la gente está acostumbrada a trabajar con editores de texto, no con IDE. Es difícil para mí ver a personas que escriben cosas que un IDE o editor de texto deberían escribir para mí (es decir, falta de autocompletar ). Es difícil ver a las personas que buscan la ruta completa de un archivo en Vim solo para abrirlo y ver los detalles de un método o una clase: en VS Code o Visual Studio, por ejemplo, un solo golpe en F12 debería ser suficiente. a la definición de clase o método, sin ambigüedad de archivo. Y ni siquiera hablé sobre la experiencia de depuración , me duele ver a las personas que escriben binding.pry (para los desarrolladores que no son ruby ​​es algo así como una palabra clave "debugger" en js) en su código solo para depurarlo en el terminal. de sólo establecer un punto de ruptura en la línea. La lista es más grande que esto, pero creo que es suficiente para hacer el punto sobre "herramientas".

OOP expresividad

En algunos lenguajes dinámicos como Python y Ruby, no tiene todas las características OOP como interfaces y clases abstractas . Eso a veces trae algunas dificultades para hacer que el código sea expresivo y claro.

Examen de la unidad

Necesita escribir muchas más pruebas unitarias para reemplazar lo que el compilador podría hacer por usted.

Tipificación dinámica

Debe utilizar la escritura de pato si desea realizar algún tipo de comprobación de tipo. No hay ayuda del compilador que obtienes.

Beneficios de los lenguajes dinámicos mecanografiados.

A salvo de la tipificación del infierno

Siempre hay ventajas y desventajas al elegir entre OOP dinámico frente a lenguajes estáticos. Un problema común en lenguajes tipificados estáticamente como C # y Java es que a veces el sistema de tipos puede hacer que el código sea muy inexpresivo y demasiado detallado. Algunos desarrolladores tienden a caer en el infierno de la tipificación de genéricos . Pero no todos los idiomas tipificados estáticamente tienen este problema (F # es uno de ellos, debido a la fuerte inferencia de tipo).

Pruebas

No tener tipos estáticos también ayuda en algunos casos cuando, por ejemplo, no desea crear una interfaz solo para inyectar a su clase y hacerla comprobable. En estos casos, la interfaz no ayuda en la legibilidad, de hecho, perjudica la legibilidad porque necesita crear un archivo simple (la interfaz) que no represente nada más que el deseo de probar el código. En Ruby, puedes hacerlo de varias maneras sin necesidad de crear una interfaz, un ejemplo sería este:

class DispatchOrderService
  def initialize(overrides = {})
    @repository = overrides.fetch(:repository) do
      ::Infra::OrderRepository.new
    end

    @mail_service = overrides.fetch(:mail_service) do
      ::Infra::MailService.new
    end
  end

  def dispatch(order)
    order.dispatched
    repository.save(order)
    mail_service.notify_order_dispatched(order)
  end
end

Sí, con este enfoque rompimos la arquitectura limpia :(

Así que para concluir, creo que es posible escribir buenas aplicaciones DDD "empresariales" en Ruby incluso si es difícil que en los lenguajes estáticos. Mi proyecto actual es un ejemplo de eso (60k líneas de código y aún se puede mantener).

También el punto mencionado por @GeorgeMaueris es importante. Puede enfrentar problemas al implementar DDD en marcos que le imponen la forma de organizar su código. Aquí elegimos usar Hanami lugar de Rails debido a esto, pero incluso Hanami es más "crítico" que nos gustaría. Realmente no recomiendo a nadie que busque "marcos" para construir DDD. El diseño / arquitectura cambia de una aplicación a otra y también evoluciona. Cuando eliges los marcos "DDD", a veces te enfrentas luchando contra ellos (haciendo soluciones o parches de monos).

Entonces, tal vez puedas preguntarme por qué elegimos Ruby en absoluto. El punto principal para usar Ruby aquí fue que casi el 100% del equipo estaba compuesto por desarrolladores de Ruby y no queríamos duplicar las dificultades: aprender DDD + un nuevo lenguaje de programación. Más una decisión estratégica que puramente técnica. La compañía (una startup) probablemente no llegaría tan lejos sin eso.

Answer 5

Python no parece ser demasiado popular en las empresas hasta ahora en comparación con Java (pero creo que el viento está en esa dirección. Un ejemplo es Django, que fue creado por una compañía de periódicos). La mayoría de los programadores que trabajan con python probablemente se encuentren en informática científica o en aplicaciones web. Ambos campos se relacionan con las ciencias (computacionales), no con empresas específicas del dominio, mientras que DDD es más aplicable dentro de las empresas específicas del dominio.

Así que diría que es sobre todo una cuestión de legado. C # y Java fueron dirigidos hacia aplicaciones empresariales desde el principio.

Answer 6

Si Domain Driven Design es un patrón de diseño definido de manera efectiva, ¿por qué importa qué idioma está usando? El asesoramiento para las filosofías de diseño y similares debe ser en gran medida agnóstico del lenguaje. Son más altos que el idioma, por así decirlo.