在领域驱动设计中使用数据库作业
我正在使用域驱动设计方法创建 .net 应用程序。该应用程序包括向客户收取服务费用。该规则规定，每天在给定时间应生成发票并更新用户的余额。正如我所看到的，这里最好的选择是计划执行上述任务的数据库作业。但是，这与DDD兼容吗？在这种情况下，逻辑被分割在数据库和域名层之间，这似乎不是一个好主意。
I am creating a .net application using Domain Driven Design approach. The application includes billing clients for services. The rule says that daily, at a given time an invoice should be generated and user's balance should be updated. As I see, the best option here would be a database job which being scheduled does the above task. However, is this compatible with DDD? The logic is split among database and domail layer in this case, which seems not to be a good ideea.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
DDD 的一部分是设法尽可能地将领域模型与技术问题脱钩。
将业务知识放入数据库作业中意味着：
我个人不会走那条路。我会写后台服务。
Part of DDD is managing to decouple domain model from technical concerns as much as possible.
Putting business knowledge in database jobs means:
I personally wouldn't go that road. I would write background service.
如果这很重要的话，实现数据库作业将更难以调试和单元测试。
我会推荐一项执行计划任务的服务。
Implementing a database job will be more difficult to debug and unit test if that matters.
I would recommend a service that does scheduled tasks.