title: Where do application logic and constraints go when creating ContentProviders?
body: <p>I'm starting to learn Android development, and also have been trying to follow the DDD design patterns. One thing that has me confused is where application logic goes with respect to ContentProviders. </p>
  
  <p>ContentProviders look a lot like repositories to me, but a lot of times I don't want to expose my repositories directly. There may be some additional application logic inside a Service which the repositories/database. </p>
  
  <p>Most of the examples of ContentProviders I find show them accessing the database directly. Is it wrong to have a Service or Application object in between the ContentProviders and database? </p>
  
  <p>For example I'm trying to create a personal finance/budget app (e.g Mint/Quicken etc..). I'm going to have a database of transactions and a corresponding TransactionProvider. In most cases transactions are independent from one another. Yet if two transactions are marked as part of the same "Transfer" there there will be some fields that I will want to keep in sync between the two transactions. If someone changes the category or amount of one transaction, I want to make sure the same values are updated for the transaction for the other account of the transfer.</p>