最近、自分の関わっているサービスをDDDで再設計してるというお話

タイトル以上の意味はない、ただの経験談。

　きっかけは半年前、自分の担当するサービスのprを後輩にレビューしてもらったとき、彼から「何書いてあるか分からないですね」と言われたことからだった。
　彼が事あるごとに言ってた「ドメイン駆動設計」について、いい加減腰据えて取り組んでいかないとますますメンテしづらいシステムになるな、という予感はあったので、どれどれ、と軽い気持ちでリファクタリングっぽいprを作ってみた。結果、その後輩から大目玉を食らってしまった。普通のエンジニアなら「おいおい」と思う話であるが、O/R Mapperの行オブジェクトをただ少し拡張しただけだったので、何の意味もないものだった。
　この理解度でDDDをやるにはレビュアーの後輩の負担があまりにも大きすぎると痛感したので、一念発起して先ずは「実践ドメイン駆動設計」（以下IDDD）を読むことに。

実践ドメイン駆動設計 (Object Oriented SELECTION)

　実はEric Evansの「ドメイン駆動設計」（以下Evans）も以前購入はしていたが、概念の説明が全く頭に入ってこなかったので恥ずかしながら早々に脱落してた。が、今回は具体的に自分の関わってるサービスに落とし込むというゴールがあるので、それなりに必死だった。常に付け焼き刃ではあったが、IDDD本で得た知識はなるべくすぐにそのprに反映する形にし、後輩のアドバイスも、本を読み進めるごとに少しずつ何を話しているのかが分かるようになってきた。
　結局、DDD化第一弾となるそのprは、差分1000行ほど、業務の合間にちまちま直し続けて一ヶ月かかって漸く後輩のOKが出た。但し、「多分そのうち色々直すことになるけど、DDD flavoredな実装としてはギリギリ我慢できるレベル」という条件付き。実際、その後何度も大きく手を入れている。

　IDDD本は、付録のEvent Sourcingにさしかかったところで一旦読むのをやめた。まだしばらくESを導入できる土壌がないのと、ESをしなくてもDDDは実践できる、と判断したため。あと僕は理解が遅いので、必要に応じて部分的に何度も読み返して自分の理解を少しずつ深めている。並行して、最近はまた少しずつEvans本を読んでいる。IDDD本には書いてなかったけど重要そうな要素がいくつもあり、モヤモヤしていたところがいくつか晴れた（そしてまた大掛かりなリファクタリングをすることに。。。）。
　因みに、なぜEvans本ではなくIDDD本から読み始めたかというと、「もう少し具体的なプラクティスを知りたかった」というのはあるが、「後輩からまずこちらをおすすめされた」というのも割と大きい。僕の場合、あるパラダイムについて慣れるのに基本的に手を動かして身を切らないと学べない頭の悪い人間なので、まずIDDD本でとっかかりを作り、ある程度DDDのパラダイムに慣れたところでEvans本でより理解を深める、という流れに結果としてできたのはよかった。

　DDDの概念を腹落ちさせるまでにだいぶ時間がかかったが、腹落ちしたきっかけは、自分が「データ」を中心に考えていたというのを把握したからだった。すべてのパラメータやデータオブジェクトを同列視していて、データを丹念に一つ一つ次の処理に送り込む、ということを繰り返して一連の処理を作っていたので、その膨大なパラメータのやりとりによって本来やるべきことを見失いかけていた。データはその由来や誰が変更するかという指向性や軽重があることが段々と見えてきて、これによってエンティティと値オブジェクトの区別ができるようになり、集約を固めてリポジトリが組めるようになってきた。リポジトリへの永続化の際、そのデータの変更はトランザクション整合性なのか結果整合性なのかと考えるようになり、いくつかはドメインイベントを使ってメインの処理からは外しても問題ないとわかった。DDD化を進めるうちに、ActiveRecordパターンはDDDにとってあまりにミスマッチで混乱の元凶なので、行オブジェクトをリポジトリの外に持ち出すことはなくなった。もはや行オブジェクトを「モデル」と呼ぶ時代は（今いるプロジェクト内では）終わった。DDDベースで書いた箇所については、行オブジェクトはリポジトリ内で存在確認とキャッシュにしか使っていない。本当はもっとシンプルにしても良さそうだが、O/R Mapperはトランザクション周りの管理やクエリビルダとして優秀なので、その辺は引き続き使っている。
　エンティティとリポジトリについての理解が飛躍的に上がったのは、「idを誰が発行するのか」についてきっちり切り分けて考えられるようになったからだった。今まではidの発行はMySQLのauto_increment任せだったので、DBにデータが入らないとエンティティとして完成しなかったが、id生成器を使うことでMySQLがなくてもエンティティが作成できるので、リポジトリの責務がよりシンプルで分かりやすくなった。

　こうして戦術面でどう考えていくかがある程度見えてきたので、戦略面での「ユビキタス言語」や「ドメイン」をなぜDDDでは重視するのかというのがもっと立体的になってきた。多分Eric Evansの考え方には「ドメインエキスパートの頭の中のモデルは実はそんなにドラスティックに変わることはないが、そのモデルを設計者（＝実装者）が捉えきれてないために、変更要求が実装者にとってはとても大きな出来事として捉えられてしまっている」というのが間違いなくあると思う。あとActiveRecordパターンを許すと、本来ドメイン層で振る舞わせなくちゃいけない処理を「共通化」の名目で容易にインフラ層に押し込めることができてしまうので、「知らないところで何か重要なことが行われている」というのが常態化してしまう。DDDはそうした「認識齟齬」や「ごちゃまぜ」を防ぐためのルールなんだというのが半年かかってやっと体得できた。完璧に実現できてるわけではないが。

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

　PDS（Presentation Domain Separation）自体は本当に重要だと思うが、これとレイヤードアーキテクチャとActiveRecordパターン「だけ」で設計するとなると指針がプリミティブ過ぎて、というかそれぞれの考え方を繋ぐものがなくて実装者の手腕に委ねる部分が大きくなるので、プロジェクト内でしか通じない記法やダーティハックがはびこることになると最近は感じる。中にははその「つなぎ」を作るのが好きで色々考えたいと思う人もいるかもしれないけど、僕はそういうところに自分の足跡を残すことに興味はない。
　設計は本当に難しい。
　ただ、何故難しいと思うのかについて、その原因の一端は自分自身にあることもわかってきた。それは、設計のセオリーを持ってないことだった。そのセオリーというのもどうやらあるらしく、最近、新規実装やリファクタリングをする際、ロバストネス分析をしてアタリをつける、というのを始めた。
　ロバストネス分析についても例の後輩が見つけてきたものだ。これは「ユースケース駆動開発実践ガイド」（以下ICONIX）に詳しい。

ユースケース駆動開発実践ガイド

　ユースケース記述→ロバストネス分析→詳細設計（シーケンス図）をきっちりやるとベストだが、一度流れだけやってみたが、完全にウォーターフォールの開発フローになるのと、開発を始めるまでかなり時間がかかりそうだったのでやめた。現在のチーム体制のスピード感には合わない。が、仕様や実装がある程度ドキュメント化されるのと、実装フローが見える化できて事前に色々話し合いができるので、うまくつまみ食いしながらほどよい距離感で進めていきたい。
　IDDD本だと、ドメインの抽出や設計について「チームメンバーで（ドメインエキスパートも含めて）よく話し合う」くらいにしか書かれていない。単純に書籍のスコープでないから省略されているのか、手法が確立されてないので言語化されてないのかは判断できない。が、ICONIX本によると「ドメインの抽出はユースケースの分析によって行う」（←だいぶ端折っている）と書いてあり、僕はこのICONIX本を読んで自分の中のミッシングピースが埋まったと感じた。確かにDDDは「整頓のしかた」については書いてあるが、肝心の「ドメイン（層）の振舞い方」については書いてない。DDDは「ドメインの振舞い」がまず定義できてこそ、ユースケースに付随するドメイン以外の種種雑多な振舞いを整頓していく、というのが王道の流れなのでは、と思うに至った。

まとめ

　この半年の経験を通して、自分がここまで設計力がなかったんだな、というのをまざまざと思い知った。でも、気づかないままこの後の人生を過ごすよりはずっとよかった。
　何より、辛抱強く色々教えてくれた後輩には本当に感謝しかない。ありがとう。

golangでBME280から情報を吸い出してよしなにする

相変わらず、goではなるべくニッチそうなlow layerなところを攻めております。
go用のI2C周りのライブラリはいくつかありますが、embdが割と素直な印象で、
実は先日BMP180というチップも買って、こちらであっさりと動かせるということを確認していました。

BMP180 気圧センサ（気温センサ付き）

embd/bmp180.go at master · kidoman/embd · GitHub
↑このスクリプトをrpiで動かしてみたら修正なしで動いてしまい、かなりびっくりしました（とても優秀なサンプルでした）
ただ、僕の本命はBME280の方で、これは温度と気圧の他に湿度も計測出来る優れものです。

BME280搭載 温湿度・気圧センサモジュール

データシートを読んでると、BMP180と全然動かし方が違う。。。
http://trac.switch-science.com/wiki/BME280
当初はスイッチサイエンスさんが用意してくれたpythonスクリプトを元にgoに書き換えようとしましたが、
やっぱりスクリプト言語なので、よしなな型変換が多い。。。
一旦組み上がったので起動してみたら、温度が-84℃とか出てきたので、思わず笑ってしまいました。
github.com
↑動作確認のために上記のスクリプトを動かしてみたらちゃんとそれっぽい値は取れているので、恐らく結線は問題ないはず。
ということで、大元のチップメーカーであるBoschのドライバを参考にすることに。
GitHub - BoschSensortec/BME280_driver: Bosch Sensortec BME280 sensor driver
型や計算を上記のCのソースに沿う形に修正してみたところ、無事動きました！

最近、計測値の保存はAT&Tのm2xを使用しております。これも一応値に応じて何かをトリガーするとかできるっぽいです。やったことないけど。
rpiとチップはこんな感じで結線してます。

で、golangでBME280を動かすためのドライバは以下となります
github.com

gist7bdffe63dff403546c4e
動作サンプルはこんな感じ

電力モニター「はやわかり」に記録されているデータをgoで吸いだしてmackerelに送ってみる

承前↓
taiyoh.hatenablog.com
ついに前回のエントリの「hogehogeする」の中身が決まりました。
２年間完全に塩漬けにしてましたが、ふと思い立ったのでやることに。
当時吸い出す部分まで作って止めていたのは２つ理由があって、

• amd64->armのクロスコンパイルに挑戦しようとしたが、cgoだと相当ハードルが高いということがわかった
• 得られたデータをどこでどう閲覧・管理するかが決まってなかった

というのがありました。
goの環境についてはraspberry pi上で普通にビルドすればいいじゃん、と思えてきたのと、raspberry piで受け取ったデータをhogehogeする的なのを検索してみると、mackerelに送っているというエントリをいくつか見かけたので、時代はやはりこれだろう、と。実際、mackerel周りの導入はめっちゃ楽でした。
良くも悪くも、当時のコードはgo1.5でもビルドできたんですが、コールバックで渡すのがかっこ悪く見えてきたのと、シグナルのハンドリングはライブラリじゃなくね？とも思えてきたので、その辺を思いっきり書き直しました（どうせ僕しか使わないやつなので）。
また、一日かけて環境を整えていざ動かしてみたら、segmentation faultでホスト毎落ちるというのが見つかりました。参考にしたeagle-owlのソースコードをもう一度読みなおしてみたら、大きめのbufferを用意した上でusb_bulk_readをし、返り値のバイト数に応じて小分けにしているという処理があったのを完全に失念していたので、これも追加しました。
で、どうにかこうにか値が取れるように。

最初に10Aを超えた値になったのは電子レンジを動かした時で、その直後に15Aを超えてるのは、ケトルでお湯を沸かし始めたからですね。（部屋の中寒いんだよ！）
いい感じで値が取得できるようになったかと。ここから先どうするとかは今後考えよう。。。
実際にraspberry piで動いてるコードは https://github.com/taiyoh/go-cm160/tree/master/example 以下にあります。へっぽこなのでご笑覧ください。
（どれくらいへっぽこだったかというと、昨日時点のコードだとmackerelに無駄にデータを送りまくってて、raspiのCPU使用率が90%を超えてました。大変申し訳ありませんでした！）
因みにこのコードの負荷についてですが、起動時は一瞬80%を超えることがありますがすぐに落ち着き、何かが徐々に上がってるということも今のところ見当たらず、平常時はmackerel-agentとcm160のプロセスを同時に動かしててもトータル12%くらいとなっております。

節電モニター

ubuntu版chromeでpulseaudioが落ちた時の対処

もう一度音が出るようにするには、現状、以下の２ステップを踏む

1. $ pulseaudio --startでpulseaudioを起動し直す
2. chromeを親プロセスから再起動する（単にウィンドウを閉じるのではなく、アドレスバーにchrome://restartを打ち込む）

というのも、どうやらubuntu版chromeは、chromeの親プロセス起動時にpulseaudioの接続先を見つけるようだ。恐らく、子プロセスはそれを共有しているはず。それはそれでいいのだが、親プロセス側での接続できなくなった時の再接続の処理がうまくいってないか、そもそも接続を確認する手段がないのか、はたまたlinux版なので適当にされてるか、まあそのどれかではないかと思う（ソースを追う気力はない。。。）
「ubuntuでchrome使ってるけど音が鳴らなくなった」みたいなことをググってみると「rm -rf ~/.config/google-chrome/するといいよ」なんて回答が引っかかるけど、上記の２ステップを踏めばOK。

iRKitを買ったお話

　lirc+lirc_webのシステムを作ったのが去年の話なのですが、肝心のエアコンの信号はlircでは認識できなかったし、今年に入って例のブレッドボードで組んだ回路が動かなくなったんですね。そもそもブレッドボードはそんな長く使うものじゃない筈なんですが。。。
　いい加減リモートでon/offできるシステムは復活させたかったので、作った回路は捨てて、先週やっとiRKitを買いました。
　結論から言うと、早く買っておくべきでした。
　部屋に無造作に置いてても問題なく機器に届くし、なによりエアコンの信号をちゃんと認識してくれたのが大きかった。小さくてかわいいし。
　そんなわけで、例のlirc_webのクライアント側も修正し、結果ただのhttp送信装置となり（iRKitのIPを直接指定して信号の文字列を送るだけになったので）、これでやっと外からエアコンのon/offも操作出来るようになりました。実に1年半越し。大塚さんには本当に感謝です＞＜

　先週末時点でライトのon/offはできるようになってたんですが、エアコンがどうも動いてなくて、原因を調べたら単にヘッダのContent-Lengthが抜けてただけでした。

　→ IRKit - Open Source WiFi Connected Infrared Remote Controller

IRKit - iPhone,iPadを使って外出先からエアコン等の家電を操作できる学習リモコン

Macじゃない環境でもIRCで流れてくる画像を表示したい人生だった

　Mac版LimeChatのサムネイル表示機能が羨ましすぎるのですが、今使ってるマシンがUbuntuだったりして、悲しみが募っていたわけです（Macに変えればいいじゃん、というのは根本的すぎるのでスルーします）。そんな悲しみを紛らわすためにずっとIRCツールを探し続けてたのですが、サムネイル表示できるのはどうもなさそう。
　でも、そんな時に見つけたのがweecloudというweb frontendでした。
　→ eirikb/weecloud · GitHub
　このweecloudというツールはweechatのrelayという機能を使って機能拡張を行うもので、weechatとはnode.jsでデータのやりとりを行い、ブラウザとはsocket.ioを使ってやりとりをしてます。表示部分に特化していて、かつその表示はHTMLなので（正確にはjade）、HTML・js・cssをいじれば自分好みの表示ができるやん、ということに気づいたわけです。
　ということで、早速拙い英語でp-r送ってみました
　→ insert thumbnail if message has image url by taiyoh · Pull Request #25 · eirikb/weecloud · GitHub
　実際採用されるかは謎ですが。
　あと、このweecloudは手元で動かすことを想定していて、認証関連は完全にスルーしてるんですね。なのでうかつにVPSに置くのは厳しいのですが、ここであのtypester師謹製のgateの出番となります。用意したサブドメインへのアクセスは一番表に置いたnginxで受け、gateに渡す。あとは認証はgateがやってくれて、通れば更にその後ろのweecloudに渡してくれます。gateはwebsocketにも対応してるので、リアルタイム通信も問題ないです。また、weechatの起動してるサーバと同じ所でweecloudを動かすので、relay用のポートを外に空ける必要がなく、weecloudとの通信をsslにしておけば、そこそこ安全性も確保できるのではと思います。
　この成果を後輩に言ってみたら「努力がすさまじいwww」と小馬鹿にされたわけですが、冒頭でも言ったとおりサムネイル表示を出来る方法を探してたのと、gateを使ってみる口実が欲しかったというのが今回の目的なので、もしかしたら数日たったら飽きて戻ってる可能性もだいぶあります。

（追記: 8/22）
上記p-r、早速マージされておりました。

radikoで聞ける番組をcronで録音したくなったので

　作った
　→ taiyoh/p5-radiko · GitHub
　rtmpdump、swftools、ffmpegがないと動きません。あとPerl側の依存モジュールはFurlとMIME::Base64、Class::Accessor::Lite::Lazyくらいか。

　→ 簡易Radiko録音ツール。要swftools/rtmpdump/libxml/wget/ffmpeg/lame
　こちらの方の作ったシェルスクリプトを大いに参考にさせていただきました。

　以下、使用例。