ドメイン駆動設計がC＃やJavaなどの静的言語でのみ人気があるように見えるのはなぜですか？
ドメイン駆動設計は、私の選択したアーキテクチャになりました。 ASP.netフレームワーク内でDDDの原則を適用するための書籍やチュートリアルを豊富に見つけることができました。これは主に、Java開発者がしばらくの間やってきたことに触発されているようです。
私の個人的なプロジェクトでは、静的型付けを放棄するのは難しいと感じていますが、Pythonに傾倒し始めています。動的型を使用して、DDDを適用するのに多くの助けを見つけたいと思っていました。言語。Python＆DDDについては何もありません。それはなぜですか？明らかにDDDはPythonに非常にうまく適用できます。人々はPythonでそれほど大きなプロジェクトを引き受けませんか？ ？または、動的型付けを考えると、PythonでDDDを適用する方が簡単なので、必要な学習の量が減りますか？
おそらく私の質問は、Pythonの経験が不足していることが原因です。あなたが私のために持っているかもしれないどんなアドバイスもありがたいです。
他の場所、特に関数型言語では間違いなく人気があると思います。ただし、Big Blue Bookに関連する特定のパターンは、動的言語には適用できず、Rails）のようなフレームワークは、制限されたコンテキストのアイデアから人々を遠ざける傾向があります。
ただし、ユビキタス言語であるDDDの真の推進力は、動的言語では確かに普及しています。 Rubyistsは特に、ドメイン固有言語を構築することに大きな喜びを感じています。キュウリの機能がどのように見えるかを考えてみてください。それはDDDです。
DDDはまったく新しいアイデアではなく、C＃やJavaの人たちから好評を得た方法で再パッケージ化されただけです。これらの同じアイデアは、さまざまなバナーの下で他の場所にあります。
この質問はかなり長い間私を悩ませているので、私はこのトピックに関するすべての貴重なデータを収集することにしました。最後に私は このgithubリポジトリ になります。
いくつかのコード例もあります：
1） Djangoについて
2） フラスコ上
3） Rubyの場合
そして、さらにいくつか。しかし、間違いなく十分ではありません。
動的言語で優れたDDDプロジェクトを作成することは完全に可能だと思いますが、静的言語よりも保守が困難です。どうして？
ツーリング
静的型付き言語では、通常、ツールの方が強力です。そのため、プレーンなTypeScriptではなくJSを使用している人もいます。これは、リファクタリングを簡単にすることでコードをスケーリングするのに役立つためです。リファクタリングは、DDDコードを保守するときに常に存在するものです。これは、ビジネスが時々変化し、モデルに関する知識が毎日進化するためです。この知識を使用すると、コードも進化する必要があります。私の経験のほとんどはC＃でのものであり、それを使用して多くのDDDプロジェクトを構築しました。現在、私はRubyで書かれたDDDプロジェクトで作業していますが、私が最も見逃していることの1つは、強力なIDEがないことです。RubyまたはPython人々はIDEではなくテキストエディタを使用して作業することに慣れています。IDEまたはテキストエディタが書くべきものを書いている人々を見るのは私には難しいです私（つまり、autocompleteの欠如）。Vimでファイルを開いて詳細を確認するためだけにファイルのフルパスを検索している人を見るのは難しいです。メソッドまたはクラス-VSCodeまたはVisualStudioでは、たとえば、F12を1回ヒットするだけで、定義に移動できますクラスまたはメソッド、ファイルのあいまいさなし。そしてデバッグ経験についても話しませんでした。人々がbinding.pryを書いているのを見るのは私を傷つけます。 （Ruby以外の開発者にとっては、jsの「debugger」キーワードのようなものです）コードでは、行にブレークポイントを設定するのではなく、ターミナルでデバッグするだけです。リストはこれよりも大きいですが、私は「ツーリング」についてのポイントを作るのに十分です。
OOPの表現力
PythonやRubyのようないくつかの動的言語では、インターフェイスや 抽象のようなすべてのOOP機能を持っているわけではありませんクラス 。それは時々コードを表現的で明確にするのにいくつかの困難をもたらします。
ユニットテスト
コンパイラーが実行できることを置き換えるには、さらに多くの単体テストを作成する必要があります。
動的型付け
ある種のタイプチェックを行う場合は、 ダックタイピング を使用する必要があります。あなたが得るコンパイラからの助けはありません。
動的型付き言語の利点
類型化地獄から安全
OOP動的言語と静的言語のどちらかを選択する場合は常にトレードオフがあります。C＃やJava）のような静的に型付けされた言語でよくある問題の1つは、型システムがコードは非常に表現力がなく、冗長すぎます。一部の開発者は ジェネリック型の類型化地獄に陥る傾向があります 。しかし、すべての静的型付け言語にこの問題があるわけではありません（F＃はその1つです-強い型推論のため）。
テスト
静的型がないことは、たとえば、クラスに挿入してテスト可能にするためだけにインターフェースを作成したくない場合にも役立ちます。このような場合、インターフェイスは読みやすさを向上させません。実際、コードをテストするという欲求以外のものを表さないダムファイル（インターフェイス）を作成する必要があるため、読みやすさが損なわれます。 Rubyでは、インターフェイスを作成せずにいくつかの方法でそれを行うことができます。1つの例は次のとおりです。
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
はい、このアプローチでは、クラスが具体的な「インフラ」実装を知っているため、 クリーンなアーキテクチャ を壊しました。しかし、それは依存性注入で解決できる問題です（Rubyこれらのフレームワークは常にクリーンなアーキテクチャを壊したか、誰かがそれを使いたくないほど醜いです、私たちのプロジェクトでは私たち自身がしましたプロジェクトの起動時に依存関係を手動でインスタンス化することによるDIコンテナー
結論
結論として、静的言語よりも難しい場合でも、Ruby）で優れた「エンタープライズ」DDDアプリケーションを作成することは可能だと思います。私の現在のプロジェクトはその一例です（60k行のコードそしてまだ維持可能）。
@GeorgeMauerisが言及した点も重要です。コードを整理する方法を課すフレームワークにDDDを実装する際に問題に直面する可能性があります。ここでは、Railsの代わりに 花見 を使用することを選択しますが、花見でさえ私たちが望むより「意見」があります。私は本当に誰にも「」を見つけることをお勧めしません。 DDDを構築するためのフレームワーク」。設計/アーキテクチャはアプリケーションごとに変化し、進化します。「DDD」フレームワークを選択すると、それと戦うことに直面することがあります（回避策やモンキーパッチを実行します）。
だから、なぜ私たちがRubyを選ぶのか、私に尋ねることができます。Rubyここで使用する主なポイントは、チームのほぼ100％がRuby開発者と私たちは困難を再現したくありませんでした：DDD +新しいプログラミング言語を学ぶ。純粋に技術的な決定よりも戦略的です。会社（スタートアップ）はおそらくそうはなりません。それなしではるかに。
2018年編集：
DDDの側面に依存するプロジェクトではRubyおよびPythonから諦めます。現在、Kotlinを使用しており、非常に満足しています。主なメリットは次のとおりです。ここにリストされています：
- 最高のIDE IntelliJでのサポート。これにより、リファクタリングが大幅に高速化され、コンパイル時にエラーが発生し、コンパイラーが実行できることのテストを作成する手間が省けます。
- 依存性注入、ORM、 関数型プログラミングのための優れた人気のあるフレームワーク
- 言語自体のもう1つの利点（nullの安全性、データクラスなど）
2019年編集：
RubyからKotlinへの移行について、一連の投稿を作成しました。 ここ で確認できます。
Pythonは、Javaと比較すると、これまで企業ではあまり人気がなかったようです（ただし、風はその方向に向かっていると思います。例として、新聞社によって作成されたDjangoがあります）。ほとんどのプログラマー。 pythonは、科学計算またはWebアプリケーションのいずれかに関連している可能性があります。これらの分野はどちらも、ドメイン固有のビジネスではなく（コンピューター）科学に関連していますが、DDDはドメイン固有のビジネスに最も適しています。 。
ですから、それは主に遺産の問題であると私は主張します。 C＃とJavaは、最初からエンタープライズアプリケーションを対象としていました。
TDDやデザインパターンなどのデザイン/コーディング手法に関するほとんどの本は、JavaまたはC＃で書かれています。これは、現在、最小公分母言語であり、ユーザーベースが最も広いか、少なくとも最大であるためです。言語を読んで理解できる人々の基盤。これは主にマーケティング上の理由で行われ、最大の人口統計にアピールします。
それは、テクニックが他の言語に適用できない、または使用されないという意味ではありません。私がDDDについて知っていることから、ほとんどの原則は言語に依存せず、AFAICRの元のDDDブックには、コードサンプルがほとんど含まれていませんでした（ただし、読んでから数年なので、誤解される可能性があります）。
ドメイン駆動設計が効果的に定義されたデザインパターンである場合、使用している言語が重要なのはなぜですか？デザイン哲学などのアドバイスは、主に言語に依存しないものでなければなりません。彼らは、いわば言語よりも高いレベルです。