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.

También hay un ejemplo de código:

1) En Django

2) En matraz

3) En Ruby

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

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 menor denominador común 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 lenguaje. Esto se hace en gran medida por razones de marketing para que atraiga a la demografía más grande.

Esto no significa que las técnicas no sean aplicables o utilizadas en otras lenguas. Por lo que sé de DDD la mayoría de los principios son independientes del lenguaje y AFAICR el libro DDD original casi no tenía muestras de código (pero hace un par de años que lo leí, así que puedo estar equivocado).

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é?

Herramientas

Con tipado estático idiomas los utillajes son generalmente más fuertes. Es por eso que algunas personas están usando TypeScript en lugar de JS simple, porque te ayuda a escalar tu código haciendo que las refactorizaciones sean más fáciles. Refactorización es algo presente en todo momento cuando se mantiene un código DDD debido a que el negocio a veces cambia y su conocimiento sobre el modelo evoluciona a diario, 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 él. Ahora estoy trabajando en un proyecto DDD escrito en Ruby y una de las cosas que más echo de menos es la falta de un IDE fuerte. En Ruby o Python la gente está acostumbrada a trabajar usando editores de texto, no IDE. Es difícil para mí ver gente escribiendo cosas que algún IDE o editor de texto debería escribe para mí (es decir, falta de autocompletar ). Es difícil ver a la gente buscando la ruta completa de un archivo en Vim solo para abrirlo y echar un vistazo a 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 para ir a la definición clase o método, sin ambigüedad de archivo. Y ni siquiera he hablado de experiencia de depuración , me duele ver a la gente escribiendo binding.pry (para los desarrolladores que no son de ruby es algo así como un palabra clave "debugger" en js) en su código solo para depurarlo en el terminal en lugar de simplemente establecer un punto de interrupción 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 tienes todas las características de OOP como interfaces y clases abstractas. Eso a veces trae algunas dificultades para hacer que el código sea expresivo y claro.

Unidad pruebas

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

Tipificación dinámica

Necesitas usar duck typing si quieres hacer algún tipo de comprobación de tipos. No hay ayuda del compilador que se obtiene.

Beneficios de los lenguajes de escritura dinámica

A salvo del Infierno de la Tipificación

Siempre hay compensaciones al elegir entre lenguajes dinámicos OOP vs estáticos. Un problema común en los lenguajes de tipo estático al igual que C# y Java es que a veces el sistema de tipos puede hacer que el código sea mucho inexpresivo y demasiado detallado. Algunos desarrolladores tienden a caer en el infierno de tipificación genérica. Pero no todos los lenguajes tipeados estáticamente tienen este problema (F# es uno de ellos, debido a la fuerte inferencia de tipos).

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 tonto (la interfaz) que no represente nada más que el deseo de probar el código. En Ruby puedes hacer eso 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 :(

Concluyendo, creo que es posible escribir una buena" empresa " DDD aplicaciones 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 mantenible).

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

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 + una nueva programación idioma. Una decisión más estratégica que puramente técnica. La compañía (una startup) probablemente no llegaría tan lejos sin ella.

Si el Diseño basado en dominios es un patrón de diseño efectivamente definido, ¿por qué importa el lenguaje que esté utilizando? Los consejos para filosofías de diseño y similares deben ser en gran medida agnósticos del lenguaje. Son de mayor nivel que el idioma, por así decirlo.

Python parece no 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 están probablemente en computación científica o en aplicaciones web. Ambos campos se relacionan con las ciencias (informáticas), no con negocios específicos de dominio, mientras que el DDD es más aplicable dentro de negocios específicos de dominio.

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