应该将对应于特定域的字符串解析器视为实用程序或域/值对象吗？
示例：用户提交金融工具的搜索请求。例如“OMX KR Equity”。为了将这样的字符串提交给提供者，必须将其解析并映射到其确切的值（工具名称，市场代码，工具类型）。搜索请求文件结构取决于仪器类型，因此在解析字符串后，必须根据数据库中的现有类型检查工具类型。如果它不存在，则无法提交搜索请求，用户必须相应地收到响应。
（搜索结果与您的预期略有不同。用户提交搜索请求。应用程序通过生成请求文件，通过FTP向外部提供商提交搜索请求。一段时间后，请求得到满足并从中获取FTP并保存到数据库中。因此搜索请求没有立即响应。）
我找不到合适的位置来放入这个逻辑。通常它可能是SearchRequest实体中的一个值对象，但需要对数据库进行验证会引发一个问题。
此外，我试图避免引入静态解决方案，因为我怀疑它使测试更加困难。特别是如果它被认为是域逻辑，我不认为它应该属于静态方法作为实用程序，帮助程序等。
根据ddd解决此问题的正确方法是什么？
答案 0 :(得分：1)
应该对应于特定域的字符串解析器 被视为实用程序或域/值对象？
应该是Value object来验证构造函数中的格式（例如使用正则表达式：[A-Z]{3}\s[A-Z]{2}\s[a-zA-Z]{1,}），并且该字符串的三个部分只有三个getter：{{ 1}}，getName():string，getType():string。让我们命名这个类：getCode():string。它具有 only one 责任：验证+解析字符串。
搜索请求文件结构取决于仪器类型，所以之后 要解析字符串，必须检查工具类型 数据库中的现有类型。
＆＃34;检查数据库中的现有类型＆＃34;在将命令发送到InstrumentQuery之前，在接收搜索命令的Application service中完成。虽然在广泛的世界中的大多数现有域中搜索是某种query method，但在您的域中，SearchRequest aggregate是SearchRequest。此汇总有Aggregate command method。
根据您的设计，submitQuery(InstrumentQuery instrumentQuery)是InstrumentType（因此它有Entity）或ID。如果是Value object，则Entity可能会收到submitQuery;这取决于内部使用情况。在任何情况下，通过尝试从ID加载它，在命令到达SearchRequestAggregate之前检查其存在。
特别是如果它被认为是域逻辑，我认为不应该 属于静态方法作为实用程序，帮助程序等。
如您所见，您有两种不同的验证：
Repository：纯域逻辑的格式，位于SearchRequest内，位于域代码层内。ValueObject：应用层逻辑，通过尝试从存储库加载来检查。