在我们的项目 (C++14) 中，我们通过系统的功能分解将软件分成几个组件。每个模块都驻留在自己的命名空间中，嵌入在系统的公共命名空间中。我们使用 CMake 作为我们的构建系统，每个组件都是一个静态库，可以单独构建并在最后链接在一起。
现在，在许多组件中定义了特定的数据类型，例如类或结构。对于时间，要一起处理的数据字段的集合等等。这些数据结构在创建它们包含的数据的组件中本地定义。
但是。当我现在必须从其他组件访问这些数据结构之一时，我必须包含来自特定组件的标头并在这两个组件之间具有依赖关系。由于这是一种常见的方法，我们的软件组件之间有许多依赖关系，很容易导致循环依赖关系。 :(
在 C 世界中，我会创建一个 GlobalDataStructures.h 并添加在整个软件系统中使用的所有数据结构。
对此的（现代）C++ 方法是什么？ 什么是最佳做法？
【问题讨论】：
标签： c++ architecture dependencies
“C 风格”方法背后的想法基本上是合理的。
作为一般规则，您希望将数据结构定义得尽可能远离依赖关系树的根。如果发生循环，则某些数据结构必须至少向根移动一级才能打破循环。
在某些时候，您最终会到达依赖根目录。对于具有不同组件的项目，这意味着引入一个根组件。它是一个组件——在你的情况下是一个静态库——就像任何其他组件一样，它拥有整个系统所必需和/或有用的数据结构和功能。棘手的部分是不要让那个组件成为厨房水槽下的橱柜——毕竟现在你有一个方便的地方来放东西，而不必考虑它们真正属于哪里。但这是人的问题，而不是技术问题。
通常我将 CMake 目标称为根组件库 projectname_core。我曾经将其所有内容放入projectname::core 命名空间。但事实证明，团队中的每个人都只是到处写using namespace projectname::core;。显然，额外的命名空间并没有添加任何有用的信息，将系统范围的内容放入 projectname 命名空间也同样有效。这就是我这些天所做的。
【讨论】：
这是我的专业领域。我是 POWER 的创建者，这是一种模拟制造的软件架构。你可以在这里阅读我关于 DTO 的文章，因为我已经超越了单纯的硬编码。 What is Data Transfer Object?
现在回答您的问题...注意在分布式 (OOP) 架构中，您需要附加整个命名空间以使用 DTO、将 DTO 复制到每个使用命名空间或将 DTO 集中到一个共享命名空间中。然而，在 POWER 中，一个命名空间中的进程可以操作它甚至不知道的对象实例，因为该进程绑定到 DTO 的引用属性而不是 DTO（及其类型）本身。 POWER 是一种零耦合架构，因为制造也是。
从技术上讲，即使 DTO 高度相似甚至在结构上等效，流程也不应该共享 DTO。共享模块甚至 DTO 会导致集中化复杂性，这是我在此使用哈佛商业评论作为来源权威描述的组织缺陷：http://www.powersemantics.com/p.html
【讨论】：