Let's say I'm using shadcn's Dialog [1] on my web target, which has many subcomponents (Dialog, DialogTrigger, DialogHeader, etc). How many of those am i representing with a 1-to-1 `UC`? Is it just the parts that are on the IO seam, like a UC for opening the dialog, UC for closing a dialog, and UC for submitting a dialog? Or is it also for things the user sees like UC for header, UC for content, UC for buttons panel?
There is obviously some cost to expressing the interface between the product/target/usecase. What exact benefit is that cost getting me? do i know that if i expose a certain use case in one target then i have to explicitly decide if i'm going to expose (or not expose) it in a different target, which helps me get consistency/governance between my app as it grows? does it help me "integration test" by application in isolation, in a "similar" way that pact [2] helps with integration testing microservices? (ex: the mobile app relies on X input, but from the ts interfaces, the tool can detect that the web-api is no longer defining an output for that api. if so, is this on the /api/v1/resource level? the openapi schema for a json body response level?). do i get a mono-build-system, where everything flows together and i just say "libmodulor build" and "libmodulor deploy" and I'm good to go?
said in another way: many of the people on HN have a backend api, a react SPA, and a mobile app. what types of problems do i have now which libmodulor solves?
[1] https://ui.shadcn.com/docs/components/dialog
[2] https://pact.io/