Interactive

モジュール設計

モジュールは、製品の中で役割を持つ部品のまとまりです。弊社では、長く使い続ける製品を、一つの機能の変更が別の機能へ広がりにくい構造にします。修正のたびに確認する範囲を抑え、担当者が変わっても影響を追えるようにするためです。

変更は依存のつながりを伝わる

どこまで一緒に変わるかを確かめる

予約、会員、支払いなど、製品の中には違う理由で変わる部分があります。今後増やす予定の機能や、別の担当者が管理する範囲を伝えると、分け方を判断する前提になります。ファイル数を増やすこと自体を目的にせず、今回の変更がどこへ影響するかを説明してもらいます。

プロンプトの例
予約の仕組みを変えたとき、会員情報や支払いにも影響する?一緒に確認する必要がある範囲を説明して

修正が続く製品で見直す

機能を追加するほど、最初の分け方が合わなくなる場合があります。一部を直すだけなのに毎回広い範囲を確認しているなら、構造を見直す理由になります。改善は通常の修正へ混ぜず、範囲を決めて依頼します。

プロンプトの例
この製品で、一つの修正が広い範囲へ影響する箇所を挙げて。分け直す必要がある理由も説明して。変更はまだしないで

コードの配置と分割規約はプログラミング、部品同士の関係はアーキテクチャ、業務ごとの分け方は境界づけられたコンテキストで扱います。繰り返す形が定まった後は、構造を規約にすることで、同じ作り方を次の変更でも使える状態にします。