In a moment of the industry where every day we have new frameworks and tools, is a good moment to remember old things.
While the problem domain defines the environment where the solution will come to work, the solution domain defines the abstract environment where the solution is developed.
The differences between those two domains are the cause for possible errors when the solution is planted into the problem domain.
Problem domain and solution domain are essentially the same? Looks problematic to me. Problem: “I have no money”. Solution: “I’ll rob a bank”. An ironic programmer.
In respect to a given problem (or set of problems), the solution domain (or solution space) covers all aspects of the solution product, including:
- The process by which the solution is arrived at.
- The environment in which it is constructed.
- The design, construction, testing, operation, and functions of the solution product itself.
Confusing the problem with the solution is one of the great dangers of IT projects, resulting in software that may be a very good solution to some problem, but not to the specific set of problems its users face. (you can read waterfall model between lines and why agile development techniques arrived).
Another important variable is time.
How much time do you have for design the solution? Do really need the best solution or could be just a great solution? What is the balance between the cost of the time to find a enough good solution?
I always related it in a more visual way with the algorithm Hill Climbing algorithm that is part of algorithm intelligence division, used for search a good solution in a resonable fraction of time.
