Overengineering is what we do

I subscribe to the DDD/CQRS Google group and read a great thread this morning on how to properly handle the assignment of an invoice number that must follow a certain pattern and MUST be sequential. Gaps in the invoice number were not allowed.

The author of the original question explained the requirements very well, and he was looking for a proper solution that would align with a CQRS approach. Some of the initial replies were very well explained and quite elaborate in terms of the aggregate root that would be required, what commands were to be issued, and some interesting approaches to handling the sequential numbering requirement.

Greg Young's reply was pretty succinct (as they usually are) and echoed what I was thinking:

ReadModel->GetNextInvoiceNumber 
Command CreateInvoice (InvoiceNumber)

Which basically means is that you just have a function in your read model that retrieves the next invoice number and then you use that when creating your command. That function could be as simple as querying a table that just generates a new IDENTITY value.

The discussion on the thread was very interesting and chock full of interesting ideas, but sometimes the simplest answer eludes us.

As engineers, the solutions we come up with are our art; there's an innate drive to make it special and unique. The simple solution, while elegant, may not be unique or special, so I think there's a drive to avoid it. We should embrace the simple more often, in both work and life.