FAQ 4.04 Should the software architecture be based on the policy of the problem?

No that would be totally insane.

The policy of any single problem is unstable. Software systems based on the least stable element (the problem) are inflexible, cannot respond to changing requirements, and are doomed to become brittle.

Software should be written so that changing the requirements doesn't break the architecture. Basing the architecture on the most stable element, the problem domain, accomplishes this objective.

Note that software can survive problem changes only within the confines of the problem domain. It's unreasonable to expect a system that was originally designed for the problem domain of compilers to work for cellular telephones, since this would be changing the problem domain rather than just the problem.

From an architectural standpoint, the message is to usually emphasize the problem domain rather than technical infrastructure. However, there are occasional counter examples, and this is why intimate knowledge of both technology and the problem domain is so important.