勉強会はブログ書くまでが勉強会です！キリッ！
以下、乱文で失礼
「現場で役立つシステム設計の原則」を読みます！
「現場で役立つシステム設計の原則〜変更を楽で安全にするオブジェクト指向の実践技法」の読書会をします。
著者増田さんの講演を中継します
北海道で同時刻に行われる勉強会で、本書の著者である増田亨さんが講演されます。
https://devlove-sendai.doorkeeper.jp/events/63754
そのセッションを今回オンラインでつなぎます。（機材・会場の都合上、音声と資料のみの予定です。）
ネットでもかなり評判の高い本書ですが、自分も購入していて、「ふんふん、、いいね、そうだよね！」とか「ほほぉ！今更ながら知ってしまったのです！」とかウンウンうなっている所、今の現場の同僚から読書会の２回目があるとのことで、参加してきました。
現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法
- 作者: 増田亨
- 出版社/メーカー: 技術評論社
- 発売日: 2017/07/05
- メディア: Kindle版
- この商品を含むブログ (4件) を見る
今回は読書会の２回目ですが、読書会と、北海道で同じ勉強会が開催されており、その中継で著者の増田さんのこの本の苦労話を聞けると言いうお得な回です。結局は増田さんの話で終わってしまったのですが・・・^^;
増田さんの話の内容は、この著書を書くにあたり、方針としたことや、各章で苦労したこと、実はもっと書きたかったんだ！と言う事が聞けたりしました。
ネットでも言われている通り、本書はシステム設計をするにあたり読めば読むほど「至極当然ではないか？」と感じる事などが書かれています。「なーーーんだ、じゃぁ読む必要ないんじゃ？」と言われそうですが、その至極当然と言う事がいかに難しいかと言う事なのでしょう。
昔、別の勉強会で「ＡＢＣが出来ている組織」（Ａ：あたりまえのことを、Ｂ：バカになって、Ｃ：ちゃんとやる）と言う話を聞いたことがありますが、その当たり前の事がいかに難しいかと言う事なんだろうなと。
昨日＠ＩＴの講演会があり、その中で「コスト削減と品質向上」について、＠ＩＴの人がコストと品質は相反するものなのでどうすればという質問があったが、「コスト削減するには品質向上」という話があった。これは品質のＡＢＣをやれば最終的にコスト削減になるということ。
http://d.hatena.ne.jp/arcanum_jp/20090725/1248536347
ａ:あたりまえのことを
ｂ:ばかにせずに(ぼやぼやせずに)
ｃ:ちゃんとやる
今回の話の中で一番気になったのは、最後にダイクストラの構造化プログラミングに言及されていたことです。構造化プログラミング自体はＢＡＳＩＣなど、オブジェクト指向以前の言語でいかにプログラムを綺麗に書いていくという手法かと認識していましたが、増田さん曰く、
プログラムの品質を保証するのは何か？と言う問題で、それはテストである、と言われるが、でもテストとは結局はブラックボックスでの挙動を保証するものであり、確認したことは保証できるが、それ以外の事は保証できない。構造化プログラミングは実は、構造と言う面で品質を保証するものではないか？
（意訳）
と言うこと。これはなるほどなぁと思いました。自分もオブジェクト指向で書いたとしてもロジックそのものは構造化を意識しないと、読めない（読みづらい）プログラムが出来上がる。それはＤＤＤを学んだ方に言わせれば、そもそもそんなに長いものを書くのが間違っていると言われそうですが、現実問題、そのように（大人の事情で）設計されている以上、人間が認識しやすいようにするには構造や、書く塊をどうにかして認識しやすい単位にする必要がある。と思っていたから。その他のこちらが制御できる部分についてはどうでもいいのですよ。
例えばそれが本書の中では１０１ページの金額や数量などの小さな単位でもドメインに関心を持つという事で、人間がクラスと言う単位で分かりやすくするという事（構造）により品質を保証するというモノなんだろうなと。設計により人間の認識できる範囲を狭めて（人間の考える余地を無くして）認識しやすくする。そうすれば他者間でも間違いはなくなる。例えばJavaでの設計でもよくEnumを使ったりしますがあれも、入りようがない値を防ぐ、プログラミングによる間違いを防ぐ仕組み（品質の保証）であり、構造でそれを保証しているなんだろうなと
質問コーナーでは、仙台からは、実際にデータベースで地獄を見た方などの、データベースとドメインモデルの関係は？と言う事が質問されました。その一つの解としては、全てを設計するというのはあきらめて、データベースは「事実」を記録する、ドメインは処理の入る場所を、と設計部分を狭めて後回しで良い項目はいったんは無視して、設計範囲を狭めるという事で、小さく設計して育てていく、初めは枝葉な設計はあえて無視するなど、あぁ、これはイテレーションだなぁと。
現システムのデータベースを流用すると言った大人の事情なんかも、やりようはあって、参照系なんかは新システムに向いたテーブルを作って参照用のテーブルを作ってしまう、更新系なんかはログみたいな中間テーブルを作ってしまうなど色々とやりようはあるなど・・・
また、データを中心とした従来の設計はデータベースには親和性が高いが、そのデータの処理と言う面とは関係がない、データベースのER図とオブジェクト指向のクラス図は一見似ているようで親和性が高いと思わされてしまうが両者は全く別物と言う事が理解されないってのも問題なんだろうねと。それはよく言われる、画面の項目を設計すればテーブルの70%は完成したも同然と言う、なんとも勘違いな言葉も表しているのかもしれないねと・・・ツラツラと・・・思いつつ、ドメインモデル以前にデータベースと処理についてはやっぱり、境界（処理←→データベース、処理←→画面、処理←→帳票などの境界部分）が難しいんだろうなと言う印象でしたが、
最後に、勉強会に出た方が言っていたのですが、じゃぁ、練習問題って無いんですか？って要望で、これは自分も
超同意！(｀・ω・´)
って思いました。ナイス要望！
昔オブジェクト指向が普通になる前、オブジェクト倶楽部で「デザインパターンによる進化的設計」と言う
あなたの使用している電子メールは，新着のメールをどのように知らせてくれ ますか? パソコンがLANに接続されている場合，おそらく周期的に新着メール の有無をチェックし，もし到着していればパソコン上に新着メールを示すポッ プアップを表示するでしょう．
http://objectclub.jp/technicaldoc/pattern/eDWP
記事があり、簡単なプログラム例からオブジェクト指向によるデザインパターンの適用例を面白く書いたものがありましたが、そうです！これなんです！データ思考でやってきた僕らにどうやったらドメインモデル設計に慣れていけるかと言う、こういう「だんだん」変わっていく様があれば、なるほど！となっていくのではないか？と思いました。いきなり全て考えを変えるてのは難しいからね。
最後に、どんな状況でも、あなたから、今日から始められるよねって話で〆ていて、小さな部分でもやっていく事が大事と言う事でした。この辺はSIerの二次受け三次受けの方は決められる部分が無くて難しいのじゃと思ったりしますが、著者は意外と個人の裁量が反映される場所ってのはあります。それをやったらヤバい（怒られる）ポイントはあれど、逸脱したり失敗したりすることが大事と言う事でした。
まずは「自分から」です。
次回以降についても参加できたらいいなと思います。
以下、メモ。ホントにメモっすよ
