2/26　YKMC祭り[設計実践勉強会]振り返りまとめ

1月に参加したYKMC主催の設計勉強会で行った、図書館の貸し出し機能のモデリングについての振り返りに参加した。

冒頭から濃い話が沢山出てきて、終わった頃には脳が疲弊しきっていたけど、また沢山の学びがあったので、参加できてよかった。

＊この記事では、主催者の方の許可をもらって、振り返りの中で出てきた図や振り返りの流れをまとめさせていただきました。

ドメインエキスパートと一緒にモデリングしていくなどが有効な方法では？

どのコアドメインが一番価値を生み出しているのか検討する。

その上で一番必要なドメインに高い保守性を持たせる。

古いシステムだと、システム依存の構造になってしまう。

本来システムは形を変えていくべきもの。

ビジネスは変化していくのに、システムに依存してしまっている。

特定の言語というリソースに依存しないようにすること。

負債の解消ができていない？

AS-ISで現状の把握を行い、TO-BEの目標地点へのマイルストーンとする。

TO-BEへの経路は複数ある。

名前から推論して答えるのは、名前の設計がきちんとしているから出来ること。

「この操作はこの名称のエンティティが持つべき」という観点から置くべき場所を探す

全体の関係を把握した上で、考える。

「この操作はこの属性が必要」という観点から置くべき場所を探す。

利用者が消えた時に貸し出し中手続き中カートとかだけ残るのはおかしい。

利用者がDDDでいう集約であり、外から通信できるクラス。（このパッケージ図の中で）

クラス名から属性を定義する。

属性からクラス名を定義する。

どちらか片方だけではなく、両方の面からチェックする。

複数の視点から見ることで、そのクラスが整合性が保たれているのかチェックする。

将来を見据えて汎用性の高い名前を付けると責務が広がりすぎてしまう。

DDD的に言うと、その時の責務に応じた名前を限定してつけましょうというのがある。

なにをどうする概念なのかという観点でのネーミングが望ましい名前設計

開発者の中で視点があっている状態では、（そのクラスの責務に対する理解が揃っている）、抽象度の高い名前にしてもいいかもしれないけど‥

将来的に新しい人が入ってきた場合、抽象度の高い名前にしたが故に、属性がどんどん追加されて、神クラスが出来上がってしまう可能性がある。

貸し出しが貸出明細のコンポジションになっている。

参考記事→

貸し出しのみを外部に公開して、貸し出し明細を閉じてしまう。

また、貸し出しからループは生成されるべき。

上記パッケージ図の実線が表しているのは、、貸出クラスの属性（プロパティ）が蔵書クラスを参照しているということ。強い参照。

破線が表しているのは、貸出のメソッドが蔵書クラスを参照しているということ。

メソッドは実行されたら終了するので弱い参照。