实体视角
语境： 因此，我正在尝试构建一个极其复杂的域模型。 与用户交谈，系统的使用方式有多种（例如：一种方式是从员工的角度；另一种方式是从雇主的角度）。 实际上，它们是重用核心域的多个应用程序。
问题： 从多个角度创建域是错误的吗？ 例如，在业务运行时构建域意味着创建各种关系类，这些关系类携带有关实体的额外信息等等......但是，当从特定角度运行时，情况会更加清晰，因为大多数关系类可以滚动到它们的父实体中。
有想法吗？ 反驳？ 我完全偏离基地了吗？
Context:
So, I am attempting to build a ridiculously complex domain model. Talking with the users, there are multiple ways the system will be used (For example: one way is from the perspective of the employee; another way is from the perspective of the employer). In actuality, they are multiple applications reusing the core domain.
Question:
Is it wrong to create the domain from multiple perspectives? For instance, to build the domain as the business is run would mean creating all kinds of relationship classes that carry extra information about the entity and so on... However, when running from a particular perspective, the picture is much clearer because most of the relationship classes can be rolled into their parent entity.
Ideas? Rebuttals? Am I completely off-base?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
不，这绝对是合适的。 埃文在他的书中将这些“视角”称为“限界上下文”。
与其拥有一个非常复杂的域模型，不如尝试构建一个简单的域模型，以特定的方式很好地解决域问题。 有界上下文可以链接在一起，形成一个更小、更简单、直接的领域模型网络。
No, this is absolutely appropriate. Evan's calls these 'perspectives' Bounded Contexts in his book.
Instead of having a really complex domain model, try building a simple one that addresses the domain in a specific way really well. Bounded Contexts can be linked together to form a web of smaller, simpler, direct domain models.
我认为您不应该尝试预先定义“核心域”。 让它在开发过程中显现出来。 此外，任何两个（或更多）视角不常见的内容都不应该出现在“核心”中。
例如，从员工的角度构建系统的一部分。 这可能会提示您创建“项目”、“任务”和“客户”等实体。 然后从员工的角度构建一部分。 这可能会提示您构建新实体，并重用“项目”和“任务”。 那时我会将“项目”和“任务”移动到系统其余部分共享的“核心库”。
有时您会发现共同的实体，但以不同的方式相关。 在这种情况下，关系应该由上下文注入，而不是内置于实体本身。
I don't think you should try and predefine the 'core domain' up front. Let it emerge over the development process. Additionally, anything that is not common to the 2 (or more) perspectives should not be in the 'core'.
For instance, build a portion of the system from the employeer perspective. This might prompt you to create entities like 'Project', 'Task', and 'Customer'. Then build a portion from the employeer perspective. This might prompt you to build new entities, and to reuse 'Project' and 'Task'. That's when I'd move 'Project' and 'Task' to the 'core library' shared by the rest of the system.
Sometimes you'll find common entities, but related in different ways. In that case the relationship should be injected by the context instead of being built-in with the entities themselves.