DDS核心概念：从域到读写器的完整链路
说实话，刚接触DDS的时候，我被这一堆概念搞得有点晕。域、参与者、主题、发布者、订阅者……还有DataWriter和DataReader？这些到底什么关系？
别急，我带你捋一遍。这七个概念，说白了就是DDS通信的七块积木。你搭好了，机器人就能顺畅聊天。
域（Domain）—— 通信的虚拟空间
域是什么？你可以把它想象成一个独立的聊天室。同一个域里的节点才能互相通信。不同域之间，默认是隔离的。
我在项目中遇到过一个问题：两个机器人团队用了同一个网络，结果数据串了。后来发现，他们用的Domain ID都是0。改成不同的ID，问题立刻解决。
核心要点：
- Domain ID是一个整数，范围0-232
- 同一个域内的参与者才能互相发现和通信
- 不同域之间完全隔离，除非你配置了跨域桥接
我的习惯：开发阶段用Domain ID 0，测试用1，生产环境用2以上。这样不会搞混。
域参与者（DomainParticipant）—— 域的入口
域参与者，就是进入这个聊天室的人。每个节点（Node）在DDS层面，其实就是一个或多个DomainParticipant。
你想想看，你要进聊天室，总得有个身份吧？DomainParticipant就是这个身份。它负责管理你在这个域里的所有资源——主题、发布者、订阅者等等。
// 创建域参与者的典型代码
DomainParticipant* participant =
participant_factory->create_participant(
domain_id, // 域ID
PARTICIPANT_QOS_DEFAULT,
nullptr, // 监听器
StatusMask::none());我曾经踩过的坑：一个进程里创建了上百个DomainParticipant，结果内存爆了。后来才知道，一个进程通常只需要一个参与者就够了。多个节点共享一个参与者，用不同的主题区分即可。
主题（Topic）—— 聊天的主题
主题，就是你们聊什么话题。比如“/cmd_vel”是速度指令，“/odom”是里程计数据。每个主题都有名字和数据类型。
嗯，这里要注意：主题的名字是全局唯一的。同一个域里，不能有两个同名的主题但数据类型不同。DDS会报错。
| 主题名 | 数据类型 | 用途 |
|---|---|---|
| /cmd_vel | Twist | 速度控制指令 |
| /odom | Odometry | 里程计数据 |
| /scan | LaserScan | 激光雷达数据 |
发布者（Publisher）与数据写入器（DataWriter）
这两个概念经常一起出现。我习惯把它们看作一对搭档。
发布者是管理者，负责协调多个DataWriter。而DataWriter才是真正干活的那个——它把数据写进DDS网络。
说白了：Publisher是经理，DataWriter是员工。经理不直接干活，但员工需要经理来管理资源。
// 创建发布者和DataWriter
Publisher* publisher =
participant->create_publisher(
PUBLISHER_QOS_DEFAULT,
nullptr);
DataWriter* writer =
publisher->create_datawriter(
topic,
DATAWRITER_QOS_DEFAULT,
nullptr);我的经验：一个Publisher可以管理多个DataWriter。比如一个Publisher管理/cmd_vel和/odom两个主题的写入。这样资源利用率更高。
订阅者（Subscriber）与数据读取器（DataReader）
和发布端对称，订阅端也有两个角色。
订阅者是管理者，DataReader是执行者。DataReader从DDS网络里读取数据，然后交给你的应用层处理。
我记得第一次用DDS时，以为直接订阅主题就能拿到数据。后来才发现，必须通过DataReader来读。这个设计其实很巧妙——它让你能精细控制数据的读取方式。
// 创建订阅者和DataReader
Subscriber* subscriber =
participant->create_subscriber(
SUBSCRIBER_QOS_DEFAULT,
nullptr);
DataReader* reader =
subscriber->create_datareader(
topic,
DATAREADER_QOS_DEFAULT,
nullptr);完整链路：一张图看懂
这七个概念的关系，我用一张SVG图给你画清楚：
七者的协作关系
你看这张图就明白了：
- 域是最大的容器，所有通信都在域内进行
- 域参与者是每个节点的入口，一个域可以有多个参与者
- 主题是数据的标签，发布和订阅都围绕主题展开
- 发布者+DataWriter负责写数据，订阅者+DataReader负责读数据
一句话总结：域是聊天室，参与者是里面的人，主题是聊的话题。发布者带着DataWriter负责说话，订阅者带着DataReader负责听。就这么简单。
实际项目中的配置建议
我在做机器人项目时，一般这样配置：
- 每个机器人进程只创建一个DomainParticipant
- 每个话题类型创建一个Publisher/Subscriber
- 每个话题实例创建一个DataWriter/DataReader
- QoS配置根据数据特性调整（比如传感器数据用BEST_EFFORT，控制指令用RELIABLE）
我曾经犯过的错：给所有话题都用RELIABLE模式，结果网络一拥堵，整个系统延迟飙升。后来改成传感器数据用BEST_EFFORT，控制指令用RELIABLE，问题解决了。
嗯，这七个概念你掌握了吗？其实DDS的设计很优雅——分层清晰，职责单一。你只要记住：域是空间，参与者是身份，主题是标签，发布/订阅是动作，DataWriter/DataReader是执行者。剩下的，就是多写代码多实践了。