ソフトウェア設計は、「誰がどこまで考えるか」を決める仕事である - 変数名からDDD、DB設計、マイクロサービス、組織構造までを同じ枠組みでソフトウェア開発には、多くの設計原則があります。 わかりやすい変数名を付ける 関数を小さくする 単一責任にする 凝集度を高くする 結合度を低くする 情報を隠蔽する DBを正規化する ドメインの言葉を使う Bounded Contextを分ける モノリスとマイクロサービスを使い分ける チームの責任範囲を明確にする それぞれに歴史があり、説明の仕方も違います。 しかし、実際に設計していると、こういう疑問が出てきます。 「関数は、どのくらいの大きさなら小さいのか」 「クラスは、何個の責務までなら持ってよいのか」 「テーブルは、どこまで分けるべきなのか」 「一つのサービスが大きすぎるとは、どういう状態なのか」 「マイクロサービスに分ければ、本当に変更しやすくなるのか」 「Bounded Contextは、何を境界にして分ければよいのか」 設計原則を知っていても、実際の境界は自動的には決まりません。
