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.

2016-11-11 UMTP モデリングフォーラム2016 DDD実践のコツとazureによるモデル実装

806 views

Published on

ドメイン駆動設計(DDD:Domain Driven Design)の実践した結果についてと、Azure上でDDD+分散アプリケーションを構築する場合のご紹介です。
UMTPモデリングフォーラムで登壇した時の資料です。
当日は残念ながらアーキテクチャとActorパターンについてはご紹介する時間がありませんでした。

Published in: Software
  • Be the first to comment

2016-11-11 UMTP モデリングフォーラム2016 DDD実践のコツとazureによるモデル実装

  1. 1. Modeling Forum 2016 2016年11月11日 株式会社ネクストスケープ 上坂 貴志 DDD実践のコツと Microsoft Azureによる モデル実装のご紹介 ALLPPT.com _ Free PowerPoint Templates, Diagrams and Charts
  2. 2. 自己紹介 会社 株式会社ネクストスケープ 名前、年齢 上坂貴志(うえさかたかし)44歳 Twitter:@takashiuesaka 好き・興味 Azure( Microsoft MVP for Microsoft Azure) Scrum( 認定スクラムマスター) DDD、ソフトウェアアーキテクチャ、機械学習 講演活動 2016年  QCon Tokyo 2016 DDD実践報告  de:code 2016 DDD & Azure Service Fabric 登壇  NS Study No.6 Azure IoTHub紹介 登壇  アプレッソ 最新IT事例セミナー Azure Machine Learning セミナー登壇  SANSAN DDD勉強会発表 2015年  FEST2015 (Channel9で動画公開)  Developers Summit 2015  QCon Tokyo 2015  他 執筆活動 人工知能アプリケーション総覧 寄稿(日経BP社)
  3. 3. 会社紹介 株式会社ネクストスケープ 2002年設立、今は西新宿にオフィスがあります 豆蔵ホールディングスのグループ会社です システムインテグレーターの会社です
  4. 4. 会社紹介 株式会社ネクストスケープ Microsoft Azureを使ったシステム開発に自信あります 動画・音楽配信のソリューションよくやってます ECサイト、DAM、デジタルマーケティングも多いです
  5. 5. 会社紹介 株式会社ネクストスケープ DDDやろうぜ Scrumやろうぜ SESやっていないので、自社で開発100%ですよ 只今、エンジニア積極採用中です
  6. 6. なぜDDDか
  7. 7. なぜDDDか DDDとは  2011年、DDDの著者 Eric Evans氏が来日。QCon Tokyo 2011にて講演 2011年発売2003年発売 2015年発売2008年発売
  8. 8. なぜDDDか システム開発の問題点とは何か ユーザーからの不満 開発側が自分たちのビジネスを良く知らない  解決したい課題・達成したい事がちゃんと伝わっているかわからない  そもそも伝えるのに時間がかかり過ぎる  納品されてから伝わってなかったことに気が付くなんて最悪 Section 1/5 total 1/13
  9. 9. なぜDDDか システム開発の問題点とは何か システム開発側視点 ユーザーの話は目的と手段が混在していて整理が大変  ユーザーからの話は解決したい課題や、達成したいことそのものとは限らな い。背景まで説明してくれないことも多い。そのため、ユーザーからヒアリ ングした内容をどう達成するか、に終始してしまいがち  要求を整理するためには、ユーザーのビジネスや業界、会社、ユーザーの部 門の状態に精通するのが近道なのはわかっているが、これらに対して短時間 で精通するのは無理 Section 2/5 total 2/13
  10. 10. なぜDDDか 原因はなに? ユーザーとシステム開発側、双方が持つ暗黙知が悪さをする  ユーザーからすると、一所懸命説明してるし、開発者側の反応を見ていると 全て(業界、ビジネス、自社の状態、部門の都合など)わかっているかのよ うに見える  開発者は自分のもつ一般常識(業界、ビジネス)に当てはめ、わかったつも りで話を進めてしまう  どうしてもズレが発生してしまう  さらにいうと、ユーザーは本当は何をしたいのかわかっていないことも Section 3/5 total 3/13
  11. 11. DDDとは DDDが提案する複雑さに対する解 解決したい事・達成したい事(ドメイン)に対して、ユーザーと開発者との 間で共通の言葉を定義していく その言葉が直感的ではないなら、両者合意の上で新しい言葉(直感的なも の)を策定していく ユビキタス言語はモデル名やメソッド名、パッケージ名などあらゆる箇所で 実際に使用する(ただの用語辞書扱いではなく) ユビキタス言語 Section 4/5 total 4/13
  12. 12. DDDとは DDDが提案する複雑さに対する解 解決したい課題、達成したいこと(ドメイン)をモデルとして表現すること で、目的に向かっているのかをユーザー・開発者双方から確認することがで きる ただし、分析用のモデルと実装用のモデルと2つ用意しないで、1つのモデ ルで表現する(フェーズ間の変換をしない) モデル駆動による設計 Section 5/5 total 5/13
  13. 13. DDDとは ユビキタス言語を定義しながらモデリングをしていくと、言葉の意味が曖昧 となってしまって混乱することがよくある。原因は、  違うものを同じ言葉で表している  同じものを違う言葉で表している から。これは本来コンテキストが異なるのに、1つのコンテキストですべて を語ろうとしているために起こる。 コンテキストを分割して、それぞれの言葉の意味を正確に確定していく。 (コンテキストは複数になって、コンテキストそれぞれでモデリングする) DDDが提案する複雑さに対する解 境界づけられたコンテキスト
  14. 14. DDDとは DDDが提案する複雑さに対する解 • ドメインを理解する人(要件定義) • モデリングをする人(基本設計) • 実装する人(詳細設計~実装~テスト) これが全てバラバラの人が実施するからズレが生じやすくなる。 メンバー全員がドメインを理解し、モデリングすることが大事。つまりプロ グラマーであってもモデリングを行い、ドメインの理解は必須となる。 実践的モデラー
  15. 15. DDD実践報告
  16. 16. DDD実践報告 影も形も残らなかった 当時の状況  設計フェーズ以降から開発側だけで勝手にDDDを始めた  ソフトウェアアーキテクチャとモデリングの導入だけでも 恩恵を受けることができると思った 結果は大失敗  最初はうまくいきそうだったが、あっという間に一般的な3層レイヤーと同じに なった 当時の 振り返り  メンバーにDDDを教育しないで始めてしまったため、メンバーがモデリング→実 装をイメージできなかった  モデリングだけなら教育なしでもある程度は形になるかと思ったが、全くモデリ ングできなかった  途中参画メンバーが「ドメインサービス」を多用。貧血ドメインになってしまっ た。このメンバーはDDDに興味がなかった Section 1/7 total 6/13
  17. 17. DDD実践報告 モデリング・実装がうまくいかない 当時の状況  メンバーにはDDDに興味があり、かつDDDを教育した人をアサイン  ユーザーにもDDDを説明し、ユビキタス言語の作成協力に快諾いただく  モデリングをしつつ、実装してみる流れでやってみた 結果は大失敗  モデリングは初期しか行われなかった。あっという間に実装だけになった 当時の 振り返り  ER図から脱却できなかった。モデリングではなく、ER図になっていた  集約のついての知識が足りないためにモデリング時に集約を意識しなかった  モデリングした結果と実装がどうしてもうまくMappingしなかった  RepositoryやFactoryをどこに実装するのかなどドメイン以外のついて議論になってし まってスタートから躓いたことで焦ってしまったため、モデリングがさらに疎かに  Specification, 副作用のない関数、閉じた操作などの「しなやかな設計」への意 識がないなど、モデリングの知識・技量が足りなかった Section 2/7 total 7/13
  18. 18. DDD実践報告 失敗と改善を繰り返した後の振り返り 原因は色々あるけど、理由は恐らく「不安」  ベテランであればあるほど、今までのやり方との差異が 気になって仕方がない 開発プロセスへの不安 要件をヒアリングしながらモデリングは理解できるけど・・・  その結果は納品物なの?  モデリングは基本設計まで踏み込んでいるの?  要件定義にかかるコストとスケジュールは今まで通りでいいの?  要件定義の次は何するの?  実装フェーズのコストは増えるのでは?どれぐらい増えるのかを どうやって見積もるの? オブジェクト指向を採 用することの不安  過去にオブジェクト指向を勉強したけど、全く実システムに関係な かった、という人が多い。無駄な作業、という認識 Section 3/7 total 8/13
  19. 19. DDD実践報告  という認識のベテランがものすごく多い!  この認識を変えてもらわないモデリングできない・・・ 失敗と改善を繰り返した後の振り返り でも、実は最大の原因はモデリングに対するベテランの驕りなのではな いか、とも。 オブジェクト指向ができる=モデリングができる モデリング=ER図と大差ない Section 4/7 total 9/13
  20. 20. DDD実践報告 その後、DDD導入・実践に成功 開発プロセスの 不安への対処  ユーザーにしっかりとユビキタス言語の共同作成について認識しても らう  開発プロセスの最初からモデリング  ベテランに対してDDDをしっかり教育  特に開発プロセスについて疑問がないように以下を伝える  モデリング結果は納品物にする  モデリングは基本設計まで踏み込んでいる、とする  要件定義にかかるコスト・スケジュールの増加を事前にユーザー に理解をしてもらう  要件定義の次のフェーズは実装。ソフトウェアアーキテクチャテ ンプレートの修正、モデリング結果の実装、UI実装。DB設計は ある程度要件が固まってきてから行う Section 5/7 total 10/13
  21. 21. DDD実践報告 その後、DDD導入・実践に成功 実装上の不安への対処  しっかりとしたソフトウェアアーキテクチャとサンプルを用意  モデリング結果が実装になることを示す  モデル以外のレイヤーの具体例を示す  モデルをドメインレイヤーに閉じ込めることで、変更に対してもうま く対処できるように Section 6/7 total 11/13
  22. 22. DDD実践報告 すべてうまくはいかなかった •複雑なドメインをモデルとして抽象化→実装はそれなりにうまくいった •モデリングに興味のない人は最後まで興味がない •時間がなくなってくると、Mappingの実装が面倒になって次第にSQLやRepositryにビジネス ロジックが混入し始める 【まとめ】成功・・・なの? でも、しばらく経ってから再度ソースを見直してみると、あちこちモデリングが おかしいな、というところに気が付くように。 わからないながらも、モデリングと勉強を繰り返すと技量はあがるらしい。モデ リングもコードも良くなっていくことを実感 ※でも、DDDにはブレイクスルーが必要だな、とも。 Section 7/7 total 12/13
  23. 23. ~これから始めるDDD~ モデリング時のポイント
  24. 24. モデリング時のポイント 1.静的構造を表すモデルにしないこと(そこで止まらないこと) 静的構造だけを表したモデルを作っても、実装には全く意味がなかった。意味がないどころか、貧 血ドメインまっしぐらになってしまうため、害悪そのものだった。 ユースケースを常に意識すること、どのモデルがどのビジネスロジックを持つべきなのかを考え続 けることで無意味な静的構造モデルから、実装できるモデルに一歩近づく。 車 タイヤ 車 タイヤ 車輪 位置 1 4 4 * 期間 走行距離 rotate() 静的構造だけのモデリング ビジネスロジックを意識したモデリング 例:タイヤのローテーションを行う 走行距離 車輪 4 ※位置はタイヤがどの車輪にどの期間ついていたのかを 表す履歴となり、次にどこに位置にローテーションする かを判断する条件となる 位置
  25. 25. モデリング時のポイント 2.1つのモデルによる中央集権にならないようにする DAM(Digital Asset Management)のシステムの場合 コンテンツ メタ カテゴリ グループ ファイル パス サムネイ ルパス 作成者 作成者Id パスワード 氏名 所属 登録日公開日公開終了日 コンテンツ コンテンツ 作成者 作成者Id メタ メタId 中央集権モデル 集約でパッケージングして、Idで連携 集約を強く意識しないと、すぐに中央に王様を配置したモデルとなってしまう。 これを分割する時のコツは、モデルを直接参照しあうのではなく、Id越しに参照する。
  26. 26. モデリング時のポイント 3.ビジネスロジックの置き場所に困った時は「仕様パターン」! 例えば、勤怠管理システムにて打刻日時から勤務日を判定する場合 ・勤務日は実際の打刻日時とは異なる場合がある。 ・例えば、11/10の24時を5分回った場合、勤務日は11/11ではなく、11/10のままである。 12 6 39 1 2 11 10 7 8 4 5 ・つまり、実際の日付と、勤務日の日時はズレることがある。 ・ちなみにネクストスケープではAM4:59までは勤務日は前日扱いとなる。(!) ・これをどうやってモデリングする? 12 6 39 1 2 11 10 7 8 4 5 打刻時刻:11/10 23:55 勤務日 :11/10 打刻時刻:11/11 0:05 勤務日 :11/10 打刻時刻とずれる
  27. 27. モデリング時のポイント ・打刻日時が勤務日を返すプロパティを実装するモデリング 3.ビジネスロジックの置き場所に困った時は「仕様パターン」! 打刻日時 勤務日 Get勤務日() new 実装例 ・var touch = new 打刻日時(DateTime stampedDateTime); ・勤務日 workday = touch.Get勤務日(); この場合、何時を基準に勤務日が何日なのか判定ロジックを打刻日時が持つことになる。 でもこれはなんか変。 ・打刻日時が勤務日の生成に関する条件を知っているの? ・そもそも打刻日時が勤務日を生成する責務を負うの?単一責任の原則(SRP)に反していない? (勤務日判定条件が変わったら、打刻日時を変更するの?打刻日時なのに?)
  28. 28. モデリング時のポイント ・勤務日が打刻日時を受け取るモデリング 3.ビジネスロジックの置き場所に困った時は「仕様パターン」! 勤務日 勤務日(打刻日時 stampedDateTime) 実装例 ・var workday = new 勤務日(new 打刻日時(DateTime stampedDateTime)); ちょっと良さそう!でもよく考えると、勤務日に対して打刻日時は複数存在することに気がつく。 つまり勤務日は毎回生成するのではなく、既に存在している場合はそれをRepositoryより復元して、 打刻日時を追加することになる(Addメソッドを持つ)はず。 (※集約のルートエンティティとなる可能性大) 勤務日 打刻日時* 勤務日 Add(打刻日時) 打刻日時 打刻日時*
  29. 29. モデリング時のポイント ・勤務日が打刻日時を受け取るモデリング 3.ビジネスロジックの置き場所に困った時は「仕様パターン」! つまり打刻があった場合、まず既に存在している勤務日をRepositoryに問い合わせて、もし存在し たら復元した勤務日に打刻日時を追加することになる。 ということは、Repositoryに打刻日時を渡して、勤務日を取得してきてもらわなくてはならない。 あれ?Repositoryが打刻日時から勤務日を判定するロジックを持つことになる? それはおかしい・・・。どうしたらいいんだろうか・・・ 勤務日勤務日Repository FindBy打刻日時(打刻日時) 復元 Add(打刻日時) 打刻日時*
  30. 30. モデリング時のポイント ・勤務日仕様というValueObjectをモデルに追加する。このモデルに勤務日と打刻日時の整合性 チェックの責務を担当させる。 ・勤務日仕様には isSatisfy(勤務日 workDay, 打刻日時 touch)メソッドを持たせる。このメソッド が整合性チェックの結果をboolで返却する。 3.ビジネスロジックの置き場所に困った時は「仕様パターン」! 勤務日仕様 勤務日仕様(TimeSpan) IsSatisfy(勤務日, 打刻日時) 勤務日勤務日Repository FindBy打刻日時 (打刻日時,勤務日仕様) 復元 Add(打刻日時) 打刻日時* Factory Factory (打刻日時,勤務日仕様) Create() 生成
  31. 31. モデリング時のポイント 生成の実装例 var touch = new 打刻日時(stampedDateTime); var spec = new 勤務日仕様(standardTime); // Factoryクラスは、勤務日クラス内部に用意する var workday = new 勤務日.Factory(touch, spec).Create(); Repositoryの実装例 ・var workday = new 勤務日Repository().Get勤務日by打刻日時(touch, spec); 3.ビジネスロジックの置き場所に困った時は「仕様パターン」! 勤務日仕様 勤務日仕様(TimeSpan) IsSatisfy(勤務日, 打刻日時) 勤務日勤務日Repository FindBy打刻日時 (打刻日時,勤務日仕様) 復元 Add(打刻日時) 打刻日時* Factory Factory (打刻日時,勤務日仕様) Create() 生成
  32. 32. .NET 編 ソフトウェアアーキテクチャ実装
  33. 33. ソフトウェアアーキテクチャ実装 全体構成の概要 presentation infrastructure 例 勤怠管理.Web 勤怠管理.Infr astructure domain interfaces application domain 勤怠管理 interfaces application domain Web, WebAPI
  34. 34. ソフトウェアアーキテクチャ実装 interfaces ー 外部とDomainとの連携をとりもつ サンプル interfaces <usecase1> <usecase2> facade dto inner converter ISampleServiceFacade SampleServiceFacadeImpl SampleModelDTO SampleModelConverter ≪public≫ アクセス修飾子がpublicなのはfaçadeのインター フェースとDTOの2種類だけで、他はすべて外部から は見えないアクセス修飾子(C#ならinternal)にし ます。 Interfacesフォルダの直下に作成するフォルダはユー スケース単位となります。 presentation infrastructure domain interfaces application domain Web, WebAPI Interfaceは、domain外部との境界です。 外部よりプリミティブ型を受け取り、モデルに変 換します。 変換したモデルをApplicationServicesに渡し、 ビジネスロジックを起動します。 ApplicationServicesからの戻り値を外部へ返却 する場合は、DTOに変換してから渡すのも役目の 1つです。 ≪public≫
  35. 35. ソフトウェアアーキテクチャ実装 application ー ルートエンティティを扱う サンプル application ISampleAService impl SampleAServiceImpl domain model sampleA aggregate SampleA ISampleARepository SampleAEvent application中のクラスのアクセス修飾子 はすべてinternalです。 applicationで実装するサービスは、 Repositoryの具象クラスをDIContainer から受け取ります。 presentation infrastructure domain interfaces application domain Web, WebAPI applicationはinterfacesからのみ、起動します。 applicationはinterfacesと1:1にします。(元々、interfa cesは存在しません。interfacesの役割もapplicationで実装 するのですが、処理が煩雑すぎるので分割したのです。) applicationのメインの役割は、ビジネスロジックを起動です。 そのための具体的な実装は以下になります。 ・ルートエンティティの生成・保管・復元 ・ルートエンティティのロジックの起動 ・ドメインイベントのレイズ 1つのapplicationは複数のルートエンティティを扱います。 ≪internal≫ sampleA…集約 SampleA…ルートエンティティ ≪internal≫
  36. 36. ソフトウェアアーキテクチャ実装 domain ー ビジネスロジック サンプル domain model sampleA service shared sampleB SampleA ISampleARepository SampleId SampleA.InnerModelA IEntity IEntityIdentifier IValueObject SampleService IDomainEvent SampleAEvent domainの中には 「model、service、shared」 の3つフォルダを作成しておきます。modelの 中は、さらに集約単位でフォルダを作成します。 フォルダ名には集約ルートクラス名を「先頭小 文字」で付けます。 domainの中のクラスのアクセス修飾子はすべ てinternalです。集約の中に作るIRepositoryも internalです。 Repositoryの実装はdomainでは行いません。infrastruc tureで行います。 .NETの場合、IRepositoryがこのままではInfrastructure からみえないので、AssemblyInfo.csにてInternalVisibleTo属 性を使用して internalをinfrastructureに公開します。 ≪internal≫presentation infrastructure domain interfaces application domain Web, WebAPI sampleA →集約 SampleA →ルートエンティティ ISampleARepository →ルートエンティティに対 するリポジトリ SampleId →エンティティのIdバ リューオブジェクト InnerModelA →集約内部に隠れているバ リューオブジェクト SampleAEvent →ドメインイベント
  37. 37. ソフトウェアアーキテクチャ実装 infrastrucute – 外部との通信 サンプル domain model sampleA SampleA ISampleARepository SampleAEvent infrastructure messaging persistence SampleAEventPublisher SampleARepository queue dapper ≪internal≫ presentation infrastructure domain interfaces application domain Web, WebAPI infrastructureではdomainで宣言されたIReposi toryと、DomainEventの実装を行います。 Database Queue Service
  38. 38. ソフトウェアアーキテクチャ実装 おすすめのサンプル DDDSample Java DDD本の内容を実際に作ってみたサンプル。定番? 一度は見ておく必要あり。 https://github.com/citerus/dddsample-core IDDD_Sample Java 実践DDD本の内容を実際に作ったサンプル。著者で あるVaughn Vernonが本の内容に沿って自ら作った ものらしい。境界づけられたコンテキスト, EventSourcing, CQRSの実例を見たいならこれ。 https://github.com/VaughnVernon/IDDD_Sampl es IDDD_Sample_NET C# IDDD_SampleのC#版。 Domain-Driven-De sign-Example C# ドメインイベント、Specificationの実例あり。 解説が全部英語なのはちょっと辛い。 https://github.com/zkavtaskin/Domain-Dri ven-Design-Example
  39. 39. AzureとDDD
  40. 40. AzureとDDD DDDでは、ドメインイベントが非同期処理の対象となりやすい  EventSourcingやCQRSと組み合わせやすい applicationinterface Messaging Aggregate EventFactory Event EventPublisher Service Bus Queue Storage Queue Persistence IRepository SQL Database コマンド クエリ SQL DatabaseDataAccess Web Job CQRSの例 domain Section 1/1 total 13/13 非同期処理パターンの実現をAzureで EventSourcingの例 Web Job SQL Database Publisher
  41. 41. Azure ServiceFabric と DDD
  42. 42. Azure Service FabricとDDD ServiceFabricのご紹介 ServiceFabricとは、大きく分けて2つの機能を持ちます。 1.Reliable Service  自分でPaaSを構築するためのインフラ 2.Reliable Actor  Actorパターンを実現するためのPaaS DDDに直接関係があるのは2の方です。 今日は2のActorパターンの実現についてご紹介します。
  43. 43. ActorパターンとDDD 出典:InfoQ Vaughn Vernon氏が語る、アクターモデルとドメイン駆動設計 https://www.infoq.com/jp/news/2013/06/actor-model-ddd
  44. 44. Actorパターン(モデル)とは Actorパターンの特徴 • 他のActorにメッセージを送信します。 • 送信元のActorは、メッセージの受信を待たずに次の処理をします。(非同期的な動作) • どのActorにメッセージを送信するのかは、アドレスで指定します。 • メッセージ送信の順に受信することは保証されません。(順不同) • Actorは他のActorを生成することができます。(Child Actor) • Actor間で状態の共有はありません。 出典:Wikipedia https://ja.wikipedia.org/wikiアクターモデル Actor Actor
  45. 45. Reliable Actor(Service Fabric) その特徴 仮想Actor  Actorオブジェクトは、メモリ内表現と直接関連付けられていません。Actorオブジェクト は、Webサービスのようなもので、その生成と破棄を意識する必要がありません。  Reliable Actorプラットフォームは、メッセージが着信するとActorオブジェクトを自動的 に生成します。  一定期間メッセージの着信がないと、Actorオブジェクトは破棄されます。その際、Actor オブジェクトの状態は自動的に保存されます。 同時実行  Actorオブジェクトはシングルスレッドで稼働します。そのため、複数のメッセージ着信が あったとしても、同時に処理が動くことはありません。 Actorとの通信  ActorはInterfaceを公開し、実装はそのInterfaceをimplementsする形式となります。Act orを呼び出すクライアントはそのインターフェースを使って通信用のProxyオブジェクトを 生成し、Actorオブジェクトのメソッドを叩きます。アドレスの指定はありません。 (※どのFabricアプリケーションにデプロイされているかを指定する必要はあります)  Actorのメソッドを叩くときの引数にセットするオブジェクトはシリアライズ可能である必 要があります。
  46. 46. Reliable Actor(Service Fabric) 実装時イメージ IActor IMyActor MyActor <<abstract>> Actor ActorProxy Actor側 Client側 Actorを実装するためには、必ずServcieFabricSDKで用意されているIActorインターフェース を継承した自前のインターフェースを宣言する必要があります。(IMyActor) さらにActorの具象クラスはServieFabricのSDKで用意されているActor抽象クラスを継承しま す。(MyActor)
  47. 47. Reliable Actor(Service Fabric) ActorでHelloworldする Visual Studio のテンプレートでActorを選択して作成
  48. 48. Reliable Actor(Service Fabric) ActorでHelloworldする namespace HelloWorldActor.Interfaces { public interface IHelloWorldActor : IActor { Task<int> GetCountAsync(); Task SetCountAsync(int count); Task<string> HelloWorldAsync(); } } 非同期処理なので、Task型を返却。文字列を返却する場合はGenericでstringを指定
  49. 49. Reliable Actor(Service Fabric) Hello World文字列を返却します。Task型を返却する必要があるので、Task.FromResultメソッドを利 用します。 ActorでHelloworldする namespace HelloWorldActor { [StatePersistence(StatePersistence.Persisted)] internal class HelloWorldActor : Actor, IHelloWorldActor { public HelloWorldActor(ActorService actorService, ActorId actorId) : base(actorService, actorId) { } ・・・ Task IHelloWorldActor.SetCountAsync(int count) { ・・・ } Task<string> IHelloWorldActor.HelloWorldAsync() { return Task.FromResult("Hello World!"); } } }
  50. 50. Reliable Actor(Service Fabric) Clientを実装します。ServiceFabricとしてプロジェクトをまとめて いる「ServiceFabric Helloworldプロジェクト」を右クリックして追加します。 ActorでHelloworldする
  51. 51. Reliable Actor(Service Fabric) ステートレス Web APIを選択し ます。 このテンプレートは 一番左のステートレ スサービスを選択し た後に、WebAPI用 のライブラリをイン ストールしてセット アップしてあるもの です。 ActorでHelloworldする
  52. 52. Reliable Actor(Service Fabric) ActorProxy.Createで生成したプロキシオブジェクトを使用して、HelloWorldAsyncメソッドを叩 いています。 ActorでHelloworldする namespace WebApi.Controllers { [ServiceRequestActionFilter] public class HelloworldController : ApiController { private static Uri serviceUri = new Uri("fabric:/ServiceFabricHelloworld/HelloWorldActorService"); private static ActorId actorId = ActorId.CreateRandom(); private static IHelloWorldActor helloworldActor = ActorProxy.Create<IHelloWorldActor>(actorId, serviceUri); // GET api/values public IEnumerable<string> Get() { string greetings = helloworldActor.HelloWorldAsync().Result; return new string[] { greetings }; } ・・・ } }
  53. 53. Reliable Actor(Service Fabric) 結果 ActorでHelloworldする
  54. 54. ありがとうございました

×