Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

C#実装から見るDDD(ドメイン駆動設計)

わんくま同盟勉強会@大阪#60でお話しさせて頂きました。
『C#実装から見るDDD(ドメイン駆動設計)』を多少手直しをして、再掲載しました。

  • Login to see the comments

C#実装から見るDDD(ドメイン駆動設計)

  1. 1. わんくま同盟 大阪勉強会 #60 C#実装から見る DDD(ドメイン駆動設計)Ver2.0 (ちょっと追記版) By @kawakawa
  2. 2. わんくま同盟 大阪勉強会 #60 はじめに みなさん、 DDDをご存じでしょうか?
  3. 3. わんくま同盟 大阪勉強会 #60 はじめに DDDとは、2011年に日本で出版され た「ドメイン駆動設計」の事です。
  4. 4. わんくま同盟 大阪勉強会 #60 はじめに DDDは書籍以外にも、ネット上に多数 の資料があり、目にされた方も多いか と思います。
  5. 5. わんくま同盟 大阪勉強会 #60 はじめに しかし、DDDは理屈の理解はできても、 実践するのは、難しいと思います。 まず、 顧客(ドメインエキスパート)が要ります。 仲間(開発チーム)が要ります。 プログラム知識が要ります。 ・・・・
  6. 6. わんくま同盟 大阪勉強会 #60 はじめに 本日は、DDDをプログラム実装という 観点から見てみることで、 DDDを知らない人には、興味のキッカケを、 DDDの実装をしらない人には、一例を提 示できればと思いました。 それではみなさん、よろしくお願いします。
  7. 7. わんくま同盟 大阪勉強会 #60 自己紹介 •かわべ たくや •Twitter:@kawakawa •大阪で働いています •I Love C#! •DDD勉強中!
  8. 8. わんくま同盟 大阪勉強会 #60 はじめに DDDを知らなくても、困らないような資料に したつもりですが、やっぱり知らないより、 知っていたほうが楽しいので、簡単にDDD を説明させて頂きます。
  9. 9. わんくま同盟 大阪勉強会 #60 DDD知らない方向け 「DDDとは?」 (独断と偏見で説明)
  10. 10. わんくま同盟 大阪勉強会 #60 DDDとは? •DDDとは、「Domain-Driven-Design」 •訳すと、「ドメイン駆動設計」 •よく目にする、●DD「●-Driven- Development」は、「●駆動“開発”」 であり、「●駆動“設計”」と異なります。
  11. 11. わんくま同盟 大阪勉強会 #60 DDDとは? •ドメインとは、「領域」の意味。 (顧客のお仕事=「業務領域」であり、これも 1つのドメインです) •ドメインから問題・関心ごとを抜き出し たのが「(ドメイン)モデル」。 •プログラマのお仕事は、この「モデル」 をプログラムで実装することです。
  12. 12. わんくま同盟 大阪勉強会 #60 DDDとは? •開発は、モデルを「分析」「設計」「実 装」のサイクルをグルグル回します。 (モデル駆動開発と呼ばれてます) •ドメイン駆動“設計”とは、そのグルグル 回すことを如何に継続させるか設計す ることです。
  13. 13. わんくま同盟 大阪勉強会 #60 DDDとは? •よくある勘違いとしては、DDD本自体 にモデルの答えは書いていません。 (モデリングの本ではないです) •モデリングを継続させる方法を考える 本です。 (魚をくれるのではなく、釣り方を教えてくれる本)
  14. 14. わんくま同盟 大阪勉強会 #60 DDDを行う意義とは?
  15. 15. わんくま同盟 大阪勉強会 #60 DDDの意義 私が思うDDDの意義は、 ・DDD本を読むまで 「動くアプリが正義!」 ・DDD本を読んだ後 「動き続けるアプリが正義!」 アプリへの認識が変わりました。 (※動く=顧客の問題を解決すると読み替えてもOK) (※動く≒顧客の問題を解決する)
  16. 16. わんくま同盟 大阪勉強会 #60 DDDの意義 動き続けるとは? •業務システムで考えると、納品は、開発の終わりで はありません。納品してからも開発は続きます。 (有償・無償は問わず) •顧客から要望は色々出てきます。 「より見やすい画面が欲しい」 「より操作しやすくして欲しい」 •顧客の業務形態に変化が生ずれば、仕様変更です。
  17. 17. わんくま同盟 大阪勉強会 #60 DDDの意義 つまり、動き続けるとは、 変化し続けるという事。 どこまで、仕様変更に追随できますか?
  18. 18. わんくま同盟 大阪勉強会 #60 DDDの意義 つまり、動き続けるとは、 変化し続けるという事。 どこまで、仕様変更に追随できますか? ※勿論、業務形態が根本的に変化したのなら、追随は 無理です。 (不動産屋が八百屋にジョブチェンジなど)
  19. 19. わんくま同盟 大阪勉強会 #60 DDDの意義 また、DDDに向かない場合もあります。 •ドメインが薄い (DDD行うほうが労力かかります) •アプリの使用期間が短い (一度きりで再利用しない場合。デモアプリなど)
  20. 20. わんくま同盟 大阪勉強会 #60 DDDの面白い所
  21. 21. わんくま同盟 大阪勉強会 #60 DDDの面白い所 DDDでは、モデルは実装されて初めて意味を成 すと考えられています。 つまり、図やUMLがモデルではなく、動くソフト ウェアまで含めて、モデルと考えられています。
  22. 22. わんくま同盟 大阪勉強会 #60 DDDの面白い所 プログラミングにおいて大抵は、実装上の制約 (性能や品質等々)により、設計図通りに実装出 来ないものですが、そう言った点も含めて、絵に かいた餅ではなく、動くモデルに注力しているの が、非常に現実的で、DDDは面白い思想だと思 いました。
  23. 23. わんくま同盟 大阪勉強会 #60 それでは、DDDの実装を見てみましょう
  24. 24. わんくま同盟 大阪勉強会 #60 とその前に・・・ いきなりですが、DDDは実装も大事ですが、実 装以外の項目も大事です。 •顧客(ドメインエキスパート)とのコミュニケーション •コンテンツマップ作成 •ユビキタス言語の発見 •開発チームづくり ・・・などなど。 残念ながら、実装だけ見ても“DDD”はできません…。
  25. 25. わんくま同盟 大阪勉強会 #60 DDD実装のサンプル元 •実装サンプルは、DDD本:著者エヴァンスも関わった「DDD Sample」使います。 •http://dddsample.sourceforge.net/ •DDD本にはそこまで詳しく触れられていなかった、DDDの実 装方法が詰まっていて大変参考になります。
  26. 26. わんくま同盟 大阪勉強会 #60 DDD実装のサンプル元 •注意点としては、DDDSampleはDDD本を読んでいる事を前 提されています。 •内容は、DDD本に何度も出てくる、貨物輸送プログラムです。 •HPにクラス設計図等の説明が無いので、本を読まないと、 「これは何クラス?」という状況に陥ります。
  27. 27. わんくま同盟 大阪勉強会 #60 実装例一覧 本日提示させて頂く、実装例は、 •レイヤ化アーキテクチャ (少しだけ責務のレイヤも) •値オブジェクト •エンティティ •リポジトリ
  28. 28. わんくま同盟 大阪勉強会 #60 レイヤ化アーキテクチャ
  29. 29. わんくま同盟 大阪勉強会 #60 レイヤ化アーキテクチャ ソフトウェアの世界には、レイヤという便利な考 え方があります。 有名なレイヤーといえば、MVC(Model View Controller)ですよね。 一番不安定なView層から、Model層を直接参 照・編集できないように切り離すことで、Model 層が安定します。 (MVCが指すModelとDDDのモデルは微妙に異なります)
  30. 30. わんくま同盟 大阪勉強会 #60 レイヤ化アーキテクチャ DDDのレイヤ化アーキテクチャも考え方は、同 じです。 (ドメイン)モデルを様々な事象から可能な限り 切り離すことで、モデルの安定化を目指します。
  31. 31. わんくま同盟 大阪勉強会 #60 レイヤ化アーキテクチャ DDD本「第4章ドメインを隔離する」から抜粋 基本的に、上のレイヤは下位レイヤーを参照できるが、 逆に下から上へは参照できない構造。
  32. 32. わんくま同盟 大阪勉強会 #60 レイヤ化アーキテクチャ ユーザインタフェース(またはプレ ゼンテーション層) •ユーザに情報を表示して、ユーザのコマン ドを解釈する責務を負う。 •外部アクタは人間のユーザではなく、別の コンピュータシステムのこともある。
  33. 33. わんくま同盟 大阪勉強会 #60 レイヤ化アーキテクチャ アプリケーション層 •ソフトウェアが行うことになっている仕事を 定義し、表現力豊かなドメインオブジェクト が問題を解決するように導く。 •このレイヤが責務を負う作業は、ビジネス にとって意味があるものか、あるいは他シ ステムのアプリケーション層と相互作用す るのに必要なものである。このレイヤは薄 く保たれる。
  34. 34. わんくま同盟 大阪勉強会 #60 レイヤ化アーキテクチャ ドメイン層(またはモデル層) •ビジネスの概念と、ビジネスが置かれた状 況に関する情報、およびビジネスルールを 表す責務を負う。 •ビジネスの状況を反映する状態はここで 制御され使用されるが、それを格納すると いう技術的な詳細は、インフラストラクチャ に委譲される。この層がビジネスソフトウェ アの核心である。
  35. 35. わんくま同盟 大阪勉強会 #60 レイヤ化アーキテクチャ インフラストラクチャ層 •上位のレイヤを支える一般的な技術的機 能を提供する。これには、アプリケーション のためのメッセージ送信、ドメインのため の永続化、ユーザインタフェースのための ウィジェット描画などがある。 •インフラストラクチャ層は、ここで示す4 層 間における相互作用のパターンも、アーキ テクチャフレームワークを通じてサポート することがある。 •個人的感想としては、ここは「ごった煮」層。
  36. 36. わんくま同盟 大阪勉強会 #60 レイヤ化アーキテクチャ それでは、早速実装をみてみましょう。
  37. 37. わんくま同盟 大阪勉強会 #60 レイヤ化アーキテクチャ 名前空間(フォルダ分け)などを使って、レイヤ分類を実装してい ました。 MVCもフォルダで分けたりす るので、同じですね。 DDDSampleでは他にもフォ ルダがありますが、ここでは 解りやすくする為、省いてい ます。
  38. 38. わんくま同盟 大阪勉強会 #60 レイヤ化アーキテクチャ レイヤ化自体は、フォルダ(名前空間)分けという 単純な方法でした。 しかし、MVC同様にどのオブジェクトはどのフォル ダに格納すべきか、よく考える必要があります。
  39. 39. わんくま同盟 大阪勉強会 #60 少しだけ、 責務のレイヤ
  40. 40. わんくま同盟 大阪勉強会 #60 責務のレイヤ •DDDSampleには直接記されていないのです が、DDDには、「責務のレイヤ」というレイヤ概 念があります。 •モデル層内部をより細かく分類して、不安定 箇所(仕様変更が多発する箇所)を切り離しま す。
  41. 41. わんくま同盟 大阪勉強会 #60 責務のレイヤ 第16章 大規模な構造「責務のレイヤ」より
  42. 42. わんくま同盟 大阪勉強会 #60 責務のレイヤ •責務のレイヤは、開発に非常に有効な手段と思いま す。 •しかし、責務のレイヤを実装するには、顧客(ドメイン エキスパート)の知識が必要となり、上流設計で行う 作業やスキルが必要となります。 ・業務知識の習得 ・業務の見える化 ・・・色々 やはり、一筋縄ではいかなそうです。
  43. 43. わんくま同盟 大阪勉強会 #60 値オブジェクト
  44. 44. わんくま同盟 大阪勉強会 #60 値オブジェクト •DDDでは、如何にモデルをシンプルに保つか が、大切な考えになります。 •オブジェクトに、責務以上の機能、余計なデー タを持たせない事に、注意を払います。
  45. 45. わんくま同盟 大阪勉強会 #60 値オブジェクト •値オブジェクトは、“属性情報”だけを持ちます。 •属性情報とは、「色」や「大きさ」など、 対象の性質を表したものです。
  46. 46. わんくま同盟 大阪勉強会 #60 値オブジェクト そして、値オブジェクトは次のルールが適応され ます。 •同一性(アイデンティティ)を持たない。 •不変(immutable)である。 (属性に変更が必要になった場合、属性を変更するのではなく、 新しい属性を持った値オブジェクトを作成する)
  47. 47. わんくま同盟 大阪勉強会 #60 値オブジェクト DDDSampleのLeg(行程)をサンプルにして、実装を みてます。 Legは船の貨物の「積み込む地点」と、「荷下ろし地点」 を保持します。 ※ 単純化の為、DDDSampleから改変(省略)しています
  48. 48. わんくま同盟 大阪勉強会 #60 値オブジェクト //値オブジェクト用インターフェース public interface IValueObject<T> { //属性が同じかチェック bool SameValueAs(T other); } 最初に、値オブジェクト用のインターフェースを用意。
  49. 49. わんくま同盟 大阪勉強会 #60 値オブジェクト //Leg(行程)の値オブジェクト実装 public class Leg : IValueObject<Leg> { public Location LoadLocation { get; private set; } //荷積み地点 private Location UnloadLocation { get; private set; } //荷下ろし地点 public Leg(Location loadLocation, Location unloadLocation) { this.LoadLocation = loadLocation; this.UnloadLocation = unloadLocation; } public bool SameValueAs(Leg other) { if (this.LoadLocation != other.LoadLocation) return false; if (this.UnloadLocation != other.UnloadLocation) return false; return true; } } ※ 解りやすくする為に、DDDSampleから改変しています。
  50. 50. わんくま同盟 大阪勉強会 #60 値オブジェクト •Leg(行程)サンプルの特徴は、属性として、 ・ LoadLocation(荷積み地点) ・ UnloadLocation(荷下ろし地点) を持ち、コンストラクタ以外に、属性を変更する 手段を持ちません。 •このLeg(行程)だけみると、値オブジェクトと 言っても、特別なことは無いように見えますね。
  51. 51. わんくま同盟 大阪勉強会 #60 値オブジェクト その2
  52. 52. わんくま同盟 大阪勉強会 #60 値オブジェクト •次は、Leg(行程)をリストとして保持する、Itinerary(運送スケジュール)オブジェクトを考えてみます。 •Itineraryは、Cargo(貨物)(後述するエンティティ)の Legをまとめたもので、Legリスト最初が出発点、最 後が到着点(目的地)となります。
  53. 53. わんくま同盟 大阪勉強会 #60 値オブジェクト このItinerary(運送スケジュール)を値オブジェク トと考えた場合、不変性をどう考えればよいで しょうか? リストとして保持しているLeg(行程)に、1つでも 変更が生じた場合、Cargo(貨物)は、Itinerary(運送スケジュール)を破棄して、都度、新しいイ ンスタンスを用意しないといけないのでしょう か?
  54. 54. わんくま同盟 大阪勉強会 #60 値オブジェクト DDD本の第16章『大規模な構造』の「責務のレイヤ」に、 次のように書かれています。 ソフトウェアにおけるこのレイヤは、計画作成と意思決 定に用いるツールをユーザに提供し、潜在的には一部 の意思決定を自動化できる (運送スケジュールが変更になった時、自動的に貨物 の経路を選択し直すなど) つまり、意思決定支援レイヤの責務として、変更対応 すればよいそうです。(うーん難しい!)
  55. 55. わんくま同盟 大阪勉強会 #60 値オブジェクト 個人的解釈としては、 •運送スケジュール変更というのは、Cargo(貨物)自 体の責務ではない。 •スケジュール変更は、より上位の意思に寄るもので ある。(例:貨物運送担当者など) •その為、 RoutingService(経路選択サービス)を用 意し、スケジュール変更に伴う実装的負担を引き受 けることで、各オブジェクト構造をシンプルに保てる (余計な仕事をさせなくて済む)
  56. 56. わんくま同盟 大阪勉強会 #60 値オブジェクト •まずは、Itinerary(運送スケジュール)の実装 をみてみましょう。
  57. 57. わんくま同盟 大阪勉強会 #60 値オブジェクト // Itinerary(運送スケジュール)オブジェクト public class Itinerary : IValueObject<Itinerary> { private List<Leg> legs = null; public Itinerary(List<Leg> legs) { this.legs = legs; } } ※ 解りやすくする為に、DDDSampleから改変しています。
  58. 58. わんくま同盟 大阪勉強会 #60 値オブジェクト Itinerary(運送スケジュール)は、単純にLeg(行 程)をリストで保持しているだけですね。 次は、Cargo(貨物)とRoutingService(経路選 択サービス)です。
  59. 59. わんくま同盟 大阪勉強会 #60 値オブジェクト // Cargo(貨物) (後ページのエンティティ時にも記載) public class Cargo:IEntity { ~省略~ //運送スケジュール private Itinerary itinerary; //運送スケジュール変更 public void AssignToRoute(Itinerary itinerary) { this.itinerary = itinerary; } } ※ 解りやすくする為に、DDDSampleから改変しています。
  60. 60. わんくま同盟 大阪勉強会 #60 値オブジェクト // Itinerary(運送スケジュール)を新しく作るサービスを用意 public class RoutingService { public List<Itinerary> fetchRoutesForSpecification(Cargo cargo) { //新しいltinerary(運送スケジュール)割り当て cargo.assignToRoute(toItinerary()); } //条件に従い、新しい運送スケジュール作成 private Itinerary toItinerary() { ~省略~ return new Itinerary(legs); } } ※ 解りやすくする為に、DDDSampleから改変しています。
  61. 61. わんくま同盟 大阪勉強会 #60 値オブジェクト DDDSampleにおける実際のRoutingService(経路選択サービス)はもっと複雑です。 ただ、DDD的意図を読み取ると、経路変更の仕 事を、経路情報を持つCargo(貨物)に行わせる のではなく、Serviceとして外部に出したことによ り、Carg(貨物)がシンプルに保たれている事に、 意義があるのと考えています。
  62. 62. わんくま同盟 大阪勉強会 #60 エンティティ
  63. 63. わんくま同盟 大阪勉強会 #60 エンティティ •エンティティは値オブジェクトと異なり、同一性 (アイデンティティ)を持ちます。 •同一性は、モデルのライフサイクル期間中保 たれます。 •同一性は、エンティティをDB格納して、取り出 した後でも、保たれます。 エンティティ モデルのライフライン DB エンティティ 同じアイデンティティ
  64. 64. わんくま同盟 大阪勉強会 #60 エンティティ •cargo(貨物)をサンプルに、エンティティの実 装を見てみます。 •cargo(貨物)は、TrackingId(追跡ID)をアイ デンティティとして、同一性を持ちます。 •TrackingId(追跡ID)は、作成時に割り当てら れた後、変更されることはありません。
  65. 65. わんくま同盟 大阪勉強会 #60 エンティティ // エンティティ用インターフェース interface IEntity<T> { //同一エンティティかチェック bool sameIdentityAs(T other); } •まずはエンティティ用のインターフェース
  66. 66. わんくま同盟 大阪勉強会 #60 エンティティ //cargo(貨物) public class Cargo:IEntity<Cargo> { private readonly TrackingId trackingId; public Cargo(TrackingId trackingId) { this.trackingId = trackingId; } public bool SameIdentityAs(Cargo other) { return other != null && trackingId.sameValueAs(other.trackingId); } } ※ 解りやすくする為に、DDDSampleから改変しています。
  67. 67. わんくま同盟 大阪勉強会 #60 エンティティ •アイデンティティであるtrackingId(追跡ID)を readonlyにすることで、設定後の不意な変更 を防止しています。 •それ以外は特段特徴のない、普通のクラスで すね。
  68. 68. わんくま同盟 大阪勉強会 #60 エンティティ •次に、そのアイデンティティとして使用されてい る TrackingId(追跡ID)の実装を見てみます。
  69. 69. わんくま同盟 大阪勉強会 #60 エンティティ // TrackingId(追跡ID) public sealed class TrackingId : IValueObject<TrackingId> { private readonly String id; public TrackingId(String id) { this.id = id; } public override bool Equals(object o) { if (this == o) return true; if (o == null) return false; TrackingId other = (TrackingId)o; return SameValueAs(other); } public bool SameValueAs(TrackingId other) { return other != null && this.id.Equals(other.id); } } ※ 解りやすくする為に、DDDSampleから改変しています。
  70. 70. わんくま同盟 大阪勉強会 #60 エンティティ •驚いた事に、 TrackingId(追跡ID)は値オブ ジェクトです。 •Cargo(貨物)は、エンティティですが、そのア イデンティティとして、値オブジェクトである TrackingId(追跡ID)を使用しています。
  71. 71. わんくま同盟 大阪勉強会 #60 エンティティ これらの事から、何が値オブジェクトで、エンティ ティなのか、深く考える必要があることが伺えま す。 (エンティティのアイデンティティも、普通ならエンティティになると 普通思うと思います) 個人的には、容易にオブジェクトをエンティティと しないという、強い意志を感じました。
  72. 72. わんくま同盟 大阪勉強会 #60 Factories と Repositories
  73. 73. わんくま同盟 大阪勉強会 #60 Factories と Repositories •エンティティの実装例で見た通り、同一性の確 保は、プログラムの実装に依存します。 (例では、追跡IDのユニーク性確保など) •このように、新しくオブジェクトをnew(インスタ ンス化)したいときに、特定条件(今回は追跡 ID採番)を実行したい事は多々あります。
  74. 74. わんくま同盟 大阪勉強会 #60 Factories と Repositories •そこで、オブジェクトの生成、並びにDBへの格 納・取り出しなど、オブジェクト化するのに必要 な処理をまとめたのが、「Factories(ファクト リ)」と「Repositories(リポジトリ)」です。
  75. 75. わんくま同盟 大阪勉強会 #60 Factories と Repositories •「Factories」がオブジェクト生成時に使用。 •「Repositories」は、DB格納や取り出しなど、 オブジェクトを使いまわす時に使用します。
  76. 76. わんくま同盟 大阪勉強会 #60 Factories と Repositories •cargo(貨物)を格納するCargoRepositoryの 実装例は次のようになります。
  77. 77. わんくま同盟 大阪勉強会 #60 Factories と Repositories //貨物リポジトリ interface ICargoRepository { //指定、追跡IDに該当するcargo取得 Cargo find(TrackingId trackingId); //全cargoを取得 List<Cargo> findAll(); //DBに格納します void store(Cargo cargo); //DBなどのシーケンスを使い、ユニークなIDを発番させます。 TrackingId nextTrackingId(); }
  78. 78. わんくま同盟 大阪勉強会 #60 Factories と Repositories •ICargoRepositoryインターフェースを実装す ることで、O/Rマッパで実装するとDBに結びつ けたり、ファイル操作で実装すると、Textファイ ルとして保存させたり、することができます。 •次ページはDBで実装した時の例です。
  79. 79. わんくま同盟 大阪勉強会 #60 Factories と Repositories //貨物リポジトリ(DB) public class CargoRepositoryDb { private DAO dao=null; //指定、追跡IDに該当するcargo取得 public Cargo find(TrackingId tid) { dao.createQuery("from Cargo where trackingId = :tid"); //SQL dao.setParameter("tid", tid); return dao.result(); } //全cargoを取得 public List<Cargo> findAll() { dao.createQuery("from Cargo "); //SQL return dao.result(); } (続く) ※ 解りやすくする為に、DDDSampleから改変しています。
  80. 80. わんくま同盟 大阪勉強会 #60 Factories と Repositories (続き) // DBに格納します public void store(Cargo cargo){ dao.saveOrUpdate(cargo); dao.createSQLQuery("delete from Leg where cargoId =null").executeUpdate(); } // ユニークなIDを発番 public TrackingId nextTrackingId() { var randomId= dao.GetRoundomUID(); return new TrackingId(randomId); } } ※ 解りやすくする為に、DDDSampleから改変しています。
  81. 81. わんくま同盟 大阪勉強会 #60 Factories と Repositories Factoriesの実装例は載せておりませんが、 Repositoriesとほぼ同じような実装内容になりま す。 そうなってくると、FactoriesとRepositoriesをま とめても良さそうに思いますよね?
  82. 82. わんくま同盟 大阪勉強会 #60 Factories と Repositories しかし、DDD本では、次の理由でFactoriesと Repositoriesの役割を分離させてます。 •Factoriesは、新しいオブジェクトを生成する責務。 •Repositoriesは、既存オブジェクトを再構成する責務。 •分離させることで、FactoriesをDB(永続)化する処 理から分離できる。
  83. 83. わんくま同盟 大阪勉強会 #60 まとめ
  84. 84. わんくま同盟 大阪勉強会 #60 まとめ 簡単な実装例だけでしたが、 •レイヤ化アーキテクチャ •値オブジェクト •エンティティ •Repositories DDDの中核をなす、実装例を見て頂きました。
  85. 85. わんくま同盟 大阪勉強会 #60 まとめ 他にもDDDSampleでは、 •集約(Aggregate) •ドメインイベント •Service •仕様(SPECIFICATION) などの実装例が紹介をされています。 (しかし、これらはDDDを知らないと、判りづらいかもしれませ ん)
  86. 86. わんくま同盟 大阪勉強会 #60 書籍紹介 次に、DDD実装で参考になる書籍を簡単に紹介させて いただきたいと思います。
  87. 87. わんくま同盟 大阪勉強会 #60 書籍紹介 ドメイン駆動 ■amazon http://www.amazon.co.jp/dp/4798116173 ■書籍紹介 C#を使った、ドメイン駆動設計をパターンを使って 実装していく実践本です。 まさに、C#er向けの一冊。 C#2.0と若干古いのですが、サンプルソースは参 考になります。 SQLServerと如何に連携させるか、 テスト駆動開発でいかに進めるかなど、 てんこ盛りな内容です。(少々詰め込み過ぎ?)
  88. 88. わんくま同盟 大阪勉強会 #60 書籍紹介 Implementing Domain-Driven Design ■amazon http://amzn.com/0321834577 ■書籍紹介 英語本ですが、IDDDというキーワードでよく見かける、 DDD実践本です。 DDD本の後に出版された、如何にDDDを実践してい くかを主眼に書かれている本で、DDD本には収録さ れていなかったドメインイベントも記載されているよう です。 DDD本に劣らない分厚さを誇ります(汗。 私は当然、英語苦手なので未読です(汗汗 IDDDのワークショップを世界的に行うコミュニティがあ るようです。(http://idddworkshop.com/)
  89. 89. わんくま同盟 大阪勉強会 #60 まとめ 最初にも書かさせて頂きましたが、DDDにお ける実装が占める役割は、ほんの一部です。 実装に至るまでの過程がもの凄く重要だと思い ます。 また、実装例として挙げたものより、状況に よって、より適切な実装方法は、数多くあると思 います。
  90. 90. わんくま同盟 大阪勉強会 #60 まとめ 今回は、実装という方面からDDDを眺めてみ ましたが、DDDを知らなかった方に、少しでも興 味を持って頂けたのなら幸です。 DDDの実装については、私も勉強中です。 もし気になる点などありましたら、是非お声かけ 下さい。<(_ _)>ペコリ
  91. 91. わんくま同盟 大阪勉強会 #60 まとめ 以上、ご清聴ありがとうございました。

×