システム開発で思うところ

Javaで主にシステム開発をしながら思うところをツラツラを綴る。主に自分向けのメモ。EE関連の情報が少なく自分自身がそういう情報があったら良いなぁということで他の人の参考になれば幸い

DDD Alliance! 現場で役立つシステム設計の原則 Night! に参加してきました

ddd-alliance.connpass.com

書評も書かせていただいた「現場で役立つシステム設計の原則 」の著者である増田さん(@masuda220 ‏)の本には書けなかったこと、というのを聞いてきました。

2017/08/30(水) DDD Alliance! 現場で役立つシステム設計の原則 Night! 〜「現場で役立つシステム設計の原則」刊行記念!〜 #DDDAlliance - Togetterまとめ

vermeer.hatenablog.jp

会の内容としては、半分書評LT、半分増田さんのお話という構成でした。

書評LT*1

www.slideshare.net

www.slideshare.net

speakerdeck.com

speakerdeck.com

www.slideshare.net

LTそのものへの感想というのは、ちょっと難しいのですが、書籍の礼賛に終始することなく、これは良い、これはどうだろう?とそれぞれのスピーカーの経験を感じられるものでとても良かったと思います。

Java勢としては @irofさんの登場が個人的に嬉しかったですね*2。あと「この本は読みやすいし、そうそうと分かった気になってしまう。でもそれだと良くない。ちゃんと自分で読み込まないとダメ」というのは同意です。*3

本に書かなかったこと(増田さんより)

www.slideshare.net

全般

執筆にあたって「自分のやっていないことを書かない」を踏まえていたとのこと。そうなんですよね、机上の空論ではなく実践の足跡を記した書籍なので 読みやすいんですよね。

テストは?

私はテストを書いていない

潔い解答でした(笑)。

ちゃんとテストはやるよ(笑)

E2Eで(ヒューリスティックテストを十分やって)品質は担保しているとの見解でした。要件の充足という意味だと それも解なんですよね。私も自分のシステム(分析・設計・実装・利用が私だけ)だと状態遷移図くらいを書いて、状態整理をしたら、あとはドキュメント作っていないですし。それが良いか悪いか、については契約云々があるので一概に正しいというつもりはありませんが、面倒なドキュメントを作らないで済むなら作りたくはないというのは本音です。

増田さんも そういう人なのかもしれませんが、私がまだSIerだったころ「あなたがシステムに触れるとバグが出る!!触らないでください!!」とメンバーに良く言われました。「いや、これが僕のお仕事なので…」といって問答無用でバグを検出しまくっていましたが(笑)。

リファクタリングの邪魔に…

ここは難しいところですが、リファクタリングを安全にするためにはテストがあると安心なんだけど、内部構造を大幅に見直すレベルのことをやっているときにテストコードがあると、テストコードメンテナンスで工数が結構必要になるんですよね。私なりの落としどころはtwitterでも言ったのですが

なんですよね。

そういうことを踏まえつつ、網羅性の担保をすべきかどうかは別にして、E2Eのテストツールについては、上手に導入できたら内部実装のリファクタリングも やりやすくなるから良いかもしれませんね*4

Entity、Aggregate、Repository、Factoryは?

DDD本ではないので…

そうですね。簡易DDD本ではなく、あくまで「増田さんの足跡と今の整理」というスタンスの書籍なので。個人的には掘り下げたらもっと面白かったかもなぁ、と思うところもありますが、過去のスライドで補完しているので、これはこれで1つの整理かな、と思います。

サービスの固有名詞はユビキタス言語にすべき?

コードの意図の説明に有効だったら

すべき、という制限事項というよりも「それが一番わかりやすかったら、その言葉を使うのが一番いい。一番わかりやすい言葉でサービスを構築するのがいい」ということを おっしゃっていたように思います。

文字列はプレゼンテーションの関心事では?

関心事は近くにあったら変更しやすい

終始書籍でも関心事と実装の距離感については扱っていたように思います。これは賛否あるところだとは思いますが、実際のところ @nunulkさんも言っていましたが、私もcssのclassをドメイン的なクラスに実装していて、見通しは良いと個人的には思っています。

国際化対応は?

要件が発生していないし仕組みでそこまで負担なく対応もできると思っている

自分がやっていないことを、さもやっているようには言わない、という指針通りというところでしょうか。個人的には「国際化対応も加味した仕組みで構築されている」という響きに惹かれてしまいますが、国際化対応をすることが常に正しいというのは確かに偏っているというか教科書的かもしれないという考え方もあるかもしれないですね。初回リリースのサービス利用ターゲットが日本人を想定していて、その上で評価が良かったら、国際化対応を別スプリントで実施するというのも1つの考え方かもしれません。少なくとも日本語対応のみに絞れは、その分、開発スピードは早くなるので。あと、増田さんが言っていたように「表示文言のみの変更」であれば、業務ロジックの変更とは異なり シンプルなので ドメイン破壊は起きえないでしょう。そういう割り切りもありますよ、というところでしょうか。

SQLでupdateしないの?

どっちにしても過去の事実は「消えている」よ

むしろ更新は不自然とすら仰っていました。トランザクション内での振る舞いという意味だと、そうなんですよねぇ。ダーディーリードなど どうなるんだろう?と、実装依存で気になるところが無いわけではないけれど、そのあたりについて、私はそこまで詳しくないので なんとも言えないところです。

おそらく許容されないと思いますが、後述で紹介する奥野さんの話を聞いたときに「ん?ってことは削除も更新も事実の追記なわけだから、DBへの操作はインサートだけにすべきってことかな?」とすら思いました。ちなみに容量と性能に問題が無ければ、今でも そう思っています。

NotNull縛りって厳しくない?

RDBの思想としてはNullは正しくないよ

リレーショナルで考えると、そうなるんだろうなぁ、と私も思います。ある時点までなかった関連(つまりNull)を持ち込むのは良くないっていうのは 以前 セミナーで奥野 幹也さんが言っていて それが設計原則ではあるんですよね。少なくとも私は そう理解しました。新たな関心事の追加というのであれば、カラム(要素)の追加ではなく、テーブル(関心事)の追加になりますよね、という整理です。

www.slideshare.net

join書こうよ・書けるようになろうよ・IDEで楽もできるよ

たぶん、書かない・書けないということを前提に増田さんに質問をぶつけたわけではないと、私は思っています。指摘された方はJoinのコストのことを気にされていたのではないかな?と思います。私としては「非正規化は性能問題が観察されてからで良いと思う」という意見です。追加したい関心事が本来は存在すべき情報だったけど漏れていたということとであればカラム追加(つまりデフォルト値がある)、そうではなく新たな概念であればテーブル追加というのが私の理解です。少なくとも「たった1つの要素で1対1だからカラム追加で良いよね」ということであれば、テーブルの面積が大きくなりやすいアンチパターンな気がします。「たったこれくらい」はアリの穴の香りがするフレーズと思っています。

RestAPI細かすぎ

最小単位を作る原則の徹底

役割がシンプルな部品を作ることと、部品の組み合わせによりサービスを構築することがあるとしたら、まず前者を満たしましょうというのが、書籍において統一した思想というところでしょうか。WebAPIは外部インターフェースなので個人的には最小単位の担保はサービス側で良いかなぁという印象ですが実経験が数少ないので何とも言えません。ただ最小単位でAPIを作っておき、利用側からの性能面や利便性の具体的な要望に応じて組み合わせるという設計思想であれば「良かれと思って作ったけれど使われないサービス」は少なくなるかな、とは思います。

ドメインエキスパートとの会話は難しい

そもそも難しい。いないこともある。

別にDDDに限らず、アジャイルウォーターフォールに限らず、エキスパートは忙しいので会話することは難しいし、新しいサービスだったらエキスパートすらいないというのは納得(新しくなくてもいないこともある)。エキスパートがいないことを前提に振る舞う方が現実的というのも納得。

プロト操作はユーザーにとって嬉しいことになっている?

プロトを操作してもらうことは、開発側による仕様確認のお願い事ではなく、「触りたいな」「これが実現されたら、〇〇が良くなるだろうな」ということを早く体験したいとユーザー自身が思っていますか?ということかな。

書籍の内容は現場で生かせそう?

75%が好意的なのに驚き

121名のアンケートで75%が好意的だったのは驚きだったとのことです。書籍による紹介が「原理原則はこうであり、それ以外はダメ」というような大上段に構えたものではなく「このくらいからなら、できるかも」とイメージしやすい書籍だったと思います。*5

データベース中心(発言力大)だとDDDは難しい?

難しいかもしれないですね

そうなんですね。まだ 私は その違いが分かっていないようです。似て非なるとは思いますが、値オブジェクトなど踏み込めるところもあるかな?とは思いますが、たぶん、そういうところではないんでしょうね。

まとまったサンプルありますか?

実験場所があります。

実験場所ですので、これが正解というわけではありませんよ。

GitHub - system-sekkei/isolating-the-domain: Spring Boot : gradle, Spring MVC, Thymeleaf, MyBatis and Spring Security sample

増田さんが心掛けていること

小さな実験をする

失敗をする方が多いからこそ、小さな実験をしていきましょう。無駄なことはありませんよ。

やりすぎてみる

@irofさんがやったみたいに、色々とやりすぎくらいのことをやってみたら分かってくることもあります。

時間はかかる、小分けに・少しずつ

簡単にフィードバックや結果が出ると思わないこと。自分自身も含めて、周囲も変化するためには時間が必要。

自分自身も少しずつ変っているもの。

成果物(コード)で測定を。昨日のコードよりも今日のコードの方が良くなっていることを実感できていますか?

信頼される人になろう

裁量範囲が広くなるのは良いこと。

QA

テスト実装無しでリファクタリングって大丈夫ですか?

上述(リファクタリングの邪魔に…)の通り。

値オブジェクトって他のシステムでも流用できるのでは?

経験的に言えるのは意外と完全一致というのは少ないと思うということ。似て非なるものなので、それだったら流用など考えずに その場その場で作った方が良い。

Entityについてもう少し話を…

Entityは2つの関心事(識別・集約ルート)がある。識別はDBの主キーという意味ではなく人の関心事の発見という意味で大事。集約ルートについては、なんでもかんでも1つに集約するのは反対。(関連によって分割するのが大事?)

数値・数量の計算の流用は?

値オブジェクトではなく、類似計算ロジックの共通化については あまりしていない。コードの重複を気にしすぎずベタで実装している。(「ロジックの重複の排除」よりも「ドメインの重複の排除」に注力しているということでしょうか?)

ドメインエキスパートはプロダクトが分かっているわけでない。落としどころは?

まず、一応、1つに集約しているインターフェース(なんでも管理画面)については分割を提案する。その上で見えるところ(外部インターフェース)はドメインエキスパートの考えを優先しても、バックヤードのサービスを細かく分割するなどしてバランスをとっている。

手続き型からオブジェクト指向に思考を切り替える方策は?

計算ロジックを値とロジックで1つにまとめて外に出す、というように小さいまとまりを少しずつクラスにして外に出すことを繰り返していくと徐々にコードが変わってくる。 また、変更の単位に注目して、それをドメインとして まとめるところを繰り返していくと良いのでは?

お勧め本の紹介

今回のセミナーの趣旨とはずれますが、この書籍が面白かった方や「システム開発かぁ、一通りプログラムは書けるようになったけど、さて…」という方に私のお勧めの書籍を紹介しておこうと思います。

以前の記事になりますが、若手の方が目を通しておいたらよろしいのでは?と思う書籍です。

vermeer.hatenablog.jp

これに追加して、悶々と考えるネタになる本として、以下が個人的にお勧めです。私自身が開発プロセスというチームにいたときに、システムアーキテクトってなんなんだろう?どういうことを考えないといけないんだろう?フレームワークってどうやって考えていくものなんだろう?と思ったときに手にした本です。正直、好みの分かれる本だと思います。

著者の萩原正義さんのお話をJJUG CCC 2013 Fall(R1-4 分散データ技術の再考)にて聞いたことがあります*6。すごく難しかったです。でも聞いているだけでなんだか賢くなった気になりました(笑)

さいごに

増田さんにご挨拶できて良かったです。自分の書評を改めて読んで少々突っかかり気味な表現など失礼なところもあったと思っていて せめて得体のしれない匿名な状態は解消をしておきたかったので。

あと今回の会には全く関係ないのですが、学生時代の先輩に偶然会ったのには驚きました。卒業以来くらいになるでしょうか。会計システムの会社に就職をされたのは記憶していたので、今もそっち系なのかな?と思いましたが、twitterMotohiro Imura (@imunew) | Twitter)を拝見させていただいたところ、かなり毛色の違う分野のようです。そして結構コアな感じのことをされているようで凄いと思います。

良い刺激を受けた日になりました。いやー、良い日でした!

*1:公開されている資料で、私が見つけたもののみです

*2:私は、@irofさんといえば「コードは読み物」というフレーズとともにインプットされています

*3:ちなみに、私も夏の実家への帰省の往復で2回読んで、書評にあたって付けた付箋のところを読んで、みたいなことをしました。

*4:E2Eテストツールを使ったことはないので塩梅が分かりませんが、網羅性の保証をすべてE2Eテストツールで満たそうとすると、それはそれで地獄が待っている気がします

*5:少なくとも鈍器こと エヴァンスDDD本は…

*6:実際には、ずいぶん後から気が付いたことなのですが。本棚の整理をしている時に「あれ?この名前はどこかで見たことがある気がする」と調べたら「あーあの人か!」と。