6年後、これにはメジャーアップデートが必要です。
簡単な答えはイエスです。しかし、複雑な答えはノーです。
いいえ、SOAは貧血を必要としません。しかし同時に、エンタープライズシステムはSOAを使用して作成する必要はありません。同様に、アーキテクチャはどのコードにもまったく必要ありません。悪夢になりますが、必要に応じて、すべての機能を1つのモジュールにパッケージ化できます。
簡単に言えば、OOは元々、前任者との違いによって定義されていました。より具体的には、C ++はCとの違いによって定義されました。しかし、OOの定義は変更されました。現在、多数のOO原則があります。
免責事項：これらの原則の多くは、OOの前に部分的または全体的に作成され、OO革命中に単に主張または更新されました。また、OOはLONG-Before C ++で使用されていることを認識していますが、それでも私のステートメントは変わりません。
カプセル化、継承、ポリモーフィズム、関心の分離、永続性の無視、高凝集度/低結合度、S、O、L、I、Dなど。
それだけでなく、これらの原則に従いながらDDDやTDDに従う場合は、ほとんど設計する必要はありません。これらの原則に従うだけで、当然、貧血ドメインモデルを使用するサービス指向アーキテクチャになります。
考えてみてください。Save()、、SendMessage()およびPayEmployee()...を含むEmployeeクラスがある場合、現在のオブジェクト指向原則の非常に多くのルールに違反しています。
特定の責任を分析して、さまざまなサービス、リポジトリ、コマンド、工場などに引き出す場合...あなたは助けることはできませんが、空の従業員クラスを持っています...ある種。
なんか？
正直なところ、値オブジェクトの概念を念頭に置く必要があります。OOの定義が進化しただけでなく、「貧血」の定義も進化しました。Employeeクラスは確かに空であってはなりません。たくさんの「ビジネスロジック」を含めることができます。
Employeeクラスには次のものがあります。
- パラメーターが検証されるパラメーター化されたコンストラクター
- フィールドを計算する読み取り専用プロパティ
- Employee.ToString（）、Employee.TryParse（）、および同様のオブジェクトメソッド
- おそらく他の人、従業員に固有
本質的に、従業員はまだ貧血です。ドメインモデルにアルゴリズムやコードフローロジックが存在することは決してありません。しかし、ビジネスロジックは1種類だけではありません。
Martin Fowlerが10年以上前に貧血ドメインモデルがアンチパターンであると言ったとき、それはすでにますます実行可能になりつつありました。彼の推論は2つあり、どちらも古いニュースです。
彼の最初の折り目は、OOの防御的な定義は、古い手続き型のスタイルとは対照的に、コードとデータが結婚している、つまり「データを組み合わせて処理する」ことでした。残念ながら、これは悪いコードにのみ当てはまります。継承とポリモーフィズムに従うと、関数がクラスに実際に存在するわけではないことがわかります。それらはポインタに存在するため、継承するクラスはそれらをオーバーライドして移動できます。しかし...彼らは読みやすさを向上させるためにコードに住んでいますか？彼らは確かにすべきではありません！これらは、インターフェイスと抽象化で定義し、クラスでのみ実装する必要があります。マーティン、申し訳ありませんが、コードとデータの組み合わせが20年前のOOの大きな元々のセールスポイントであったことは正しかったのですが、今ではそれほど問題ではありません。
彼の2つ目の特徴は、SOAが正しく行われていないとして失格となることであり、今日のN層アーキテクチャと非常によく似た説明を示しています。確かに、これは新しいテクノロジーではないことはわかっていますが、定義は何年にもわたって変更されています。
マーティン・ファウラーだけでなく、彼がすぐに彼の記事を引用した後、SOA自体がアンチパターンであると言った後の多くの人々は、貧血モデルを必要としたため、ファウラーはアンチパターンであると言います。
だから私たちはこれに取り掛かっています...
貧血ドメインモデルは、人々が信じているほど貧血ではありません。そしてSOAが必要であり、それを割り引くことはできません。残念ながら、これは単に物事がそうである方法です。
なぜSOAが必要なのですか？-これは説明が多すぎます。しかし、長い話-短い：90年代のドメインでは、ソフトウェアはPCとサーバーで実行されていました...そしてハードウェアはそれらのモノリスに「プラグイン」されていました。最近、私たちは文字通り何兆もの「コンピューター」を身の回りに持っています。煙探知器、冷蔵庫、時計、電話...最近のコンピューターは物事に接続されています。したがって、すべてのアイデア、部門、懸念事項、およびオブジェクトは、独自の小さなドメインです。それらを独自の小さなサービス、さらにはサブサービスに書き込むために、SOAが必要です。
したがって、アプリケーションは（サービスをアプリケーションに接続する代わりに）サービスに接続するようになりました。SOAを作成するには、SOLIDや関心の分離などのOOの現在のルールに従うだけです。そしてそうするとき、私たちは自然に貧血ドメインモデルに到達します...ちょっと。
したがって、SOAには貧血ドメインモデルは必要ありません。これらは、現在の原則と基準に従った自然な結果です。