in e2e. that function name is the use case. and the parts inside are the steps taken to accomplish that use case. same thing as use case pattern.

and user story is what the use wants. like as a user of the system i want to post vacancies to new job posts.

then use case name is, post job vacancies. and the steps taken to accomplish that. again at a big level, not not deep. like on publish save to db. then notify others. subscribers, send mail to company hr. and all that. thats the flow to accomplish this use case. and all these describe a use case.

they both should be granular to a level possible. single responsibility principle. like doing the bare minimum. should only do one coherent thing. low coupling high cohesion…

just follow these principles….

again as with ut and just everywhere. you could just ask, what you want? that all. what i want. what you want to do? that is the function name.

and anyways its always evolutionary design.

what i want. just one question? thats all…

i want to post job vacancies. and then inside the defining the flow to accomplish that. the behavior expected form the system. what is/should system be expecting and all that…

so good. and its self documentation… thats what i want…