セミナーを終えて、今後意識しようと思ったこと
- 新しいことをやるには、まず小さく始める。
- ビジネスルール、ビジネス戦略、ドメインオブジェクト、ドメインモデルの4象限を行ったり来たりしてよいドメインモデルを探求してゆく。
- ステークホルダーと共通認識を得るための言葉（ユビキタス言語）を育ててゆく。認識が取れずに重大障害になることがあるので、特にビジネスサイドとITサイドでの認識合わせは意味がある。
本文
参加イベント概要はこちら。
今までスクリプト言語ばかり触ってきて、静的型付け言語はJavaを新人研修で少しだけ、って感じだったので、今日の話は目から鱗だった。
静的型付け言語にアレルギーを持っていたけど、一気に払拭された気分だ。
ビジネスに必要なデータを「型」として定義し、データの種類とその有効範囲、そしてデータへの操作も含めて記述する。そうすることで、ビジネスルールをソースコードに表明できる。可視化できるのだ。
最初は「レガシーをぶっつぶせ！」なんて煽り気味のタイトルに惹かれたけれど、たまたま今月から入ったプロジェクトが正にレガシーの嵐で共感しきりだった。
なんせ現場はドキュメントが全く無く、担当者任せの秘伝のタレコードだらけ。
ビジネスロジックとI/Oロジックがごっちゃになった10000行のグローバル変数まみれのスクリプトコードというシロモノだ。これは胃が痛い。
だから、型としてコードにビジネスルールを記述できるのはとても良い方法だ。
プログラムの意図しないデータパターンを排除して組合せ爆発を回避できる。
テストコードの数も減らせる。
ソフトウェアの根本にある複雑さというのは、ソフトウェアが表現しているドメイン（ビジネスそのもの）が複雑だから起きるもの。だからココに振り切ってドメインロジックを複雑にしないようにすることがカギになるという。
ビジネスは、ルールの適用条件による条件分岐がコアとなる複雑さだ。単に、扱うデータ量が増えただとかいった類のものは、処理が面倒になるかもしれないが複雑というわけではないのだ。
そう、一律定時ではなくてフレックスタイムを導入しようとか、テレワークを導入しようだとか、そういった「条件分岐」がソフトウェアの複雑さを加速させる。
こういった複雑なビジネスルールを、ドメインオブジェクトやドメインモデルといった形で整理できれば、とても面白いことになりそうだ。
データモデリングと同じような感じだ。
いままで、ただただ面倒だと思っていた、年末調整や確定申告、標準報酬月額の集計、その他沢山の役所対応をするときに、読むのを躊躇っていた超絶に複雑な手引書を、これからはドメインモデリングのトレーニングとして使ってみよう。楽しくなるかもしれない。
登壇者の人たちが、現場でもがいた知見を展開してくれたことが、ただ有り難かった。
最初はどこか、「やっぱり大手企業は凄い人たちが揃ってるから出来るんだろーな」と、どこか遠い国の話のような、そんな感じで聞いていた。
でもセミナーの最後に主催の安西さんがこう言った。
セミナーでの話は、言語化された整理された話。最初からうまくいったように見えるが、そんなことはない。みんな泥にまみれてきた。だからいま現場で泥沼でもがいていて、なんとかしようとしている経験こそが大切なものなので頑張ってください。一緒にがんばりましょう
だから自分も頑張ろうと思う。