当遵循类似 DDD 的风格时，可以复制现有的“实体”吗？属性略有不同？
我正在尝试将一些类似 DDD 的模式应用到我编写的代码中，以将其用作如何编写良好代码的示例。我们已经有一堆代表域对象的类，但大多数类“知道得太多”，并且逻辑、getter/setter 和数据访问（以非类型化数据集的形式）遍布其中。
对于应用程序的这一部分，我需要使用相同的域对象，但返回的数据的一小部分导致使用“胖”对象变得笨拙（例如，假设“胖”对象有 20 个属性和方法我只注意在这部分使用 7 个属性）。我是否可以接受创建一个具有相同名称（当然在不同的命名空间/包中）且仅包含我需要的属性的精益 DTO 样式对象？我似乎记得这是 DDD 世界中的一个很好的实践，但我不能确定（我记得与有界上下文有关？）并且我不想污染我的设计。
I'm trying to apply some DDD-like patterns to the code I write to use it as an example of how to write good code. We already have a bunch of classes that represent the domain objects, but most of them "know too much" and have both logic, getters/setters and data access (in the form of untyped DataSets) strewn throughout them.
For this portion of the application, I need to use the same domain object but with a small subset of the data returned that makes it unwieldy to use the "fat" object (for instance let's say the "fat" object has 20 properties and methods and I only heed to work with 7 properties for this portion). Is it acceptable for me to create a lean DTO-style object with the same name (in a different namespace/package of course) with only the properties that I need? I seem to recall this was a good practice in the DDD world but I cannot remember for sure (something to do with bounded contexts, as I recall?) and I would hate to pollute my design.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我会对你想要实现的目标保持警惕。为了真正实现域驱动，您的实体应该具有丰富的功能，而不是“贫血”域模型
因此，如果您发现自己处于“需要使用相同的域对象但具有一小部分属性”的情况，那么在这种情况下到底使用域对象是什么。
它是否只是用作 DTO 并传递给包含实际功能的其他管理器类。
如果是这种情况，您可能需要重新审视您的设计，看看它是否真正是领域驱动的。
I'd be wary here with what it is you're trying to achieve. For it to be truly domain driven, your Entities should be rich in functionality and not an "anemic" domain model
So if you find yourself in a situation where you "need to use the same domain object but with a small subset of properties", what exactly is using the Domain Object in this scenario.
Is it just being used as a DTO and being handed around to other manager classes which contain the actual functionality.
If that's the case you may want to revisit your design to see if it's truly domain driven.