Using database jobs in Domain Driven Design

I am creating a .net application using Domain Driven Design approach. The application includes billing clients for services. The rule says that dail开发者_如何学Cy, 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.

Part of DDD is managing to decouple domain model from technical concerns as much as possible.

Putting business knowledge in database jobs means:

• You would have 2 places to look for business logic (loss of model isolation)
• Your business logic would be described in 2 languages (e.g. c#; t-sql)
• It might not be easy to manage business logic w/ procedural sql scripts
• It might not be easy to sync w/ part which is written in .Net

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.