Whi*_*cal 1 architecture design-patterns domain-driven-design
我需要从我的域收集和导出指标。在某种程度上，我觉得指标是纯粹基于业务的，因此必须位于领域层。另一方面，我害怕将计数器的状态存储在域中，因为它们的正确状态取决于事务性
想象一下，您有一个典型的 CRUD + 一些次要业务逻辑 DDD 应用程序，并且您想要注册所有创建、更新等，然后通过端点导出它们。你会如何设计这个？
该解决方案会根据您用于实现该解决方案的框架和技术而变化，但让我提出一些广泛适用的一般准则，
当您为域模型运行分析指标时，了解分析的重要性非常重要。他们多久被访问一次？这些指标是用于审计日志还是驱动业务决策？这些问题应该指导我们使用正确的模型。
当指标与您的领域一样重要时，您应该开始考虑将它们视为单独的实体。它们应该在单独的上下文中设计。所需的指标和分析通常与传统的 CRUD 需求不同，单独的“有界上下文”在这里确实有意义。
如果您刚刚开始使用或对分析的使用有限，您可以考虑在 CRUD 数据旁边放置审核日志，并每次按需导出指标信息。这将节省时间，因为您不需要设计单独的指标上下文。