在 DDD 中添加通用语言？
我在 UML 中（在纸上）快速定义了我的域模型，当我开始测试驱动功能时，重构使我得到了一些小类，这些类不代表我的域中的概念，但这些类很好地封装了所需的职责。
例如，我从一台具有多个许可证的机器开始（机器 --->* 许可证）。我从方法 Add(licenseType) 和 remove(licenseType) 开始，它们增加或减少了列表中相应的许可证对象（即许可证有一个许可证类型和该类型许可证数量的计数器）。
Machine 有其他关联和行为，因此我创建了一个 LicenseTypeManager，其中我现在拥有 Machine --->1 LicenseTypeManager --->* 许可证。
我将 Machine 作为聚合根，将 LicenseTypeManager 作为值对象，将 License 作为值对象。
现在 LicenseTypeManager 是我在重构时创建的东西，根本没有被提及，并且不是应用程序通用语言的一部分。它的存在可以吗？
换句话说，使用 UL 建模然后找到其他可能有助于更清楚地解释该领域的术语是否可以？
另外，我开始认为 LicenseTypeManager 可能是一个域服务，但后来我开始担心我可能正在创建一个贫乏的模型（尽管模型中仍然有很多逻辑）。所以我的下一个问题是它应该是一个域服务还是应该保留在原来的位置？
京东
I defined quickly my domain model in UML (on paper) and as I start to test drive out functionality, refactoring has led me to small classes that do no represent concepts in my domain but these classes nicely encapsulate the responsibility needed.
For example, I started with a Machine which has a number of licenses (Machine --->* License). I started with methods Add(licenseType) and remove(licenseType) which increased or decreased the corresponding license object in the list (i.e. license has a licenseType and a counter of the number of licenses of that type).
Machine has other associations and behaviors so I created a LicenseTypeManager where I now have Machine --->1 LicenseTypeManager --->* License.
I have Machine as an aggregate root, LicenseTypeManager as a Value object and License as a Value object.
Now LicenseTypeManager is something I created whilst refactoring and was not mentioned at all and is not part of the ubiquitous language of the application. Is it okay for it to exist?
In other words is it fine to model using UL and then find other terminology that may help in explaining the domain more clearly?
Also, I started to think that LicenseTypeManager could be a domain service but then I started to worry that I may be creating an anemic model (although there is still a lot of logic in the model). So my next question is should it be a domain service or should it remain where it is?
JD
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
是什么导致了普遍语言的丰富并不重要。但重要的是它无处不在。
因此，如果您对您的领域进行建模并找出易于理解的新术语，只要领域专家理解它们、已经使用或开始使用它们，那就没有问题。
想象一下，您正在销售汽车，但对编程一无所知。
汽车类型管理器对您来说有意义吗？不太可能。它也不应该存在于域中。据我所知：
- 你不理解聚合根、实体和值对象之间的区别
- 你缺乏一般的 OOP （因此你通过引入“经理”来寻求救赎）
It doesn't matter what causes enrichment of ubiquitous language. But it matters that it is ubiquitous.
So - if you model your domain and figure out new terms that eases understanding, there's nothing wrong with that as long as domain experts understands them, already uses or starts using them too.
Imagine you are selling cars and know nothing about programming.
Would
Car type managermake any sense to you? Unlikely. It should not live in domain either.As I see it:
- you don't understand distinction between aggregate roots, entities and value objects
- you lack knowledge of OOP in general (hence you seek for redemption through introduction of "managers")