cette question me dérange pendant un certain temps donc je décide de recueillir toutes les données précieuses sur ce sujet. Finalement je me retrouve avec ce GitHub repo .

il y a aussi un exemple de code:

1) Django

2) Sur La Fiole

3) Ruby

et d'autres. Mais certainement pas assez.

la plupart des livres sur les techniques de conception/codage tels que le TDD et design patterns sont écrits en Java ou en C#, étant donné qu'il s'agit actuellement du plus petit dénominateur commun et que la base d'utilisateurs est la plus large, ou du moins la plus grande base de personnes capables de lire et de comprendre la langue. Cela est fait en grande partie pour des raisons de marketing de sorte qu'ils font appel à la plus grande démographie.

cela ne signifie pas que les techniques ne sont pas applicables ou utilisées dans d'autres langues. De ce que je sais de DDD la plupart des principes sont indépendants de la langue et AFAICR le livre original DDD avait presque pas d'échantillons de code en elle (mais il est un couple d'années depuis que je l'ai lu, donc je peux me tromper).

je vais mettre mes deux cents ici...

je pense qu'il est parfaitement possible d'écrire de bons projets DDD dans des langues dynamiques, mais est plus difficile à maintenir que dans les langues statiques. pourquoi?

Outillage

avec des laguages statiques dactylographiés, les outils sont généralement plus résistants. C'est pourquoi certaines personnes utilisent TypeScript au lieu de JS , parce qu'il vous aide à mettre à l'échelle votre code en faisant remaniement plus facile. Refactoring est quelque chose de présent à chaque fois que vous maintenez un code DDD parce que l'entreprise change parfois et votre connaissance du modèle évolue à chaque jour, avec cette connaissance votre code doit évoluer aussi. La plupart de mon expérience a été avec C# et j'ai construit beaucoup de projets DDD avec elle. Maintenant je travaille dans un projet DDD écrit dans Ruby et l'une des choses qui me manque le plus est l'absence d'IDE fort. Dans Ruby ou Python les gens sont utilisés pour travailler en utilisant le texte des éditeurs, pas des IDE. Il est difficile pour moi de voir des gens écrire des choses qu'un IDE ou un éditeur de texte devrait être en train d'écrire pour moi (i.e. manque de autocomplete ). Il est difficile de voir les gens qui cherchent le chemin complet d'un fichier dans Vim juste pour l'ouvrir et regarder les détails d'une méthode ou d'une classe dans VS Code ou Visual Studio, par exemple, un simple hit sur F12 devrait suffire à aller à la définition classe ou méthode, sans ambiguïté de fichier. Et Je ne parlez même pas de expérience de débogage , cela me blesse de voir les gens écrire binding.pry (pour les développeurs non-ruby, c'est un peu comme un mot-clé" débogueur " dans js) dans leur code juste pour le déboguer dans le terminal au lieu de simplement définir un point de rupture sur la ligne. La liste est plus longue que cela, mais je pense que c'est suffisant pour faire le point sur "tooling".

OOP expressiveness

dans certains langages dynamiques comme Python et Ruby, vous n'avez pas toutes les caractéristiques de la programmation orientée objet comme les interfaces et les les classes abstraites . Cela entraîne parfois des difficultés à rendre le code expressif et clair.

tests Unitaires

, Vous devez écrire beaucoup plus de tests unitaires pour remplacer ce que le compilateur peut faire pour vous.

typage Dynamique

vous devez utiliser duck typing si vous voulez faire certains sorte de vérification de type. Sans l'aide du compilateur que vous obtenez.

avantages des langues dynamiques dactylographiées

à l'abri de Typicité de l'Enfer

il y a toujours des compromis lorsqu'on choisit entre des langues dynamiques ou statiques. Un problème commun dans les langages statiquement typés comme C# et Java est que parfois le système de type peut rendre le code beaucoup inexpressif et trop verbeux. Certains développeurs a tendance à tomber dans le typification Générique hell . Mais tous les langages statiquement typés n'ont pas ce problème (F# est l'un d'eux - en raison de la forte inférence de type).

test

ne pas avoir de types statiques aide aussi dans certains cas quand, par exemple, vous ne voulez pas créer une interface juste pour injecter à votre classe et la rendre testable. Dans ces cas, l'interface n'aide pas à la lisibilité, en fait cela nuit à la lisibilité parce que vous devez créer un fichier muet (l'interface) qui ne représente rien d'autre que le désir de tester le code. Dans Ruby, vous pouvez faire cela de plusieurs façons sans avoir besoin de créer une interface, un exemple serait celui-ci:

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

Oui, avec cette approche nous avons cassé le architecture propre :(

pour conclure, je pense qu'il est possible d'écrire de bonnes applications DDD "enterprise" dans Ruby même si c'est difficile que dans les langages statiques. Mon projet actuel en est un exemple (lignes de code de 60k et toujours maintanable).

aussi le point mentionné par @GeorgeMaueris est important. Vous pouvez faire face à des problèmes dans la mise en œuvre de DDD dans les cadres qui vous impose la façon d'organiser votre code. Ici, nous choisissons d'utiliser Hanami au lieu de Rails à cause de cela, mais même Hanami est plus "opinionated" que nous aimerions. Je n'ai vraiment pas recommander quelqu'un trouver des "cadres" pour construire DDD. La conception / l'architecture change d'application en application et évolue également. Quand vous choisissez "DDD" frameworks parfois vous faites face à vous-même la lutte contre elle (faire des solutions de contournement ou des patches de singe).

alors, vous pouvez peut-être me demander pourquoi on a choisi ruby. Le point principal à utiliser Ruby ici était que presque 100% de l'équipe était composée par des développeurs Ruby et nous ne voulions pas dupliquer les difficultés: apprendre DDD + un nouveau langage de programmation. Plus une décision stratégique que purement technique. L'entreprise (une start-up) n'irait probablement pas aussi loin sans elle.

si la conception axée sur le domaine est un modèle de conception efficacement défini, pourquoi importe-t-il quel langage vous utilisez? Les conseils pour les philosophies de conception et autres devraient être largement agnostiques de langage. Ils sont de plus haut niveau que la langue, pour ainsi dire.

Python semble ne pas être trop populaire dans les entreprises jusqu'à présent par rapport à Java (mais je crois que le vent est dans cette direction. Un exemple est Django, qui a été créé par une société de presse). La plupart des programmeurs travaillant avec python sont probablement dans l'informatique scientifique ou dans des applications web. Ces deux domaines se rapportent aux sciences (informatiques), et non aux entreprises propres à un domaine, tandis que le DDD s'applique surtout aux entreprises propres à un domaine.

pour que je puisse soutiennent que c'est surtout une question d'héritage. C# et Java ont été ciblés sur les applications d'entreprise dès le début.