モジュール式のエンタープライズアプリケーションを設計したすべての人から、モジュール化をどのように認識し、パラメータは正確に何であるかを知りたいと思います。
これは、経験に基づく設計上の質問であるため、その経験に基づく意見の組み合わせが含まれます。
レイヤーベースのモジュール化はほとんどメリットがないため、機能ベースにする必要があります。もちろん、これは（ソフトウェア）レイヤーを完全に無視する必要があるという意味ではありません。
モジュールをデプロイ可能なコンポーネント（Mavenアーティファクト、EAR内のJARなど）と考える場合、これの主な動機の1つは、特定の顧客/デプロイメントでオンとオフを切り替えることができるパーツにアプリケーションを分割することです。この場合、機能ベースのモジュール化が明白な方法です。
そのような展開が必要ないと確信している場合でも、機能ベースのモジュール化を使用することをお勧めします。機能モジュール間のインターフェースは、レイヤー間よりもはるかに小さい（したがって管理が容易）傾向があります。また、隣接する2つのレイヤーで作業する人は通常同じであるため、モジュールの分離を強制することは難しく、分離によってもたらされるメリットがなくても邪魔になることがよくあります。
「ビッグレイヤー」（UI、ビジネスロジック、データベース）について考えている場合を除いて、その場合は実行可能です。この場合、「マトリックスのモジュール化」（つまり、機能とレイヤーの両方のモジュール化）をお勧めしますが、機能ベースのチーム/個々の責任と、ハードパーツのいくつかの専門的な役割があります。たとえば、GUIの1人の設計者と、GUIを含む個別の機能モジュールをそれぞれ使用する複数のプログラマー。
質問3については、これら2つのモジュールをさらに分解してみてください。それらは通常粗すぎます。それらが何らかの思考/議論の後でないことが判明した場合は、循環を避けるためにそれらを人為的に分割する必要があります。それが間違っていると感じたら、特に。本当に小さなモジュールで終わる場合は、それらを1つのモジュールにマージします。最初のステップとしてマージを試みないでください。