Oh, Happy Day !

Suppose, you are an architect of a new web portal framework. For this purpose, you came up with a prioritized list of requirements and use cases. Now, you are starting to design the framework. First use case of consideration is login of a user who should then redirected to his personal portal. But now you are starting to consider more details:

• what if the user provides the wrong credentials?
• what if you encounter memory outeage when instantiating new objects?
• what if the communication breaks down?
• what if you can't read the user's preferences from the file system?
• what if data already has been locked by someone else?
• what if the HTTP request does provide a user agent you don't support?
• ...

You are a smart architect who never forgets any detail, a perfectionist in terms of software engineering. Thus, you are starting to cover all these exceptions in your architectural design. A few use cases later you are lost in design erosion, trapped in a web of entities and relationships.

On one hand, it is essential to consider all of these exceptional cases and list them in the use cases. Most of the exceptional issues are cross-cutting, re-apperaring in different places of your system. On the other hand, if you start to consider them from day 1, you will be doomed to fail in any non-trivial development project.

The recommendation in architectural design thus reads as follows:

• In the beginning only start with the main flows (the happy day scenarios). Those should be the ones driving and guiding your core architectural design.
• In addition, you should come up with project-wide strategies how to cope with exceptional cases. Strategic documentation should be made available and mandatory for all developers with description how to deal with exceptions, transactions, synchronization issues, and the like.
• The exceptional cases will together with non-functional requirements help extending or changing the domain-specific architecture and infrastructural parts.

Of course, it would be fatal to rely on happy day scenarios only. How often, did I encounter finite state machines with all "happy day nodes and edges" where no one thought about the error states, because errors are for pussies. It is not the matter of ignoring exceptional cases. It is more on doing happy day scenarios first to obtain a stable strategic base-line and then thoroughly integrating the exceptional cases.

From now on, you should always think of "happy days" when modeling your architecture :-)