Provide an example application.

[sageserpent-open]

Benchmarks and tests are all very fine, but an example application can show you a better use of time. Ahem.

Rather than tweaking the benchmark further, it would serve as a better indicator of performance and also of the API usability if there were a non-trivial example application driving Plutonium. It doesn't have to be a fully fledged product, but needs to be realistic enough to serve as a template to develop real applications off.

[sageserpent-open]

What shall be implemented?

How about a billing system for electricity?

What are the use cases? Who are the actors?

[sageserpent-open]

Actors:

1. Customer.
2. Metered address.
3. Meter - possibly several corresponding the same metered address, not necessarily within that address.
4. Account - what happens when a customer, possibly resident at the metered address or possibly not, enters into a contract to pay for electrical energy consumed at the metered address. Has a start time and an optional expired time. For now, let's consider a customer that moves to / takes on payment responsibility for another metered address as setting up a new account. Likewise, any new customer at that metered address has a new account set up. Obviously an account refers to the amount of electrical energy consumed and the monies paid into that account so far. It must also take into account variable tariffs, plus tariff price changes.
5. Bill - is sent out to a customer, needs to be paid in full.

[sageserpent-open]

Use cases:

1. Send a bill.
2. Receive bill payment.
3. Provide usage report, outstanding bill and next estimated bill.
4. Receive meter reading from customer.
5. Receive meter reading from meter reading staff.
6. Receive smart meter reading.
7. Set up account for new customer.
8. Amend meter reading from customer.
9. Amend customer details.
10. Amend metered address details.
11. Close account.
12. Decommission meter.
13. Commission meter.
14. Change tariff prices.

[sageserpent-open]

This just became an epic.

[sageserpent-open]

Note the use-cases above are framed from the perspective of a core service receiving events from elsewhere - for example 'receive meter reading from customer', as opposed to 'customer requests meter reading'. The point is not to provide an end to end system with a web front end, embedded meter software etc, but to maintain a core business domain model.

[sageserpent-open]

What would constitute a simple story to yield some provable outcome to a stakeholder?

At very least, the business will need to bring in a customer and show that said customer has a live account on the system, even if they can't be charged for consumption of energy - the business will catch up with them later when billing is brought in.

So, "Set up account for new customer."

[sageserpent-open]

A natural follow up would be "Send a bill" / "Provide usage report, outstanding bill and next estimated bill." These two use-cases are related from the perspective of a core system, in the sense that either the actor is a scheduled activity when sending a bill, or is the customer when requesting a report, but in both cases, the core system has to calculate a bill.

How about splitting the latter to give:

1. Provide usage report.
2. Provide bill.

The difference between an outstanding bill and an estimated future bill is then simply the query time, they are the same core use-case.

[sageserpent-open]

Following on, there is a notion of knowing that a bill has been generated and chasing it up until it is paid - let's have "Send a bill" as a story too.

[sageserpent-open]

Let's put this under the package com.sageserpent.protactinium is an additional subproject for now, it will probably be broken out later.