没有业务属性的集合或实体 [英] Aggregate or entity without business attributes
问题描述
在以下摘录中，有关cqrs和ddd的摘录来自
这是否意味着命令方的域模型可以省略大多数业务属性？
例如客户实体看起来如何？
客户实体可以省略名字，姓氏等吗？
如果是，这些业务属性在哪里？
或者除了包含所有业务属性的CustomerEntity之外，还可能存在CustomerAggregate以1：1关系包装CustomerEntity，并且命令对象将在客户汇总？ （对我来说似乎很奇怪）。
客户实体不合理是什么意思？
您指向的文本意味着您不必为整个系统甚至整个有界上下文建模可重用实体（不要对可重用实体建模生活事物）。这样做是不好的设计。
您必须对执行动作的聚合建模。您只能持久地将执行该操作所需的数据和聚合响应（域遭受的更改）提供给聚合，这是您必须坚持的。
为什么要有实体和VO？
要建模一致性，封装和去耦是基本部分，但这是实现细节。对于DDD而言，重要的是不同的角色（或概念）。
在馈入聚合（构造函数，函数调用参数等）时，聚合必须知道它是否是与实体和/或VO合作
如果域操作意味着更改实体属性（在整个系统中具有唯一标识的事物），则聚合的响应（一次所有规则和不变量均已检查），应包括新的属性值和允许持久保存更改的实体的标识。
因此，默认情况下，每个聚合都有其拥有唯一标识和聚合操作所需属性的实体。
一个聚合可以有一个带有ID及其名称的Customer实体。
另一个汇总可能有一个具有ID及其Karma点的客户实体。
因此，每个汇总都有自己的 内部 与之合作的客户实体。当您输入汇总时，您将传递客户数据（即ID和名称或ID和Karma点），并且汇总将该信息视为实体（如果汇总内部有结构，类等，则取决于实现细节）代表实体）。
一件重要的事情：如果您只需要处理实体ID，则将其视为VO （CustomerIdentityVO），因为ID是不可变的，并且可能在该操作中，您只需要在持久性的某些字段中编写此CustomerIdentityVO，而不更改任何Customer属性。
此是标准的愿景。一旦您开始确定与多个聚合或一个聚合有关的通用结构，这些结构可以对馈入的相同数据执行多个操作，那么您将开始重构，重用等。这只是良好的OOP设计和SOLID原则的问题。
请注意，我试图超越实现细节。我知道您几乎总是会遇到不想要的工件，具体取决于编程范例类型，选择的编程语言等。但是这种方法可以极大地避免您可能遇到的更糟糕的工件。
推荐的读物：
http://blog.sapiensworks.com/post/2016/07/29/DDD-Entities-Value-Objects-Explained
http://blog.sapiensworks.com/post/2016/07/14 / DDD-Aggregate-Decoded-1
http://blog.sapiensworks.com/post/2016/07/14/DDD-Aggregate-Decoded-2
https://blog.sapiensworks.com/post/2016/07/14/DDD-Agg regate-Decoded-3
和
https://blog.sapiensworks.com/post/2016/08/19/DDD-Application-服务说明
完整的拼图视觉。
Regarding below excerpt, concerning cqrs and ddd, from Patterns, Principles, and Practices of Domain-Driven Design by Nick Tune, Scott Millett
Does it mean that domain model on command side can omit most of business attributes ? How would it look like for eg Customer Entity?
Could Customer entity omit FirstName, Surname etc? If so, where would these business attributes be? Only in read model in CustomerEntity?
Or maybe apart from CustomerEntity containing all business attributes there would also be CustomerAggregate wrapping CustomerEntity with 1:1 relation, and command object would operate on CustomerAggregate? (seems strange to me).
What does it mean "Customer entity desn't make sense"?
The text you pointed means that you do not have to model a reusable Entity for your whole system or even for your whole bounded context (Do not model reusable real life things). Doing this is a bad design.
You have to model an Aggregate that performs an action. You feed the Aggregate with only, and just only, the data needed to perform that action and the aggregate response, the changes the domain suffered, is what you have to persist.
Why Entities and V.O.'s then?
To model consistency, encapsulation and decoupling is the basic part but these are implementation details. For DDD what matters is that are different roles (or concepts).
When feeding the aggregate (constructor, function call parameters, etc) the aggregate has to know if it is working with entities and/or with V.O. to build its response.
If the domain action means a change in an attribute of a entity (something with unique identification in your whole system) the response of the aggregate (once all rules and invariants has been checked) should include the new attribute value and the identification of that entity that allows persist the changes.
So, by default, every aggregate has its own entity with the unique identification and the attributes needed for the aggregate action.
One aggregate could have a Customer entity with ID and its Name. Another aggregate could have a Customer entity with ID and its Karma points.
So every aggregate has its own inner Customer entity to work with. When you feed an aggregate you pass Customer data (i.e. ID and name or ID and Karma points) and the aggregate treats that info as a entity (It is a matter of implementation details if there is a struct, class, etc internally to the aggregate to represent the entity).
One important thing: If you just need to deal with entities ID's then treat it as a V.O. (CustomerIdentityVO) because the ID is immutable and, probably, in that action you just need to write this CustomerIdentityVO in some field in persistence, not change any Customer attribute.
This is the standard vision. Once you start to identify common structures relevant to several aggregates or one aggregate that can perform several actions with the same data fed you start to refactoring, reusing, etc. It just a matter of good OOP design and SOLID principles.
Please, note that I am trying to be higly above of implementation details. I know that you almost always will have unwanted artifacts that depends of programing paradigm type, chosen programing language, etc. but this approach helps a lot avoiding the worse artifact you could have.
Recommended readings:
http://blog.sapiensworks.com/post/2016/07/29/DDD-Entities-Value-Objects-Explained http://blog.sapiensworks.com/post/2016/07/14/DDD-Aggregate-Decoded-1 http://blog.sapiensworks.com/post/2016/07/14/DDD-Aggregate-Decoded-2 https://blog.sapiensworks.com/post/2016/07/14/DDD-Aggregate-Decoded-3
and
https://blog.sapiensworks.com/post/2016/08/19/DDD-Application-Services-Explained
for a complete puzzle vision.
这篇关于没有业务属性的集合或实体的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
