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