Win a copy of Testing JavaScript Applications this week in the HTML Pages with CSS and JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Bear Bibeault
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
  • Tim Cooke
  • Liutauras Vilda
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • fred rosenberger
  • salvin francis
  • Piet Souris
  • Frits Walraven
  • Carey Brown

Righting Software: Core Use Cases

Posts: 8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
Posts: 12
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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.

Ranch Hand
Posts: 106
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well explained Juval Lowy.

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:
Thread Boost feature
    Bookmark Topic Watch Topic
  • New Topic