场景：

现在的程序中有两个模块，模块A 和 模块B。 由于业务逻辑的特殊性，B中有一个子模块C，C中有一个子模块D，D模块的初始化/构造函数依赖于外部的A模块中的一个值。除此之外， B模块中的任何方法、属性 都与A模块无任何关联。 B模块的初始化过程中会初始化子模块C，C模块的初始化过程中会初始化子模块D。

问题：

基于以上的情况：

• 该如何设计当前的模块结构才是最合适的呢？
• 鉴于模块化“高内聚低耦合”的设计原则，A和B两个模块 除了 子模块D依赖A中的一个值这一点之外，没有任何交集
• 如果把A和B完全打通搞成同一个模块，违背了高内聚的原则，而目前的A B分开的模块结构，又存在业务逻辑上的这种特殊依赖，产生了让人不太舒服的耦合度
• 场景只是就事论事举个例子，真实的业务场景中肯定不止ABCD这四个模块，B中还会有很多其他的子模块，A中亦然，所以大家没必要纠结我的场景为什么把四个模块要搞出这种奇怪的模块结构，我相信这样的情景在很多业务场景中都存在