6/27に「BPStudy#82」の勉強会に行ってきました。
BPStudy#82 - connpass
株式会社ビープラウドが主催するWeb系技術討論の会
メモ
現実世界/モデルとコード
- もやもやした現実世界(要求)をいかに単純化してモデルにするか
- 顧客は、ありきたりなモデルでは満ち足りてないから、新しいものを作ろうとする
- モデルをどうやって動くソースコードにするか
モデリングと設計のパラダイム
- 設計とはコードの整理の仕方
画面・帳票モデル(スマートUI)
- 例:Submitのイベントハンドラに全ての処理が書かれる
- 検証
- DB登録
- etc
- 同じことを違うコードで実装したり、違うことを同じコードで実装したり
- 保守地獄
機能モデル(トランザクションスクリプト)
- 処理詳細まで落とし込んでコードに変換するだけ
- コードの重複が発生
- 変更しようとしたときに、スマートUIと同じ問題が起こる
データモデル(AcriveRecord)
- コードの重複は防げる
- ただし、テーブルと1:1にすべての処理が結び付くか?
- 例えば、消費税の端数計算はどこに置いたらいいのか?(テーブルと1:1に結びつかない)
オブジェクトモデル(ドメインモデル)
- 変更・拡張が楽になるという手応えを感じている
強調されていたこと
- 変更・成長させたい時にかかる負荷を減らすことが、正しいものを作るときに重要
- 一回きりの開発であれば、スマートUIとトランザクションスクリプトを否定しないが、ソフトウェアを成長させていこうとするならアンチパターン
三層+ドメインモデル
- プレゼンテーション層
- アプリケーション層
- データソース層
- ドメインモデルは三層から使われる(どの層にも属さない)
- ビジネスルールはドメインモデルへ
- 例えば、特定の商品だけの特別な処理
- ビジネスのルールはドメインモデルだけにあるので、重複しない
- ビジネスルールはドメインモデルへ
- 参照は一方向(双方向参照はしない)
- 繰り返し変化させる
- 実際にコードを動かそうとすると、ビジネスロジックが三層に記述されがち
- いきなりドメインモデルを実現できるわけではない。ビジネスロジックをドメインモデルに移動させることを常に継続し続ける
プロジェクトの進行モデル
プロジェクトの初日の設計
- パッケージ図とその依存関係を作成する
- この図は重要なので、プロジェクトの最後まで更新し続ける
- 依存関係がうまく引けない場合は、そこに何か問題がある
- 業務の基本構造=プログラムの基本構造であれば、業務の依存関係がプログラムの依存関係と一致している
- 保守しやすい
Q&A
- Q.インフラストラクチャのコードもドメイン層に置くのか?
- A.インフラ層の言葉で表現されるコードは、インフラストラクチャ層におく
- SQLのビジネスルールはどのフレームワークを使うかによる
- DB回りや通信回りは微妙なことが多い