FAQ 4.03 What should the architecture be based on, the problem being solved or the problem domain?

The problem domain.

One of the primary goals of the software architect is to build a system that will survive changes in requirements and that can be adapted to new and related problems. To achieve this goal the system architecture must have a stable base.

The specification of a single problem that is to be solved is unstable, since it depends on the whims of the customer and therefore is unsuitable as the basis for the system architecture. The problem domain is much more stable, because it is an artifact of the world in which the customer lives.

For example, every order entry system must deal with orders, customers, prices, quantities, payments, addresses, sales reports, and so on. These entities represent the problem domain and are stable across all order entry systems.

However, each particular order entry system has different parameters that reflect the customer's current requirements based on the current business situation, including different placement of fields on the screen, different colors for different fields, different currencies for multinational applications, and so on. Furthermore, some order entry systems are implemented as PC applications, others are implemented as Web-based applications, while others are implemented as Interactive Voice Response systems.

The moral for the software architect is that the system architecture should be based on the problem domain because the needs of customers change more rapidly than their world does.