Hi Juval, I understand one central point you propose for reaching a stable architecture of a system is identifying the core business use cases. But I guess it is not always easy to identify such use cases unless you are fully involved with that business.
How do you achieve that correct identification of core use cases in short live projects?
The core use cases are part of having composable design, where the decomposition (the making of the architecture) does not change, while the use cases change all the time (more in Chapter 4).
All businesses always have core use cases, and as the book explains, the core use cases represent the essence of the business. As such the core use cases do not change (unless the nature of the business changes which is both infrequent and unlikely).
Nowhere in the book did I say it is easy to find. Sometimes, people do not understand their own business.
To find the core use cases you must understand the business. Note, I am referring to the business, not to the domain-specific details. For example, life insurance companies likely have the same core use cases, but the details of how they go about it (like calculating the risk) could be very different. As such you do not have to be fully involved in every details. What you must have is a keen nose for business. That is the best way to make it easier.
The duration of the project is immaterial. All commercial software systems address some business need. As such there are always some core use cases to the business.
My understanding on this is ,the central theme of any business domain or business operations would
eventually lead you to the Central Use Cases, and other supporting uses cases get spun out of there
if you want to organically grow the system ,but that is the old mind set that i have seen time and again.
Cob is sand, clay and sometimes straw. This tiny ad is made of cob: