makotan _at_ gmail dot com

DDDと伝票モデルとときどきburix

amazonで五つ星の エリック・エヴァンスのドメイン駆動設計を読んだ時、伝票モデルとDDDの関連とか色々考えてたので過去をふりかえったり色々しながらすこしネタばらし


伝票モデルを理解するには多分過去を知るのが良いんだろうなぁと思うので、古い話から・・・
むかしむかしあるところに会議室がありまして、そこで繰り広げられてのはドメインモデルvsDOA
まこたんはどっちでも良いんだけど、「ある人なら100点だけど別の人が40点しかとれない技術より、だれがやっても70点超えれる技術が技術としては良いと思う」っていう理由からどっちかといえばDOA（でも実装はOOP）を選択
あっ、ちなみにある会議室で繰り広げられてた議論は基本的に見てただけです・・・文章長かったし
どっちかといえばDOAが良いとは言いつつDOAには不満もあって、RDB全盛期の時代にRDBが無い頃の設計技術を使うっておかしくない？っていうか、それってまるでOOPの詳細設計書をフローチャートで書いてる感じしない？ってwww
なので、その頃からDOAの手法そのものというよりも基礎的な考え方の「データ」と「プロセス」を尊重してたって感じ


そこからT字形やら色々知っていくとデータモデルはもう誰でも出来るだろうからERでとりあえずは良くて、問題はプロセス(プログラム)の方にあるって思った訳ですね。
プロセスというよりも、テーブルに内蔵されてるフラグ管理とフラグが原因のIF文。
この辺からはまこたんを知ってる人なら多分知ってるぶりのネタに話が繋がり始めるわけで・・・
ぶりは始めから(ハマチの頃から)プログラムからIF文を排除することを最大の目的に計画が始まって、ぶりの基本的な考え方は「伝票転がしモデル」最終的にはワークステートエンジンって名前が付けられたと。
ワークフローエンジンはデータの管理と状態遷移とそれらの管理機能が込みなので、間違えられにくい様に名前を付けました。って程度の感じ


実際に今のぶりを使えばプログラムからIFを取り除く事に成功してると思うんだけど、エンジニアは欲深い生き物でもっと楽したいよね〜〜って考える訳ですね。
IFは取り除いたら次は・・・当然データモデル。
必要な画面数はぶりのActivityで判るからあとは画面とデータのやり取りをどうやって楽にするか！
というよりも、データモデルの設計手法がT字形もERDレッスンも手順がめんどくさいと。というかERモデルなんて書きたくね〜〜！みたいな感じになったんですね〜
いっそのこと画面の情報をそのままHTMLでDBにつっこんで全文検索で引っ張れば・・・なんて事を考えるくらいにERモデルを作りたくなくて仕方なかったwww


そんなこんなしてるとABDが生まれたりしてその実装方面のアイデアを思いっきりパクりつつ作ったのがBurixの初代
ABDそのものは使わない(BuriのProcessの中にActivityがあるのにActivity Baseって意味判んないしwww)方針だったけど、初代は未来を感じさせるには十分だった。
この頃にほぼ出来たのが伝票モデルの基本的なアイデア。この時点でコードレベルでは「Denpyo」ってBeanがあったりしてDenpyoの状態遷移をBuriが担当する。って形が出来たのもこの頃
問題があるとすると・・・ERD書いてるし！！ABDのめんどくさい部分がそのまま出てるので実装まで含めいろいろと面倒


やっぱりERD書きたくないし、もっと楽したいしなぁ〜
という流れで限りなく普通のテーブルモデルに近づけた(同じだとは言わない)のがBurix2と呼ばれて、表向きギョイゾーって名前になったあれ。


で、Burix2って一体なんだったの？？
やっと本題プロローグ
Burix2を簡単に表現すると「仕様を決めるところ、設計、画面、ソースコード、SQLの全てで伝票(Denpyo)が使える仕組み」
仕様を決めるときには扱っている情報を伝票としてみなして、状態遷移とその時々で扱う情報やエラーチェック方法を追加すればOK！
設計は自動生成できないところや本当に手でかく必要のあるロジック部分を決める。その場合にもどの伝票を扱うのかで話が片付く
画面は基本的にBuriのActivityに紐づくのであまりやる事が無い・・・特殊な画面だけ自作。その場合にもDenpyoが扱えるので問題無し。
ほとんどのSQLは手書きする必要が無い(ほぼ自動生成だけで片付くから)けど、仮にSQLを手作りする場合もViewとして用意したDenpyoを扱えるので問題無し
当然、テーブルは可能な限り意識したくないのでERDを手書きする必要なんてなし。ちなみにテーブルに必要そうなIndexも自動生成してたwww
こんな風に、全ての開発行程で伝票を扱う仕組みがBurixシリーズの最大の特徴
まぁBurix2も完璧とは言い難い部分があったので実際にはBurix3の計画もあったりして・・・そんなこんなしてると２年と１ヶ月前の状況になりましたとさ。
ちなみにBurix3が目指してたのは、データモデルを一般的なモデルへ変更＆本気で使って判ったBurix2の面倒なところの改善＆SQL実行効率の改善がメインだったんだけどなぁ〜
余談はさておき、単一のモデルで単語を統一しつつ、単純な手作業(と手作りすると間違えそうな部分)を徹底的に自動化していったのがBurixでした。
結果的にプログラムする人の作業のほとんどは、その会社の特徴的なロジックの実装と、こだわりの画面や帳票作りと、"設計"が間違えてない事を確認するテストと、凝ったSQLの作成でほぼ終わり。


DDDと伝票モデルの関係
短いけどここが本題
ドメインモデルはドメインエキスパートとチームメンバ全員が使用する言語やモデルが必要、伝票モデルで言うと伝票とその状態遷移
そのモデルと実装を結びつける物が必要、伝票モデルとBurixで言えばDenpyo
コアドメインは「ユーザが扱いたいと思う伝票と状態遷移」、それ以外はざっくり伝票を作って決まりきった状態遷移を割り当てて終わり。
伝票は一般的な業務に普通に存在しているはずなので、ドメインモデルを蒸留するみたいな作業はあんまり必要ない。(既にシステム化してたら伝票の抽出が必要)
さらに、既存知識が伝票という形なら抽出し易いし、かなり一般的に存在してる
しかも伝票は紙やExcelが元になるので物理的なイメージが出来易い(四角と線と矢印かかれてもすぐには理解できないしね)
という風にマッピングしていくと、元々はDOAから出発してなが〜〜〜〜〜〜〜〜〜〜〜い旅をした結果出来た伝票モデルというのは実はDDDと同じ方向を向いてたんだなと。
RDBも含めてモデルの中に組み込んでる分、業務システム用途としては伝票モデルの方がちょっと良いかも〜
ただ、業務システムに分類されないタイプのアプリケーションなら無理に伝票モデルで作るより自分でドメインモデルを作った方が絶対に良いのは間違いないです。(組み込み系とか画像処理とか３Dとか・・・)


おまけ
最近の伝票モデルの状況は、伝票モデルをもっといろんな種類のシステムへ適用し易くなる様に深化させていってるところ。
各種実装はサラリーマンなのでほぼ無理！