「現場で役立つシステム設計の原則」を読んでます（4-7章）

4章 ドメインモデルの考え方で設計する

まずドメインモデルはデータモデルとは異なりロジックがあると述べている。
よくあるパターンとしてデータはクラスか変数として、ロジックは関数として別々に作ってしまう。
もしくはフレームワークに合わせて適当にクラスを作成するとか。
しかしオブジェクト指向ではデータとロジックはまとめ、オブジェクトとして扱うものである。
これにより業務データとそれに関連する処理を一元化することができ、シンプルな構成になる。

またトップダウンでなくボトムアップの設計を推奨している。
一個一個の部品=ドメインオブジェクトを作り込む。
とはいえどのような部品が必要になるかは知る必要があるので業務フロー図やパッケージ図を用いておおまかな地図を書くことから始まる。
（これだけ見ると結局トップダウンじゃんという感じはするが）
結局のところ全体と部分を行ったり来たりしていくことが大事ということである。

開発を進めることで徐々にドメイン知識が身につくはずである。
そのため徐々にドメインモデルを正確なものに改善していくことができる。
「リファクタリング」でもクラスの分離や結合、移譲などの話をしているが、
これもオブジェクトの構成を改善するための手法の一つである。

新装版 リファクタリング―既存のコードを安全に改善する― (OBJECT TECHNOLOGY SERIES)

またドメインに関する語彙とドメインモデル中の変数名や関数名を一致させることでより分かりやすくなる。
ドメイン知識が少ないうちはまずは専門用語を身に着けていくと設計がしやすくなる。

データとロジックを合わせて設計をするというのはまだなれないところだが、
これが出来るとシンプルな実装に出来るかと思うので実践してみようと思う。

5章 アプリケーション機能を組み立てる

アプリケーション層のクラス=サービスクラスは複雑になりがちであるが、業務ロジックはドメイン層に書くべきである。
MVCでもfat controllerを避けるべきみたいな話があるが同様のことだと思う。
（ググったら機関車トーマスに出てくる局長のキャラクターもfat controllerと呼ばれてるらしい）
業務ロジックは出来るだけ細かくし、サービスクラスはその組み合わせを構成する。
プレゼンテーション層では入力を受け、サービスを呼び出して適用し、出力を返すだけで、ここにロジックは置いてはいけない。

またサービスクラスからデータベースの都合を切り離すために記録と参照のみを行うクラスとしてリポジトリを利用する。
具体的なデータベース操作はリポジトリ内に記述することで、サービスクラス内では記録と参照を行っているということだけがわかるようにする。

6章 データベースの設計とドメインオブジェクト

データベース設計では制約を行うことでプログラムの記述を簡単にする。
具体的にはNOT NULL制約, 一意性制約、外部キー制約である。
この辺は「データベース実践入門」にも記載があった。
（この書籍だともっと厳しい正規形についても述べている。）

理論から学ぶデータベース実践入門 ~リレーショナルモデルによる効率的なSQL (WEB+DB PRESS plus)

SQL実践入門──高速でわかりやすいクエリの書き方 (WEB+DB PRESS plus)

特に一意性制約は重視したい。テーブル内のカラムでどれが一意になる組み合わせを考え、
それを複合キーとして設定することで参照が楽になる。
個人的に最近はNoSQL(datastore)を利用する機会が多い。
そのため外部キーを利用してJOINでつなげることが少なく、使用場面を考慮したテーブル設計になっていることが多い。
それでもNOT NULL制約、一意性制約に関してはNoSQLのテーブル設計にも役立つ。

またオブジェクトとテーブルの設計は異なる点に注意すべきである。
オブジェクトはロジックを含むがテーブルはデータのみを管理する。
フレームワークによってはテーブル設計とオブジェクトが一致するような命名規則を強いるものがあるが、
このようなフレームワークは避けるべきとしている。
MVCだとmodelがリポジトリ兼ドメイン層となってしまっている。
「現場で役立つシステム設計の原則」だとJavaのSpring bootがドメイン駆動を再現しやすいとして推奨している。
僕としては制約の少ないシンプルなフレームワークを利用して必要な部分だけ利用すべきかなと思っている。

7章 画面とドメインオブジェクトの設計を連動させる

UI中に業務ロジックをおくべきでない。DDD本でもこのようなUIは「利口なUI」としてアンチパターンとしている。
また複雑な画面になってしまう場合は分離すべきである。
たとえばユーザー登録画面でも1画面にすべての項目を入力するのではなく、
いくつかのフローに分離した画面のほうが開発しやすく、ユーザ側としても使いやすい。
またユーザーの関心事に注目して設計すれば画面の内容とドメインオブジェクトが連動してくるはず。
それから画面の設計には近接、整列、対比、反復を重視すべきとしている。
これはノンデザイナーズ・デザインブックに書いてある話である。

ノンデザイナーズ・デザインブック [第4版]

ふりかえり

今まで読んできた本とのつながりが見えてきたのが良かった。
特にDB設計に関して学んできたことは変わってないなと思う。
一方でデータと業務ロジックをオブジェクトとしてまとめるということはまだ出来てないなと感じる。
また今自分が開発に携わっているシステムが、どうして今のような構成なのか、
どうしてこのようにオブジェクトを分けて設計しているのかなど、設計の意図を把握しやすくなったような気がする。

前回
woody-kawagoe.hatenadiary.jp