In the spirit of DDD I'd like to offer a few domain boundaries and vocabulary terms that my team and I used when building our (multiple) billing platforms. "ch

In the spirit of DDD I'd like to offer a few domain boundaries and vocabulary terms that my team and I used when building our (multiple) billing platforms. "chargeable items" are things we want to charge for. In my experience there are exactly three kinds of chargeable item, which operate largely in their own domain: - "usage charges" are charges based on usage of some resource (eg, bytes, time or phone calls). - "recurring charges" are charges that are billed on a regular basis, e.g. a monthly fee. Recurring charges get complex due to the need for pro-rata, e.g. if your customer is on a monthly plan but signs up in the middle of the month, or changes plan in the middle of a month. (you can get away without this, but that just moves the complexity somewhere else - and computing refunds can become a huge pain at scale, especially if you want to build a system that is 100% self-service). - "one-time charges" are charges that are raised due to actions taken during the billing cycle; you might also call these "event charges". Things like connection/disconnection fees etc that are generated by a process or external system. These are the simplest, just an SKU and a value, maybe a qty and rate if you need it. Arguably, the most challenging domain for billing in telco circles is "rating", which is the process of computing the usage charges for individual charge detail records (CDRs) and aggregating them so that your database doesn't get overwhelmed. You might get a billion CDRs in a month. Although not all billing applications require rating, anything that does usage billing is doing some kind of rating. In Telco we also talk about "mediation" and "guidance" but that's another story... What's important about the above is the knowledge that there are different charging domains which need to be handled differently. There's a huge world of difference between a recurring charge and a usage charge. "billing" is the process of collecting these chargeable items together, to prepare them for sending to a customer. The resulting database rows might include the raw pricing along with tax, discounts etc. The important thing here is that we have a means of separating what we want to bill, from what we actually send to the customer, because the timing of an invoice is different from the timing of the charges. "invoicing" is the collection of the outstanding chargeable items into a final invoice, which can actually be sent to the customer. Interestingly, once you've issued an invoice to a customer, modifying the amount owed is probably illegal in most countries, and most certainly a bad idea. "payments" is the process of receiving money from credit cards. "collections" is the process of asking people to pay (It's also called "dunning", after the famous debt collectors, Dunn and Bradstreet). It arguably also includes policy actions like restricting access for non-payment, raising late fees, etc. Another can of worms... Anyway ... you can see a kind of billing pipeline here, where you have an ingress of chargeable events, which get rated, aggregated, held for invoicing, and then an invoice is raised, payment is requested, and non-payment is processed. This is just based on my experience, the industry seems to vary somewhat on the specifics. And ... it seems easy enough when I write it like this, but there are many devils in the details. Nevertheless, I hope this helps someone.