パッケージ原則とは？？

はじめに

初めまして、東京都内でエンジニアをしています。
最近は実務にも慣れて、実装の速度が上がったり、コードを書くことにも得意になってきました。
しかし、より良いコードを書くためには「アーキテクチャ」に関する知識が必要であり、学ばないとこれ以上の成長は見込めないと思い学ぶことにしました。
今回はアーキテクチャを設計するにあたり、必要な知識であるパッケージの分割方法についての原則「パッケージ原則」についてまとめます。
前提となる知識：https://zenn.dev/shundahoy/scraps/a5f52e87480127

パッケージ原則とは

パッケージ原則は、ソフトウェアの部品を整理するルールのようなものです。
ソフトウェアを構成する部品（モジュールやコンポーネント）を適切にまとめることで、開発や管理がスムーズになります。つまり、関連する部品は一緒に、再利用する可能性のある部品は一緒にまとめるという考え方です。これにより、ソフトウェア全体の見通しを良くし、保守や変更がしやすくなります。

再利用・リリース等価の原則

「リリースされたものだけを再利用すべき、再利用させたければリリースすべき」と言う考えです。
また「再利用する単位」と「リリースする単位」は同じであるべきとも言えます。
特定のソフトウェア部品が変更された場合、その部品を含むパッケージ全体を再リリースすることを指します。
つまり、1つの変更があると、それに関連するすべてのコンポーネントが影響を受けるため、それらを同時に再リリースする必要があります。
これにより、システムの安定性が維持され、互換性のない変更が他の部品に影響を与える可能性が減少します。

全再利用の原則

「一つのパッケージに起きた変更は全部使うか、全部使わないかの二択である」と言う考えです。
どういうことかというと、パッケージ利用者に「このクラスの変更は必要だけど、このクラス変更はいらない」と言う選択権がないことを表しています。なのでパッケージ提供者側は同じ責務をもったクラスは一つのパッケージにまとめ、違う責務のものは違うパッケージにまとめることで不要なリリースを減らすことができるとも言える原則です。

閉鎖性共通の原則

「一つの変更が生じるとき、変更範囲ができるだけ一つのパッケージ内に収まるようにするべきだ」と言う考えです。こうすることで変更した際の影響を、そのパッケージのみに収めることができるので、そのパッケージのみをデプロイするだけで変更完了とすることができる。

非循環依存の原則

「パッケージの依存は循環してはならい」と言う原則です。
循環依存したパッケージはセットで一つの塊になるので、絶対に一緒に使用しなければならない依存性の高いコードになってしまいます。。

安定依存の原則

「パッケージの依存は常により安定したパッケージに向く」と言う原則です。安定とは変更の起きにくさであり、依存先のパッケージに変更が頻繁に起きてしまえば、それに合わせて変更箇所が増えてしまいます。
なので依存先のパッケージは自分よりも安定しているべきであると言う原則です。

安定度・抽象度等価の原則

「安定度と抽象度には相関関係があり、安定度が高いと抽象度も高く、また逆も然り」と言う原則です。
ここでいう抽象度とは以下の四つである。

• 抽象クラスやインターフェースなど、実装詳細を自身から排除したもの
• 上記のような詳細持たないものだけに依存するロジック
• 固有の業務にも特定技術にも関係しない時刻や配列などの汎用概念とその操作
• プログラミング言語そのものや言語標準ライブラリと同等レベルの業界標準