NS study8 DDD Microservices Azuer Service Fabric

2016/07/06
株式会社ネクストスケープ
エバンジェリスト上坂貴志
NSStudy No.8
www.nextscape.net 1
～C# と Azure Service Fabric で最高の DDD 開発を～
ドメイン駆動設計＆Azureで
行うマイクロサービス開発

アジェンダ
なぜ今Microservicesなのか
MicroservicesとDDD
Domain-Driven Design
DDD導入のハードル
Azure Service Fabric
最後に
www.nextscape.net 2

自己紹介
• 会社
株式会社ネクストスケープ
• 名前
上坂貴志（うえさかたかし）Twitter:@takashiuesaka
• 年齢
44歳
• 好き・興味あり
Azure(Microsoft MVP for Microsoft Azure)、
Scrum（認定スクラムマスター）
DDD、ソフトウェアアーキテクチャ、機械学習
• 講演活動
• 2016年
de:code 2016 DDD & Azure Service Fabric 登壇
NS Study No.6 Azure IoTHub紹介
アプレッソ最新IT事例セミナー Azure Machine Learning セミナー登壇
SANSAN DDD勉強会発表
• 2015年
FEST2015 (Channel9で動画公開)
MSxNextscape合同 Azure Machine Learningセミナー開催
Developers Summit 2015
QCon 2015
CloudDays2015東京・大阪 3
• 執筆活動
• 人工知能アプリケーション総覧寄稿（日経BP社、2015年9月30日発売）
• ITPro：クラウドで機械学習を手近に、Azure Machine Learningの概要
www.nextscape.net 3

会社紹介
www.nextscape.net 4
設立年月日 2002年4月10日
資本金 1億5001万円
主要株主株式会社豆蔵ホールディングス
（東証一部上場）
〒163-0722
東京都新宿区西新宿2-7-1
小田急第一生命ビル22F
03-5325-1301(代表)

会社紹介
www.nextscape.net 5
クラウド、デジタルマーケティング、システム構築に強み
（※2012年～2014年マイクロソフトパートナーズオブザイヤー）
2013 Microsoft Worldwide Partner Award において
Sitecore Of The Year Asia 2013において
Cloud Partner of the Year ファイナリスト選出
Best Japanese Siteを受賞
3年連続 Microsoft Azureパートナーアワード受賞

会社紹介
www.nextscape.net 6
タワーレコード様
「NO MUSIC, NO LIFE.」のキャッチフレーズでおなじみの、音楽エンタメ・小売り事業の大手。
250万点もの商品を取り扱うオンラインショップ「TOWER RECORDS ONLINE」のCMSをSitecoreで構
築。
2010年当時に1日当たり100万強だったPVは、2014年4月時点で205万強まで倍増。
https://www.sitecore.net/ja-jp/customers/e-commerce/towerrecords.aspx
エイベックス通信放送様（ｄTV powerd by BeeTV ）
「dビデオ powered by BeeTV」は、スマートフォン利用者向けに映画、ドラマなどを視聴可能な国内最大
規模の動画配信サイトとして注目を集めている。
Microsoft Azureにて、高負荷・ハイパフォーマンスに耐えうるスケーラブルな配信インフラを構築。
http://special.nikkeibp.co.jp/as/201207/mpncompetency/cs01.html
400万会員を超える動画サイトの配信インフラを構築
EC売上を3年間で2倍以上にしたタワーレコードの成長を支えたCMS基盤を導入

なぜ今
Microservicesなのか

なぜ今Microservicesなのか
www.nextscape.net 8
サービス切り出し指針がなかった
サービス間の連携について標準がなかった
可用性を担保が難しかった
分散リソース実装が辛すぎた
初期SOAの思想は素晴らしかった
だが思想を実現する前にSOAの概念が拡大しすぎた
設計
設計・実装
インフラ
実装
初期SOAの思想の実現ですら難しかった

MicroservicesとDDD
www.nextscape.net 10
よく見かけるのが
というやり取り。
サービスをどうやって
分割すればいい？
DDDの「境界付けられたコ
ンテキスト」が参考になり
ます
折角DDDに触れるのにそこだけ？勿体無い！

DDDの考える課題
戦略要件基本設計詳細設計実装
変換変換変換変換
この戦略はどの実装？
この実装はどの戦略？
この変換が全ての元凶！

顧客にとっては理不尽だらけのIT業界
機能追加して
機能の改善して
バグだ！すぐ修正して
工数とスケジュールの提示
するけど・・・
でも工数の根拠は提示されない。提示できない。

小さな機能追加依頼
• 以前と同じぐらいのボリュームだろう、
と顧客は思っている
見積もり提示
• 以前に比べて高額
• でも根拠は提示されない（できない）
不信感
• 高い！遅い！前と違う！
• もっと早く、もっと安くできるでしょ？
スケジュール優先の対応
•顧客の要望は品質よりスケジュール、予算より
スケジュール、と理解
•ソースが肥大化（品質悪化）
不信感の負の連鎖

DDDの目指す世界
業務をモデルで
表す
モデルをそのま
ま実装する
モデルから業務
を改善する
業務と実装のギャップを埋める
余談：業務＝ドメインってこと？詳しくは後ほど

DDDのよくある誤解
 そういう箇所も一部もありますが、それはDDDの
メインではありません。
 ビジネスモデリングなどの要求開発工程から業務
フローなどの要件定義工程などを含んでいます。
DDDとは
デザインパターンのような設計技法
である

モデリングから実装へのプロセス
ドメインをコン
テキストで分割
コンテキストごと
にドメインをモデ
ルとして表現する
モデルをそのま
ま実装する
最初はものすごくざっくりとした理解から

そもそもドメインとは何か
 もっとざっくりと具体的には、ドメインとは
システムを使う人にとっての関心事のことです。
DDDではドメインエキスパート、という言
葉出てきます。これは業務（ビジネス）に
精通している人のことを指します。
業務業務の成果
という感じで最初はいいんじゃないでしょうか
達成したいことエンドユーザー
運用者
※異論は認めます！他にもステークホルダーはいっぱいいますよね
が

ではコンテキストとは何か
誤解を恐れず
に言えば、
「環境」
特定のモデル
達だけが意味
を持つ「環
境」
モデルが特定
の意味を持つ
ための「前提
条件」
そのモデルは、そのコンテキストだけでしか成立しない
もうちょっと言えばもっと正確に言うと

ではコンテキストとは何か
www.nextscape.net
20
メンバー同士の会話特定の作業あるコードの範囲
そのモデルは、そのコンテキストだけでしか成立しない
コンテキストの例
例：料金というモデル。ある時は送料を、あ
る時は発注代金を表す
例：コンテンツを個人単位にブックマークす
る機能のことを、ある時はお気に入り機能、
ある時はクリップボード機能
よくある混乱
 違うものを同じ言葉で表す  同じものを違う言葉で表す

境界付けられたコンテキストとは
業務別
• 在庫管理業務
• 商品発送業務
顧客の組織別
• パッケージング・発送
• 経理
• 経営
• 広告
他システム
• DDD本の例だとレガ
シーシステムが良く出
てくる
つまり粗い前提条件別にアプリを分割すること
よくある分割指針
コンテキスト（前提条件）が違うことが明確になった結果のこと

分割したコンテキストを明示化
順応者
図の参考：コンテキストマッピングによる戦略的ドメイン駆動設計
https://www.infoq.com/jp/articles/ddd-contextmapping_jp
コンテキストマップ目的１．コンテキスト間の関係を明示化
コンテキスト間の情報の伝達に
は注意が必要
他コンテキストのモデルで自分のモ
デルを侵食されないようにする腐敗
防止層(Anti Corruption Layer)の検討を
情報変更のトリガーとしてドメイン
イベントの検討を
Webユーザープロファイル
個人財務管理銀行
システム
支払い追跡
オンライン銀行
サービス
(レガシーシステム)
パートナー
U
D D
U

分割したコンテキストを明示化
目的２．コンテキスト間のモデルのマッピング
図の参考：Modularity and Domain Driven Design; a killer combination?
http://www.slideshare.net/aca_it/modularity-ddd
コンテキストマップ
車
オプションオーナー
保証
モデル
製造
車コンテキスト
輸送
場所
輸送対象
輸送先顧客
輸送依頼元
輸送コンテキスト
ビジネス
パートナー
担当窓口住所
ビジネスパートナーコンテキスト
from
to

不信感の負の連鎖を
断ち切る

モデルを顧客と作る
モデルを顧客と作る＝要件定義＋設計です
• モデルで使用されている名詞や動詞に、顧客が知らない言葉があってはなら
ない。
• モデルがそのままコードになる＝言葉がコードで使用される
顧客と同じ言葉でモデリングする。
業務の中身をモデリ
ング
• 顧客と一緒にモデリ
ングすることが重要
開発者もモデリング
に参加する意義
• 業務を正確に把握で
きる
顧客もモデリングに
参加する意義
•複雑な業務がそのままコー
ドになることから
コスト感覚を持てる
重要なプラクティス、ユビキタス言語

おまけの話
DDDのソフトウェアアーキテクチャ
達成すべきこと
•ドメインレイヤー内でドメインモデル以外の余計なものを絶対に入れない
•DDD本ではレイヤーアーキテクチャが掲載されているが、特にこの構成を採用せよと規定されていない
図の参考：DDD and Hexagonal architecture
http://tindaloscode.blogspot.jp/2013/11/ddd-and-hexagonal-architecture.html
「実践ドメイン駆動設計」では
PortAndAdapter（別名ヘキサゴナル
アーキテクチャ）をお勧めしている
余計なものって？例えば
データ永続化
ロジック
トランザク
ション
権限チェック
ロジック
ドメイン
Layer
Port
内部Client Port
外部Client Port
内部永続化Port
外部サービスPort
HTML
Web Gadget
RIA
Viewer
Web API
ESB
inbound
RDBMS
In-memory
Object store
他システム
ESB
outbound
プレゼン
Layer
インフラ
Layer

DDDがなかなか採用されない理由
DDD本が難解すぎる
• とにかく分厚い
• 前提とするスキルレベルがかなり
高い（PoEAA知ってるとか）
• 章立てとプロセスが紐づいていな
いので混乱しやすい
設計・実装のイメー
ジが沸かない
• 結局どうすればいいのかわからな
い
• どこから手を付ければいいのかわ
からない
モデリングできる人
がいない
• 大抵の場合、ER図になる
• もしくは、ただ構造を表しただけ
の静的なモデルとなる
小さななシステ
ムには向かない
手法
小さく実験して
も効果がわから
ない
むしろ煩雑なだ
けにしか感じな
い
何がいいのかわ
からない
最大のハードル：試しにくい

ハードルを越えよう
「実践ドメイン駆動設計」は読みやすいです
• 本で登場するサンプルの著者による実装がGithubにあります
• https://github.com/VaughnVernon/IDDD_Samples
まずは社内システムから
• そこそこ複雑なものを選ぶ
• システム開発にあまり詳しくなく、モデリングに付き合って
くれる業務担当者に協力を依頼

ハードルを越えよう
要件定義中からモデルを書きましょう
• モデリングをする、ということは業務フロー＝モデル、となるはずです
• 逆にいうと、基本設計以降のフェーズだけでDDD採用は見送った方が良いです（負担ばかりが多くて価値が出にくい）
コンテキストマップを書きましょう
• これを軽視すると１つのコンテキストでモデリングしがちです。巨大なモデル群を作り上げてしまいます
最初からテーブル設計を絶対にしないこと
• DDDを採用すると開発プロセスが変わります。
• モデリングという作業が強要され、要件定義＝モデリングしつつ実装も進めます。
• ER図の作成開始はモデリングが完了してからです。が、モデリングは要件定義なのでなかなか固まりません。
• だからER図の作成は後回しにするしかないはずなのです。
• RDBMSで保存するなら最終的にテーブル設計は必要ですが、最初からやろうとしてはいけません。無駄になるだけなら
いいですが、最悪モデリングしないで工程が進んでいきます。（もはやDDDではない）
私が感じた、実践したほうが良いプラクティス
大事！

Azure Service Fabric
難解極まるMSDNを読み解こう！

Azure Service Fabricとは
スタンドアロンアプリのクラスタ化PaaSです。
• クラスタリングとは？
多数の低廉なコンピュータを、特別なソフトウェア・ハード
ウェアを用いて、あたかも1つの大きなコンピュータとして利
用できるように接続すること。（Wikipedia）
1. 負荷分散・・・複数のマシンで処理を分散
• クラスタの特徴とは？
2. 高可用性・・・1台のマシンが停止しても、待機系マシンがすぐ立ち上がる

イメージ
Exe
Exe
Exe
Exe
Exe
Exe
Exe Exe処理リクエスト
• ５つのExeで負荷分散
• ３つのExeが待機中

イメージ
Exe
Exe
Exe
Exe
Exe
Exe
Exe１つが停止してしまった

イメージ
Exe
Exe
Exe
Exe
Exe
Exe
Exe１つが停止してしまった
待機系が昇格

イメージ
Exe
Exe
Exe
Exe
Exe
Exe
再起動して待機系に
待機系が昇格

スタンドアロンアプリは2種類に大別されます。
1. Exe, Javaアプリなどのスタンドアロ
ンアプリをホスティング
2. ServiceFabricのSDKを使ったアプリ
をホスティング（実はこれもスタン
ドアロン
ゲスト実行可能ファイル
ステートレス
サービス
ステートフル
サービス
という名称です。でもServiceFabricは
として起動します。
2種類のタイプのサービスを作ることが
できます。ステートレスサービス

MSDNを見るともう1つReliable Actorというものがあります。
これはExe単位ではなくオブジェクト単位のクラスタです。
実態はステートフルサービスです。
つまり、Service Fabricを理解する近道は
ステートレス
サービス
ステートフル
サービス
を理解することです。
※もっと言うと、ステートレスサービスから理解するとわかりやすいです。
ちなみにService FabricはオンプレでもLinuxでも動きます！
別にAzure上だけで動くサービスじゃありません！

Azure Service Fabricでマイクロサービ
スとは
大きな
システム
小さな
サービス小さな
サービス
小さな
サービス
分割
小さな
サービス
独立した小さなサービスが協調して
大きなシステムを構成
モノリスマイクロサービス

Azure Service Fabricでマイクロサービ
スとは
ステートレス、ステートレス、時には
Acitorも組み合わせて大きなシステム
を構成します。
大きな
システム
分割
モノリス Service Fabric
ステートフル
サービスステートフル
サービス
Microsoft Azure
ステートレス
サービス
ステートレス
サービス
これ１つずつについて
・負荷分散
・高可用性
を担保することができる

Service Fabric SDk

Service Fabric SDKを使った実装
 ServiceFabricのSDKを使って実装すると
• 外部との通信が実現
• 中止、開始、停止時のイベントをハンドルできる
プログラミングモデルの種類
Reliable Service Reliable Actor
ステートレス Service ステートフル Service
Exe等の実行ファイル
単位のホスティング
Service Fabric
の基本
オブジェクト単位
のホスティング
 データを保持しない
 StatelessServiceクラス
を継承したクラスに実
装していく
 データを保持する
 StatefullServiceクラスを
継承したクラスに実装
していく

StatelessService
から覚えましょう。

Stateless Serviceの仮想メソッド達
StatelessService
※StatefullServiceも同名の仮想メソッドを持っていて使い方も同じですが、クラ
ス階層を辿っても、StatelessServiceとStatefullServiceは関連がありません
自作クラス
Task RunAsync(
CancellationToken cancellationToken)
Task OnOpenAsync(
Task OnCloseAsync(
void OnAbort()
IEnumerable<ServiceInstanceListener>
CreateServiceInstanceListeners()
サービス起動イベントハンドラ
バッチ処理用
サービス起動準備の最後にレイ
ズするイベントのハンドラ。初
期化処理用
サービス停止イベントハンドラ
外部からの着信を待ち受けるリ
スナーを返却する
サービス中止イベントハンドラ
※全部仮想メソッドなので必要
なメソッドだけOverrideする上の４つのメソッドは
イベントハンドラ

Service Fabricの外部と通信する
StatelessService
RunASync, OnOpenASync, OnCloseASync, OnAbort
MyService
ICommunicationListener
MyListener
protected override IEnumerable<ServiceInstanceListener>
CreateServiceInstanceListeners()
{
return new ServiceInstanceListener[]
{
new ServiceInstanceListener(serviceContext =>
new MyListener ())
};
}
Task<string> OpenAsync(
Task CloseAsync(
void Abort()
見ての通り、リスナーは複数
返せるのでエンドポイントを
複数用意できます。
1つはhttpで、もう1つもhttpで
Port違い、3つ目はtcpでクラス
タ内通信とかできます
あれ？こっちも
Open,Close,Abo
rtじゃないか
OpenASyncメソッドの戻り値で
返す文字列が重要。
外部からの着信をリッスンす
る場所を返却する
例：http://ホスト名:port/ほげ
ほげ

Webで通信
 IISが動かないので、OWINで自己ホストします
 Visual Studioに用意されるテンプレートのService Fabric
WebAPIはMSDNで解説している内容の完全実装です
StatelessService
自作クラス
Startup
void ConfigureApp(IAppBuilder appBuilder)
protected override IEnumerable<ServiceInstanceListener> CreateServiceInstanceListeners()
{
{
new ServiceInstanceListener(
serviceContext => new OwinCommunicationListener(
Startup.ConfigureApp,
serviceContext,
ServiceEventSource.Current,
"ServiceEndpoint"))
};
}
ICommunicationListener
OwinCommunicationListener
Task<string> OpenAsync(CancellationToken cancellationToken)
OpenASyncでリッスンするURIを組み立てて、
サーバースタートしているだけ
https://azure.microsoft.com/ja-
jp/documentation/articles/service-fabric-reliable-services-
communication-webapi/
MSDN解説のURL

WCFで通信
 なんと。ICommunicationListenerを実装済みのクラスが提供
されています。Nugetで入れます
 完全なサンプルが見当たらないので、実装のポイントをいくつか
https://azure.microsoft.com/ja-jp/documentation/articles/service-fabric-reliable-services-communication-wcf/
MSDN解説のURL
プロジェクト構成
※サンプルではクライアントも同じクラスタ内で稼働させる必要が
あるため、クライアントをStatelessServiceでプロジェクト追加します
プロジェクト参照します

WCFで通信
WCFホスト側の実装
Calculatorの実装がサンプルに見当たりません。適当に作ってください
class Calculator : ICalculator
{
public Task<int> Add(int value1, int value2)
{
return Task.FromResult(value1 + value2);
}
}
<Resources>
<Endpoints>
<Endpoint Name="WcfServiceEndpoint" Protocol="tcp" Port="8515"/>
</Endpoints>
</Resources>
リッスンする場所とプロトコルを定義して名前つけます
internal sealed class WcfHostStateless : StatelessService
{
private ICalculator _calculator;
public WcfHostStateless(StatelessServiceContext context)
: base(context)
{
this._calculator = new Calculator();
}
protected override IEnumerable<ServiceInstanceListener> CreateServiceInstanceListeners()
{
{
new ServiceInstanceListener(serviceContext =>
new WcfCommunicationListener<ICalculator>(
wcfServiceObject:this._calculator,
serviceContext:base.Context,
endpointResourceName: "WcfServiceEndpoint",
listenerBinding: WcfUtility.CreateTcpListenerBinding()
))
};
}

WCFで通信
サンプルでServiceUriというオブジェクトが説明なく出てきます。
これはWCFを実装したホストの場所を保持したUriオブジェクトです。
例：”fabric:/アプリ名/サービス名/”
WCFクライアント側の実装
クライアント側にもライブラリをいれてください
private void CallWcf(StatelessServiceContext context, string endpointName)
{
var binding = WcfUtility.CreateTcpClientBinding();
IServicePartitionResolver partitionResolver = ServicePartitionResolver.GetDefault();
var wcfClientFactory = new WcfCommunicationClientFactory<ICalculator>
(clientBinding: binding, servicePartitionResolver: partitionResolver);
var calculatorServiceCommunicationClient = new WcfCommunicationClient(
wcfClientFactory,
new Uri("fabric:/ServiceFabricWcf/WcfHostStateless"),
ServicePartitionKey.Singleton);
var result = calculatorServiceCommunicationClient.InvokeWithRetryAsync(
client => client.Channel.Add(2, 3)).Result;
}
サンプルそのままです
this.CallWcf(this.Context, "WcfServiceEndpoint");
RunAsyncの中でCallWcfメソッドを呼びます
Wcfホストと同じEndpoint
設定を記載します

で一緒に働きませんか！
一次請け案件100％
SESやっていません。すべて自社開発（西新宿）
DDDプロジェク
ト２つ進行中
Scrumプロジェ
クト3つ進行中
裁量労働制
コーヒー、ミネラ
ルウォーター、お
茶飲み放題
デュアルディスプ
レイ支給
技術書籍は全額会
社負担
各種社外研修も全
額会社負担
海外カンファレン
スも積極的に行け
ます
募集中！
•PM
•PL
•SE
•スマホエンジニア

イラストはこちらを利用させていただきました
いらすとや：http://www.irasutoya.com/
ブ
ー
ス
に
も
来
て
ね
！
NS Study
で待って
ます！

NS study8 DDD Microservices Azuer Service Fabric

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to NS study8 DDD Microservices Azuer Service Fabric

Similar to NS study8 DDD Microservices Azuer Service Fabric (20)

More from 貴志上坂

More from 貴志上坂 (10)