「DDD Alliance! ドメイン駆動設計をやってみた　６つの現場からの報告」に参加してきた #DDDAlliance

2015年11月10日に開催された「DDD Alliance! ドメイン駆動設計をやってみた　６つの現場からの報告」の抽選に当たったので参加してきました。

ddd-alliance.connpass.com

第一部　ビックローブでの2年間の取り組み

DDDを組織で始めるための考え方

1. DDDはじめの一歩

当時のビッグローブでは内製をしておらず外注メイン、プログラマがいないスクラムを始めた → メンバーが増え、2、3年で十数チームできた

課題：アーキテクチャ

  • 15年稼働しているシステム
  • 独自言語で書かれている(!)
  • 複数の会社に外注してた

結果: カオス!

コンテキストマップ作ってみたけどわけわかんない

スクラムでも成果でそうになかった 独自言語で人が成長しない

オブジェクト指向へ

課題: 業務ロジックの設計

  • MVCでは足りない
  • ある日：DDDがいいのではというメンバー
  • DDDおじさん(増田さん)の記事→呼んでみよう!

増田さんの言うとおりに守破離の守

作っては壊しを3人で半年

取り組んだこと

できそうな気がする → 案件探し

案件の条件

  • 「新規サービス」
  • 小さい
  • 他に影響しない
  • 納期調整可能

独自言語を書き直し機能追加も→うまくいった!

暖簾分け→育ったメンバーを別チームに配分して拡大する

時間かかるが暖簾分けおすすめ

2.組織に導入するポイント

DDDのような組織がやったことがないことをやるには

  • 小さくやる 5人くらい
  • 知っている人に教えを請う
  • 暖簾分け

重要：結果を出す

3. なぜDDDか

クリストファー・アレグザンダーの思考の軌跡より

設計の仮設：設計（デザイン）の動機は自分たち（プログラミング）の外にあるべき

DDDの価値とは

組織全体として考え方を統一する

  • サービスとコードをドメインでつなぐ → サービスを考えるようになる
  • 変化へのしなやかな対応　→ 変えることが当たり前になる

やるのは「人」

設計する人、サービスを使う人、プログラミングする人

開発メンバーの成長 道具を変えることで人は成長する アジャイル スクラムとの相性は良い

まとめ

サービスを考える人(経営者)と作る人との理解がつながる。これをしないとサービスが良くならない

キーワードは「統合」

開発現場から学んだドメイン駆動設計中心のサービス開発

www.slideshare.net

  • 現BIGLOBE社員
  • リードエンジニア（技術リーダー）

導入

  • 5チーム/30人気簿でDDD
  • 目標は100名くらいでやりたい

大事にしてること

  • DDDの価値を共有
  • 課題分析と解決に向けての行動
  • 人材育成計画
  • 新たな技術(CQRSとか)
  • 開発環境基盤の高度化

DDDを採用する価値

  • エンジニアもサービスの価値を考えないといけない
  • サービスの継続が大事(人増える、変化多い、価値が変わる) 5~10年

独自言語はサービスの維持が精一杯

DDDの価値→サービス終了までのトータルコストの削減

変更コスト、属人性を下げる→業務をコードで表す

チーム環境の考え方

立ち上げ時の心構え

  • 開発初期はわからないことだらけ
  • 方向付けのレベルの設計に留める
  • コアドメインを議論することはサービスを理解する第一歩
  • サービスの複雑性と向き合う(大事)

スプリント

  • ドメインモデルとコードを結びつける
  • モデルの持つ糸をコードに引き継ぎコードを通してモデルにフィードバックする
  • 設計者と実装者を分離しない

スプリント時の心構え

  • コアドメインの設計・実装は重点的に
  • 時間の都合上、すべての設計を完璧にはできない。
  • プルリクエストのWIPを活用して効率的にレビューする（バックログ取ってから半日でPRがでる）
  • スプリントごとに重要な概念を追加、ふような概念を削除
  • 普段の会話のぎこちなさに敏感になった
  • 書き言葉と話し言葉がずれたら警告
  • 初期のドメインモデルや実装では重要で
  • 見つけた問題を放置すると困る（特にコアドメイン）
  • ドメインモデルを改善するプロセスが大事

チームビルディング

  • 人的要因がパフォーマンスに影響
  • 相乗効果(1 + 1を3以上にする)
  • 知識（要求）は変化する。知識の共有が大事

DDDにおけるチームビルディング

「チームが機能するとはどういうことか」

チーミング

  • 学習するための組織づくり
  • 学習しながら実行する → DDDで必須

リーダーは方向性を定める

  • 絶えず少しずつ変化することが日常的
  • 双方向のフィードバック
  • 社員の判断は不可欠
  • 目標：長期的な価値を生み出すこと

チームビルディングの内容

1. 全員で設計する

  • メンバーが考える場所を作る
  • メンバーの意見を引き出す
  • メンバー間のギャップをなくす

メンバー全員が同じ地図を（ドメインモデル）を理解するため

設計の目的と効果をメンバー全員が理解して実装するため

熟練者のノウハウを経験が浅いメンバーに伝授する

2. モデリング済みの部分も積極的に改めてモデリングする

  • メンバー間で確認
  • 機能強化時、プランニング時、コードレビュー時、いつでもやる
  • 経験が浅いメンバーはモデリングする機会を増やすことが成長につながる
  • 新規加入メンバーはドメインを理解するチャンス
  • 大事：モデリングはメンバー自身に実施させる（考えをアウトプットさせる場）

結果:

  • チームの設計力が向上
  • 変更コスト、属人性が下がる
  • DDDを採用する価値を実感

まとめ

  • DDDはチームビルディング大事
  • 全員で設計に参加
  • 既存部分も設計しなおそう

開発

  • コアドメインになりそう、変更がありそうな所は積極的に分離
  • 業務を中心に添えると業務ごとにデータが増えるのが自然
  • Eventテーブル: 業務(申し込み、契約、解約など)ごとに用意。Insert中心。イベントログとしての役割。
  • Stateテーブル: 業務によってUpdate。Eventテーブルの補助としての役割。データアクセス層の関心事で利用。
  • imuttableデータモデルを使用するとNULLが減って良かった
  • アプリケーションのみでなくDBで業務ロジックを表せられた

失敗談

ドメインモデルが古い

Policyクラスの乱立

  • 業務チェックのために
  • エンティティから業務ロジックが減っていく貧血症
  • Policyパッケージを作った時点で負け

RepositoryのSaveメソッド

  • あらゆる操作をsaveメソッドのみで対応
  • BaseRepository作ってみた → カオス感Up!
  • 業務イベント事にメソッド用意したほうがシンプル

他集約のRepositoryを操作

  • アプリケーション層のコードだけでは関連する集約が把握できない
  • やめよう

SQLに業務ロジックが混在

  • はがそう
  • 主キーのみで検索してドメイン層で絞った方が良い

まとめ

  • DDD本と実践を行ったり来たりして理解を深めよう
  • サービスが存在する限り変化しつづけ、成長しつづけ、価値を届け続けるソフトウェアを作ることが大事

第二部　受託開発の現場から

ドメイン駆動設計を実践するプログラマーの悩み

  • プログラミングの面で悩んでいること
  • 今は3層レイヤとドメインロジックで構築

気をつけていること

  • モデルの歪みに気づけるか
  • 人は作りやすい方向に流れてしまう...
  • モデルにロジックを集める方向に作りやすくする

辛いこと

UIからのデータバインディング辛い

  • publicなsetterがひつよう
  • 場合でデフォルトコンストラクタ必要
  • 型のミスマッチ
  • 階層を持った多肢選択UIや一覧表入力系UI

UIすぐに変わるし辛い

バリデーション辛い

  • 型のミスマッチ
  • 意味的なチェック
  • DBを必要とするチェック
  • 限定的な文脈でのみ行われるチェック

まとめ

  • データ境界面が主に辛い
  • Javaから何かに変換するのはあまり辛くない
  • 何かからJavaに変換するのが特に辛い

ドメイン駆動設計におけるシナリオテストの活用

シナリオテストの動機

  • ウォーターフォール的にすすめていた → 最後に大量のフィードバック → 辛い
  • アジャイル的 → 毎週打ち合わせ、成果物リリース → 画面をできるだけ早く揃えたいが、出戻りをできるだけ防ぎたい

BDDでシナリオをテストコードで表せれば顧客からのフィードバックを受けやすくなるのでは → Spock採用

効果

  • 開発にリズム感でた
  • ちゃんとした実装は後回し
  • 仕様の合意でたら実装にスピード感出る
  • 声に出して読み合わせして毎週フィードバック得られる

今後

  • よりよい可読性を目指す
  • 複数モジュールやコンテキストをまたいだテストを書けるようにする
  • どこまでテスト作るかの見極め
  • 画面を作るタイミングの見極め

第三部　内製の現場から

ECサイトのリプレイスをDDDでやってみた

背景

サービスをちいさく分割したい

某殿堂の圧縮陳列(ドンドンドン・ド○キー♪)

やってみた

ドメインモデリング

  • ドメインエキスパート不在...RDBからモデリングしてしまった
  • 結果として知識を噛み砕けていないモデルを作っただけだった

実装

  • レイヤー化アーキテクチャ
  • レイヤの役割やコンテキストを意識できた
  • DDDの実感ここだけ
  • ドメインモデルをきちんと落とし込めないと意味ないと増田さんからバッサリ

結果

  • いわゆるドメインモデル貧血症に陥る
  • 振る舞いを切り捨ててしまったのでDDDを導入した意味がなかったかも
  • チームでもっと言葉を使って探求すればよかった

その後

  • DDDの普及活動（読書会）によって仲間が最近増えてきた

最後に

  • たぶんDDDに正解はない
  • チームが言葉で話して納得できたらそれが正解
  • DDD本←→実装の反復作業がより理解する近道

ガチDDDを経てDDDって何？って現場に行ったあるプログラマーのお話

www.slideshare.net

DDDとの出会い、DDDと離れて、再び導入した話

DDDって?

転職してDDDが無い環境へ

  • ロジック分かれてない、ドメインが無い
  • リファクタリングでごまかしてたが拉致があかない → 勝手にDDD
  • 1つ何か対応するたびに20以上クラスが増える、毎日嫌がらせのようなPRを出し続ける
  • 気づいたらレビューしてくれるメンバーが似た感じのコードになっていた。

DDD導入には

  • エヴァンス本や勉強会で知識高めることも大事
  • 実際に手を動かすことの方が重要かも

最後に

ドメイン駆動設計のススメ

悪しき習慣

  • 基本データ型でプログラミングする→型を独自に定義しない
  • 動いたら設計を辞める → 本当に業務をあらわせているか?
  • コードを書く前にドキュメントを準備する
  • 分析/設計/実装を別の人間がやる
  • 分析/設計/実装を別の日にやる

身に付けるべき習慣

  • 独自の型をどんどん作ろう
  • 動いてるコードの設計改善に時間をかける -- まずコードを書いて動かす -- 動いてるコードに対して議論して設計改善する
  • ドキュメントは(必要なら)コードから生成する
  • 分析/設計/実装を同じ人間がやる(鉄則!!)
  • 毎日、分析し、設計し、実装する

学び方

書籍から学ぶ

コードから学ぶ

  • 動いてるコードを対象に設計改善を議論する
  • 動いてるコードを変更する
  • 設計の違いの効果を実感する

まとめ

  • DDDやったからといってすぐ見違えるわけではない
  • DDDをやりながら実感を増やし徐々にかわっていく

最後に

おなじみケント・ベックの言葉

どんな状況でも改善できる
どんなときでも「あなた」から改善を始められる
どんなときでも「今日」から改善を始められる

リファクタリング―プログラムの体質改善テクニック (Object Technology Series)

リファクタリング―プログラムの体質改善テクニック (Object Technology Series)

  • 作者: マーチンファウラー,Martin Fowler,児玉公信,平澤章,友野晶夫,梅沢真史
  • 出版社/メーカー: ピアソンエデュケーション
  • 発売日: 2000/05
  • メディア: 単行本
  • 購入: 94人 クリック: 3,091回
  • この商品を含むブログ (312件) を見る

オブジェクト指向入門 第2版 原則・コンセプト (IT Architect’Archive クラシックモダン・コンピューティング)

オブジェクト指向入門 第2版 原則・コンセプト (IT Architect’Archive クラシックモダン・コンピューティング)

エクストリームプログラミング

エクストリームプログラミング

Scala Best Practiceの和訳を進めています

少し前からScala Best Practiceの和訳を進めていて、現在0章と1章が済んだところ。

github.com

ライセンスはCC BY 4.0だけど、一応著者本人に声かけとくかな―と思ってた矢先に、一緒に和訳してくれている知人が知らせてくれていた。

github.com

こんなことやってる、ということを同僚に伝えたらあれよあれよと各章の担当が決まり*1、大変感謝している状況なんですが、多くの人の目に触れた方がより良い翻訳になるので、ここの表現おかしくない?などの意見はドシドシご指摘ください。

*1:なお自分は全然英語が出来ず、「バンドやろうぜ!当方ボーカル」状態である

次世代 Web カンファレンス #nextwebconf に参加してきた

2015年10月18日に開催された「次世代 Web カンファレンス #nextwebconf」に参加してきました。

次世代 Web カンファレンス - connpass

server_perf

以下自分のつぶやきと参考になったツイート

server_arch

server_archでは開始早々、@yuguiさんが開発したJSON APIへの変換プロキシ生成機"grpc-gateway"の話となった。

そもそもgRPCとは、HTTP/2の利点である双方向ストリーミングや多重リクエストを扱えるRPCフレームワークであり、C、C++、Java、Go、Node.js、Python、Rubyなどの言語をサポートしている。

新しいオープン ソース HTTP/2 RPC フレームワーク、gRPC のご紹介 - Google Developer Japan Blog

ただ、gRPCはすべての言語をサポートしているわけではなく、かつHTTP/2が必須なため、これを今までのJSON API、HTTP 1.1でも動かせるようにするためのものが"grpc-gateway"とのこと。

gRPC-JSON proxy - 世界線航跡蔵

以下自分のつぶやきと参考になったツイート

standardization

(昼飯で抜けてたので途中からしか聞いていない)

以下自分のつぶやきと参考になったツイート

http2

以下自分のつぶやきと参考になったツイート

front_arch

以下自分のつぶやきと参考になったツイート

さいごに

主催してくださったJxckさんを始め、登壇された方々ありがとうございました。とても濃密でWebの未来について感じることができた1日となりました。

今回俺がいかにして転職したか晒す

9月から新しい会社で働き始めました。折角なので今回どのように転職したのかをまとめておきます。

何をつかったか

今回はWantedlyをメインに使って転職活動を進めてきました。前回の転職ではエージェントを使いましたが、今回は自分のペースで活動したかったのでエージェントは使いませんでした。

www.wantedly.com

期間・エントリー数

期間は3月~8月の間の5ヶ月間、活動しました。エントリー数は全部で6社となりました。

準備

プロフィールを書く

とりあえずWantedlyのプロフィールを埋めました。経歴、このさきやってみたいこと、作ったアプリなどは特に公開しておけばいいと思います。

履歴書・職務経歴書

企業によっては、エントリーしてすぐに履歴書・職務経歴書をメールで送ってほしいというところもありました。履歴書は、Wantedlyの「できる履歴書」で書くと写真込みでPDF出力できてすごく便利でした。

www.wantedly.com

職務経歴書版も是非欲しいですが、職務経歴書はフォーマットが様々なので厳しいのかもしれません。

企業にエントリーする

まずは1社エントリーすると良い

Wantedlyの場合、おそらく1社でもエントリーすれば最近活動のあるユーザとして企業側に伝わるようで、初エントリー後はスカウトがよく来るようになりました。*1

エントリー後の流れ

エントリー後はWantedlyのチャットでその企業の担当さんとやりとりします。 大体の流れとして、

  • 面接の日程調整
  • 履歴書・職務経歴書 → リモートで技術テスト
  • リモートで技術テスト → 面接

というケースがありました。この中ではいきなり面接というケースが一番多かったです。

福利厚生については別サイトで

Wantedlyでは、その企業がどのような活動をしているか、どのような技術を使っているかはわかりやすくなっていますが、福利厚生などがわかりにくいのでそこは別サイトに頼る必要があります。(実際に福利厚生について質問したら別サイトのリンクが渡された)

企業の規模でレスポンスに差がある

これは経験則ですが、社員数が十数名の企業はエントリーしてから数日で返信が帰ってくるのに対し、社員数3桁以上の企業は返信に2週間程度かかりました。これはその会社のエントリー数にもよると思いますが、転職活動のスケジュールを考える上で注意が必要です。

さいごに

最近自分の周りで転職を考えている人が増えてきているので自分のケースをまとめてみました。何かの参考になれば幸いです。

*1:数えてみたら16社あった

YAPC::ASIA Tokyo 2015に参加してきた #yapcasia

YAPC::ASIA Tokyo 2015

2015年8月22日に開催されたYAPC::ASIA Tokyo 2015に参加してきました。1日目は参加できず2日目のみの参加です。なお僕は初参加で、かつYAPCは今回で最後らしいです。

セッション

yapcasia.org

スピーカーのNathan LeClaireさんはDocker Machineの中の人。Polyglotとは複数言語、複数のツールを扱う人のことを指す。

今まで、エンジニアが新しい技術を学ぼうとするとき、毎回開発環境の方法を学ばなければならず、それが新しいユーザ参入の障壁となっていた。特に今のフロントエンド界隈は6ヶ月で新しい技術が生み出され(AngularJS,React.js,Grant,Gulp,etc..)、そのたびに環境構築に学習コストを払うのは辛い。

Dockerの魅力はそういった参入障壁をなくし、誰でも簡単に開発を始められるようにすること。ユーザの島と技術の島の橋渡しをする存在ということでした。

なお、質疑応答でDocker.incの中の人はほとんどがboot2dockerを使っているとのこと。

yapcasia.org

speakerdeck.com

Docker3兄弟とは、

  • Docker Machine
  • Docker Compse
  • Docker Swarm

のことを指す。(勝手に呼んでいる)

これにDocker Toolboxが加わり4兄弟になった。Docker Toolboxは3兄弟 + VirtualBox + GUIツールの全部入り。

Docker3兄弟のおかげでDockerがゆるふわに使えるようになった。開発環境では十分利用可能で、プロダクションに使うにはまだ課題があるがロードマップが提示されている。

yapcasia.org

togetter.com

歴代の実谷委員長が集まり、今までのYAPCの思い出話から、イベント運営に関するノウハウが語られました。以下内容を箇条書き。

  • 入場者数は300人から2000人
  • スポンサー数は6社から60社
  • ワイエーピーシー?ヤップク?ヤップシー。
  • ✕ 「ヤップシーアジア」◯ 「ヤップシーエイジア」
  • ライチタイムをリジェクトしたらTwitterが「お腹すいた」で溢れた
  • トーク観るのは素人
  • LTはYAPC発祥(Asiaではない)
  • 高橋メソッドもそこで生まれた
  • 大学を会場にしたいときはヒエラルキーを理解する

yapcasia.org

www.slideshare.net

mozaic.fmのJxckさんによるHTTP2のお話。

HTTP2はすでにRFCになっており、策定するフェーズから使うフェーズになっている。既にいくつかのHTTP2実装が世に出されている。

HTTP1.1はシンプルな分、これ以上速度をあげることに限界がきていた。Keep AliveやFile Concatなどの実装を駆使して対応してきたが、これらはバッドハックであり、ビルドシステムなどが複雑化していく。

HTTP2は1つのコネクション上でストリームを多重化することで、3 way handshakeが1回で済み、パフォーマンスの一番美味しいところを維持できる。

かつ、セマンティクス(各メソッドの意味とかHTTPステータスの意味とか)は維持され、下位互換も保証される。

我々はどうするべきか?

  • よく知らない/導入しない

HTTP1.1はこれからも生き続けるので問題ない

  • 理解した/導入しない

戦略としてはありだが、今後もパフォーマンスのためにバッドハックをし続けなければならない。どこかで見定める必要あり。

  • よく知らない/導入する

エコシステムの成熟しだいではあり。そもそもHTTPはよく知らなくても動くべきだし、既にクライアント(ブラウザ)は知らないうちに導入されている。(ただ、エンジニアとしてはどうなの...)

さいごに

特に何を聴くか考えずに来たけど割りとDocker寄りになったので自分でも興味があるのだろう。Dockerちゃんと勉強します。

とても素晴らしいイベントだっただけに1日しか行けなかった悔しさとこれで最後という悲しみがあります。実行員会の方々、スピーカーの方々、その他運営に関わった方々には大変感謝しております。ありがとうございました。

Photos

diffコマンドでファイルではなく標準出力を比較する(Process Substitution)

いざ使おうとして良く忘れるのでブログに書いておく。

bashやzshのProcess Substitutionを使えば、diffをファイルからではなく標準出力の結果から比較できる。(実際は/dev/fd/に一度ファイルとして吐かれるのだけど)

$ diff <(echo "hoge") <(echo "fuga")
1c1
< hoge
---
> fuga

参考:

http://tldp.org/LDP/abs/html/process-sub.html

『アジャイルサムライ横浜道場　特別編「RSGT再演 くじびきイテレーション改』 に参加してきました #agilesamurai #横浜道場

2015年5月12日に開催された『アジャイルサムライ横浜道場　特別編「RSGT再演 くじびきイテレーション改』 に参加してきました。

yokohama-dojo.doorkeeper.jp

www.slideshare.net

今回は特別回として今給黎さんを講師にお招きし、ゲームを通してスクラムを体験するというワークショップを行いました。細かいルールはスライドの方に書いてありますが、1ターンを1dayとし、1ゲームを1スプリント、場のカードをバックログに見立て、それを見ながら見積もりをします。そして手札のカードを使ってバックログを消化し、最後にふりかえりをするというスクラムの一連の流れがこのゲームに凝縮されています。

これを5セット行いますが、セットとともに追加ルールが加わります。加わるルールは以下になぞらえられたものでした。

  • 個々人が決められたタスクしかできない(単能工)
  • タスクを協業できる(協業)
  • 個々人の能力が違い、それぞれの能力をチームは把握している
  • 個々人の能力が違い、それぞれの能力をチームは把握していない

これらを通して学んだことは、

  • 決められた仕事しかできないと、スプリント内で消化できるタスクが制限される
  • 優先度が高くコストが重いタスクでも、協業できれば(タスクを分割すれば)確実に消化できるようになる
  • 個々人の能力をチームが把握していれば、見積りの精度が増す。
  • 逆に、個々人の能力をチームが把握していないと、アクシデントが起こる可能性が増す(見積もりを予測しにくくなる)

といったことでした。事実、僕らのチーム*1は能力を把握していないときの見積もりのブレが1、把握しているときが5と顕著に現れました。

さいごに

今回のワークショップはとても白熱し、たのしくスクラムが学べたかと思います。 講師をしていただいた今給黎さん、スタッフの方々、参加された方々ありがとうございました。

*1:チーム名は「Dieふごう」にしました