4 comments

[ 5.3 ms ] story [ 19.5 ms ] thread
I always wonder who the audience is for these things, as I assume that most people in some kind of software engineering principle will have gone to university, but I suppose this is a good read for anyone who went the bootcamp route. Use cases are very important and it oftens stumps product owners when I ask them about use cases because they haven't really thought out what clients are asking for and how it relates to users. Many "super urgent" feature requests can be reprioritised when the product owner understands how it actually relates to the system.
Use cases tend to fall apart as relevant to guiding developers once the domain model necessarily diverges from the implementation, which is very common. I don't see how they're more useful than general user stories: if someone hasn't thought about what the users actually want, and why they need to achieve something, that's not a software problem.
I actually like use cases. The code shouldn’t diverge from the actual procedural use case. The domain layer defines the services, which define the contract for data retrieval and possibly complex process. The use case produces a set of data that the invoker would use to produce the response to the user.
Great article!

Given the absence of libs / frameworks to help in the domain part of the architecture, we created Herbs [1], where our proposal is to shift the focus of developing a microservice from the infrastructure (http, DB, logs, etc) to the domain , with an emphasis on use cases [2] and entities [3].

It may seem small but it changes a lot where you put energy into developing your software, especially maintaining it.

[1] https://herbsjs.org/

[2] https://herbsjs.org/docs/usecase/getting-started

[3] https://herbsjs.org/docs/entity/getting-started