Reading this article from Uncle Bob, led me to these reflections on how databases (and frameworks) “infect” the design of our applications.
One common mistake when designing an application is to put the database or the framework as the centre of the application; e.g.: when designing fishery management systems, it is very common to start by choosing the technology (e.g.: .NET Framework, Oracle) or to design the database before deciding anything else (including, if we have the “need” for a database). This is wrong, as the centre of the application – the highest level and most visible architectural entities – should always be the “use cases”. The first thing should be to know what exactly are the data entities involved (the “actors”), how they are related, and how they are used. Only after clarifying these points, it is possible to make decisions about a data model, and fit it into a database. Getting a database “involved earlier on” will warp the design, and influence our ideas about what we want to achieve. For instance, the relational model will bias our thinking into a “relational” view of the world, where data is organized into tuples and relations.
Databases and frameworks are technical details that may be decided (and changed) later, but a correct design is a crutial – and often disregarded – step in software development.
Developing use cases should be looked at as an iterative process, pretty much in line with the AGILE approach; the process should rely on work and refinement, rather than getting them at perfection in the first instance. The primary use cases should be the “sunny day” scenarios; these are scenarios that describe what happens when everything “goes well”. These scenarios are very important, firstly because they account for what happens in most of the cases, and secondly because they will help us write the edge cases, or “Rainy day” scenarios.