domain-driven-design - 实现 DDD(红皮书): Why did he made the Collaborators as Value Objects?

Question

我与 Vaughn Vernon 的红皮书有关。

在协作有界上下文中，他将作者、成员、参与者、创建者等设置为值对象，其中字段与它们绑定(bind)的实体内联存储。

比方说，如果您创建一个有一个创建者的讨论，那么创建者的字段(id、姓名、电子邮件)将存储在同一个表中(tbl_discussions)。

论坛也是如此。 (见下面的架构)

DROP DATABASE IF EXISTS iddd_collaboration;
CREATE DATABASE iddd_collaboration;
USE iddd_collaboration;
SET FOREIGN_KEY_CHECKS=0;

CREATE TABLE `tbl_dispatcher_last_event` (
    `event_id` bigint(20) NOT NULL,
    PRIMARY KEY (`event_id`)
) ENGINE=InnoDB;

CREATE TABLE `tbl_es_event_store` (
    `event_id` bigint(20) NOT NULL auto_increment,
    `event_body` text NOT NULL,
    `event_type` varchar(250) NOT NULL,
    `stream_name` varchar(250) NOT NULL,
    `stream_version` int(11) NOT NULL,
    KEY (`stream_name`),
    UNIQUE KEY (`stream_name`, `stream_version`),
    PRIMARY KEY (`event_id`)
) ENGINE=InnoDB;

CREATE TABLE `tbl_vw_calendar` (
    `calendar_id` varchar(36) NOT NULL,
    `description` varchar(500),
    `name` varchar(100) NOT NULL,
    `owner_email_address` varchar(100) NOT NULL,
    `owner_identity` varchar(50) NOT NULL,
    `owner_name` varchar(200) NOT NULL,
    `tenant_id` varchar(36) NOT NULL,
    KEY `k_owner_identity` (`owner_identity`),
    KEY `k_tenant_id` (`name`,`tenant_id`),
    PRIMARY KEY (`calendar_id`)
) ENGINE=InnoDB;

CREATE TABLE `tbl_vw_calendar_entry` (
    `calendar_entry_id` varchar(36) NOT NULL,
    `alarm_alarm_units` int(11) NOT NULL,
    `alarm_alarm_units_type` varchar(10) NOT NULL,
    `calendar_id` varchar(36) NOT NULL,
    `description` varchar(500),
    `location` varchar(100),
    `owner_email_address` varchar(100) NOT NULL,
    `owner_identity` varchar(50) NOT NULL,
    `owner_name` varchar(200) NOT NULL,
    `repetition_ends` datetime NOT NULL,
    `repetition_type` varchar(20) NOT NULL,
    `tenant_id` varchar(36) NOT NULL,
    `time_span_begins` datetime NOT NULL,
    `time_span_ends` datetime NOT NULL,
    KEY `k_calendar_id` (`calendar_id`),
    KEY `k_owner_identity` (`owner_identity`),
    KEY `k_repetition_ends` (`repetition_ends`),
    KEY `k_tenant_id` (`tenant_id`),
    KEY `k_time_span_begins` (`time_span_begins`),
    KEY `k_time_span_ends` (`time_span_ends`),
    PRIMARY KEY (`calendar_entry_id`)
) ENGINE=InnoDB;

CREATE TABLE `tbl_vw_calendar_entry_invitee` (
    `id` int(11) NOT NULL auto_increment,
    `calendar_entry_id` varchar(36) NOT NULL,
    `participant_email_address` varchar(100) NOT NULL,
    `participant_identity` varchar(50) NOT NULL,
    `participant_name` varchar(200) NOT NULL,
    `tenant_id` varchar(36) NOT NULL,
    KEY `k_calendar_entry_id` (`calendar_entry_id`),
    KEY `k_participant_identity` (`participant_identity`),
    KEY `k_tenant_id` (`tenant_id`),
    PRIMARY KEY (`id`)
) ENGINE=InnoDB;

CREATE TABLE `tbl_vw_calendar_sharer` (
    `id` int(11) NOT NULL auto_increment,
    `calendar_id` varchar(36) NOT NULL,
    `participant_email_address` varchar(100) NOT NULL,
    `participant_identity` varchar(50) NOT NULL,
    `participant_name` varchar(200) NOT NULL,
    `tenant_id` varchar(36) NOT NULL,
    KEY `k_calendar_id` (`calendar_id`),
    KEY `k_participant_identity` (`participant_identity`),
    KEY `k_tenant_id` (`tenant_id`),
    PRIMARY KEY (`id`)
) ENGINE=InnoDB;

CREATE TABLE `tbl_vw_discussion` (
    `discussion_id` varchar(36) NOT NULL,
    `author_email_address` varchar(100) NOT NULL,
    `author_identity` varchar(50) NOT NULL,
    `author_name` varchar(200) NOT NULL,
    `closed` tinyint(1) NOT NULL,
    `exclusive_owner` varchar(100),
    `forum_id` varchar(36) NOT NULL,
    `subject` varchar(100) NOT NULL,
    `tenant_id` varchar(36) NOT NULL,
    KEY `k_author_identity` (`author_identity`),
    KEY `k_forum_id` (`forum_id`),
    KEY `k_tenant_id` (`tenant_id`),
    KEY `k_exclusive_owner` (`exclusive_owner`),
    PRIMARY KEY (`discussion_id`)
) ENGINE=InnoDB;

CREATE TABLE `tbl_vw_forum` (
    `forum_id` varchar(36) NOT NULL,
    `closed` tinyint(1) NOT NULL,
    `creator_email_address` varchar(100) NOT NULL,
    `creator_identity` varchar(50) NOT NULL,
    `creator_name` varchar(200) NOT NULL,
    `description` varchar(500) NOT NULL,
    `exclusive_owner` varchar(100),
    `moderator_email_address` varchar(100) NOT NULL,
    `moderator_identity` varchar(50) NOT NULL,
    `moderator_name` varchar(200) NOT NULL,
    `subject` varchar(100) NOT NULL,
    `tenant_id` varchar(36) NOT NULL,
    KEY `k_creator_identity` (`creator_identity`),
    KEY `k_tenant_id` (`tenant_id`),
    KEY `k_exclusive_owner` (`exclusive_owner`),
    PRIMARY KEY (`forum_id`)
) ENGINE=InnoDB;

CREATE TABLE `tbl_vw_post` (
    `post_id` varchar(36) NOT NULL,
    `author_email_address` varchar(100) NOT NULL,
    `author_identity` varchar(50) NOT NULL,
    `author_name` varchar(200) NOT NULL,
    `body_text` text NOT NULL,
    `changed_on` datetime NOT NULL,
    `created_on` datetime NOT NULL,
    `discussion_id` varchar(36) NOT NULL,
    `forum_id` varchar(36) NOT NULL,
    `reply_to_post_id` varchar(36),
    `subject` varchar(100) NOT NULL,
    `tenant_id` varchar(36) NOT NULL,
    KEY `k_author_identity` (`author_identity`),
    KEY `k_discussion_id` (`discussion_id`),
    KEY `k_forum_id` (`forum_id`),
    KEY `k_reply_to_post_id` (`reply_to_post_id`),
    KEY `k_tenant_id` (`tenant_id`),
    PRIMARY KEY (`post_id`)
) ENGINE=InnoDB;

现在，如果用户更改了他的电子邮件，那么您必须更新/同步所有表以反射(reflect)更改。

我只是想知道他为什么想出那个解决方案？他考虑了什么？

还有其他选择吗？就像实现相同的代码，但以不同的方式坚持它们？

Answer 1

从书中:

There is not effort made to keep Collborator Value instances synchronized with the Identity and Access Context. They are immutable and can only be fully replaced, not modified. p.468 para. 1

这意味着当值被替换时，基本上会发生同步。

If a Collaborator name or e-mail address changes in the Identity and Access Context, such changes won't be automatically updated in the Collaboration Context. Those kinds of changes rarely occur, so the team made the decision to keep this particular design simple and not attempt to sycnrhonize changes in the remote Context with objects in their local Context. p.469 para. 1

您还需要阅读 p.476 para.2 Can You Handle the Responsibility .在本节中，Vaughn 演示了在必须处理无序消息消费时保持有界上下文之间的数据同步可能是多么复杂。它还概述了为了保证消息的顺序，我们可能不依赖于复杂的消息传递基础设施，而只是从远程上下文中提取消息(例如，通过 RESTful 通知服务2)。

这始终是一个权衡问题以及您的域可以接受的问题。

2. 这种方法在 p.312 秒中描述。将通知发布为 RESTful 资源。