name: centering layout: true class: center, middle --- name: coverpage # 俺流DDD # "データの向こう側"へ 　 　 　 Masayoshi Nomura / @nmrmsys　 　 2019/12/27 年忘れLT宴会in新大阪 ＜第76回IT勉強宴会＞ --- layout: false ## 自己紹介 .introduce-left[ ### 　■ なまえ： 野村 昌由 ### 　■ 業務システム開発</br>　　とインフラ業 ### 　■ 基盤構築・設計開発・運用</br>　　直近まで引き籠ってましたが</br>　　ようやく社会復帰</br>　　 ] .introduce-right[ .center[ [](https://nmrmsys.github.io/) ### 　@nmrmsys ] ] ??? 本名のローマ字綴りを子音だけにしたもの、アバターは Tim O'Reillyさん Web2.0 --- class: center ## ここ一年位、業務データ処理の</br>ドメインモデルってのを考えてまして  --- class: center ## 最終的にたどり着いたのがここでした  --- class: center ## それで作ってみたのがこれで [](https://github.com/nmrmsys/data-domain-driver) ### サーバーサイドJSでストプロを書いて実行するライブラリ --- class: center ## 強力なドメインモデルの力というのは  ## 中を見なくても何が書いてあるか分かる ??? ここに来てる方の年代なら特に --- ## フォルダファイル構成と設定ファイル  ## ddd直下がデフォルトデータドメイン ??? database-jsというよく出来たデータアクセス抽象化ライブラリでメジャーなDBは大体使える</br> ドメイン指定は最初、管理サイト向けadmin等を考えていたが、DCIのCをここにしても良さそう</br> ドメインがフォルダになってるので / 区切りで無限に階層を設ける事が可能っちゃ可能 --- ## なぜ、ストアドでは無いのか？ - ## 各DBMSごとの方言が多過ぎる ### PL/SQL,T-SQL, pgSQL, etc... - ## 使用を想定しているWAFの少なさ ### PHP/Laravelで作ろうとしてPDOで積んだMARSとか - ## デプロイ手順が煩雑になる辛み ### 依存関係があるストプロを何回もコンパイルするやつ ??? ストアドはスケールアウトしない問題はそもそも更新RDBMSがSPOFなのでどうにもならない --- ## なぜ、JavaScriptなのか？ - ## 複数言語のスイッチングコスト ### 実際やってみて同じ言語で書けるのは正直楽だった - ## ローカル開発環境構築の手軽さ ### Node.jsさえインストールしとけばOK、サーバ構築不要 - ## フロント/バックのコード共有 ### データ処理、ユーティリティ関連なら結構使い回せる ??? 今年の初めくらいにGUIで業務システム開発できるPaaSでクライアント/サーバスクリプトが JS（サーバサイドはRhino）なのを使ってみて、そこは良かった。 --- class: center ## という事でProcedureの中身がこれ  ## あれ？SQLはどこにいったの？ --- class: center ## sql-behindという仕掛けで別ファイルに  ## こうしておくと入力補完も可能で快適 --- class: center ## 関数や別DBやWebAPIを呼び出したり  ## 最後に結果コードと結果セットを返す ### ※実際の開発時には処理名と関数名を工夫する事が肝要で</br>大体は業務機能ID+[画面帳票枝番]+操作アクション名 ??? callFunctionで呼んでる共通関数が真のドメインロジック</br> 共通的なパラメータバリデーションや判定ロジック、処理ロジック等を共通関数化する --- ## 業務データ処理にドメイン特化する事で</br>記述を定型化、抽象度の高い操作が可能 - ## 結果セット(ResultSet) ### 表データを保持、行カーソル移動、フィールド値get/set</br>行追加、copy/clone、rowsプロパティ経由でJSON直接編集</br>lodash,alasql等の汎用データ操作ライブラリが利用可能</br>今後データ型に応じたヘルパメソッド等を追加予定 - ## データセット(DataSet) ### スカラ値とResultSetの連想配列、プロシージャの戻り値</br>toJSON()メソッドでヘッダ/明細データを直接Viewに展開 ## 便利メソッドもこれらに色々生やし放題 --- class: center ### lodashはgroupByで挫折、alasqlの何でもあり感がヤバイ  ### DataSet.toJSONメソッドでDDDの集約の様な形式が指定可 --- class: center ## クエリビルダは1テーブルだけでよい  ## 現行WAFは何故コードで書きたがる？ --- ## たぶんORMのモデルがスキーマ定義に</br>なっているのも同根なのだと思われる</br>データモデルは単なるストレージ理論 ## DBA観点ではスキーマ定義、変更定義が</br>コードなのは実はかなり不便である ## スキーマ定義を使った自動生成ツールや</br>データディクショナリは大規模では必須 ## 今考えてる欲しいDBマイグレツールは</br>変更定義からalter半自動生成しておいて</br>それを編集後コミットver管理するもの --- ## 同じ事はDDDにも言えて現行のDDDは</br>データアクセスごとにモデルクラスが</br>必要でそれを本当に全て手作りする？ ## 適用範囲を限定出来ないのが最大の不満</br>重要じゃないモデルも同等に扱わなきゃ</br>ならないってのがDDDのつらい所だ ## 適切な名前付け/機能分割/統合というのはある程度スキルが必要だし労力を伴う</br>開発メンバー全員にそれを要求するのは</br>コスパが合わないし練習は個人PJでヨロ ??? 今回Javaと.NetのFW調べててEFにDBファースト、MDLファースト、CODEファーストとありピンときました</br> DDDってドメイン駆動ドメイン駆動言ってますが、ドメインモデル駆動では無くドメインコード駆動では？</br> ORMの採用でモデルを中心に据えると、そうならざるを得ないのはまあわかる</br> DDDにはドメインクラスに機能が統合されるので分業どうする問題もある</br> パーシャルクラスで分割するのが定石みたいだが、そうする名前付けに悩む</br> DCIでやる？もうちょい細かくAction単位ぐらいで分割しておきたい</br> 値オブジェクトについては、CodeKata 型 過多！</br> そもそも静的型付けでチェックできる内容をあまり信用していないし</br> 投入する労力に見合って無いと思ってる。それをするぐらいなら</br> 必要な所だけテストを流す様にしたい、その方が包括的ですしおすし --- class: center ## DOAでのデータモデルは情報管理体系、</br>帳簿組織、つまり元からドメインモデル [](http://blog.benkyoenkai.org/2012/06/) ## 三要素分析法のデータモデル図はDEと</br>実際のデータ例を見て話せるのが良い ??? ドメインモデルのレイヤーレベル 概念/論理/物理データモデル --- class: center ### とはいえDOAで動的制御が欲しい場合も無いわけでは無い</br>そんな時の為に DAM（Dataset Anything Mapping）を御用意  ### JSを採用した余禄でドメインモデルの</br>フロント利用の可能性が見えてきたかも --- ## フューチャーワークス！ - ## 前述のDBマイグレーションツール ### データドメインの設定を元に ddd migrate するみたいなの - ## パラメータのバリデーション機能 ### ストアドのパラメータ定義風、エラー返却の仕組みも考える - ## テスティングフレームワーク対応 ### テストデータのセットアップ、SQL実行結果の差し替え等 ??? 俺流DDDは昔杉本さんがDDDの拡張可能性であげてたリレーショナルモデル/DSLタイプのモダンなDOAのソリューションで</br> データドメインというメタなドメインを設ける事と抽象データ構造からオブジェクトモデルへの変換機構により</br> O/Rマッピングのインピーダンスミスマッチ無しに業務データ処理を行い、動的制御も実現するナイスなDSLレイヤです。