Righting Software: Core Use Cases

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?

Márcio,

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.

Juval.  

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.

Hi Juval Lowy. How can I find code example of The Method. I am reading your book.

a particular use case can change in only two ways: Either the sequence
itself changes or the activities within the use case change.
...
Manager components encapsulate the volatility in the sequence, whereas
Engine components encapsulate the volatility in the activity.
...
Since use cases are often related, Managers tend to encapsulate a
family of logically related use cases, such as those in a particular
subsystem.
...
Managers may use zero or more Engines. Engines may be shared between Managers.
...
Managers can directly call Engines.
...
Engines are really just an expression of the Strategy design pattern used to implement
the activities within the Managers’ workflows.

In the book I did not find any code example so not understanding how to implement it or how the Manager or Engine actually look like in The Method.

I understand that I have to somehow use the strategy pattern. But, I am not understanding how to do it?

Please help.

I haven't read the book, and I'm not sure if the author is still around to answer your question, but I could imagine something that roughly looks like this:
interface Vehicle {  void start();  void stop();  void accelerate(Acceleration acceleration, int duration, TimeUnit unit);  void decelerate(Acceleration acceleration, int duration, TimeUnit unit);  void turn(Rotation rotation, int duration, TimeUnit unit); }final class Car implements Vehicle {  ... }final class Shopper {  private final Vehicle vehicle;  Shopper(Vehicle vehicle) {    this.vehicle = vehicle;  }  void driveToStore() {    // perform sequence of operations on vehicle  } }
Here, Car is an engine that implements Vehicle, and Shopper is a manager that uses a Vehicle to drive to the store.

Car is an engine because it just implements some functionality. That functionality is not a goal in itself. It is not a real use case.

Driving to the store is a real use case, and Shopper is a manager because it uses engines to implement that use case.

We can see the Strategy Pattern being used here by virtue of the Vehicle interface. The Shopper doesn't really care how the vehicle is implemented, just that it has a vehicle and that that vehicle functions as expected. Here, using a Car is one strategy for driving to the store. Using a Bike could be another strategy.

Thank you very much.