Internal metadata

[endersoncosta]

We have a problem with the buchu when we need identify the usecase by an name for example.

Aiming at it i beleave that we need a metadata with the purpose of identify the usecase internaly, example, the glue herbs2gql still use the name of usecase wrongly that should be used to explain the scenary cleary, and don't to identify like a variable or function.

Thinking about that and talking with you, I beleave that we can use for this purpose, something like:

identifier or name

with this we can use that metadata universally and the glues can use this too.

What you think??

[thgpdr]

I'm a fan of identifier inside metadata since we can use him for default names for routes or query's/mutations. The use case description its not always translatable for them. Even offering the custom route/query/mutation option, I think identifier fits much better for this case.

Besides, having a unique 'identifier' for a use case opens a whole another world for metadata consumption. We can benefit from it on Herbs Shelf, specially if we are talking about direct use case calls.

[dalssoft]

if no explicit identifier is given the default identifier should be the camel case concatenation of the description:

usecase('Create Item', {
...

uc.identifier // `CreateItem`

this will avoid breaking changes

[dalssoft]

The use case description its not always translatable for them [routes or query's/mutations]

I guess you are right. However, we should (1) separate the concerns here and (2) try to make the description good enough for both uses.

(1) If there is a name that works better for the infrastructure layer, this config should be there, not inside the use case (2) We should try to avoid using Get if the use case has already Retrieve or Read in the description

[endersoncosta]

Talking with @maikmb he do a sugest to use ShortName, with this, we can avoid the wrong idea like use an uuid or an generic number.

what you think?

in addition, we could add a metadata that describes the "request" of the authorize, something like authorizeRequest, with this, we can show in documentation how to get authorization in the use case...

[dalssoft]

ShortName implies that Create list description, with space, is valid. However, it shouldn't. At least for the problems we are trying to solve.

[italojs]

I think we could to have a filed meta inside the usecase, so there we could to override some metadatas like the name aaaand we could to create new custom metadata like:

usecase('my usecase': {
meta: {
   name: 'blabla', //used in many glues
   group: 'blabla' // used into herbs2rest
   entity: 'blabla': used int herb2rest
   metadataForMyNewGlue: { blabla: 'blabla' } // used to create new glues
},

request: [...],
response: [...]

[...] 

}

I think it reforce the domain orientation philosophy and facilitate for new glues be generated using only the usecases

[dalssoft]

Now with herbarium it is possible to:

(1) create a ID for the usecase, entity, etc:

module.exports =
    herbarium.entities
        .add(Item, 'Item')   // type and its ID. this ID can be used as the "System Name" of the object
        .entity

a reinforcement we can make / implement on herbarium is to accept only "system names", so no spaces or special chars in order to make sure it will be correct everywhere. PR are welcome.

(2) add metadata

module.exports =
    herbarium.usecases
        .add(createItem, 'CreateItem')
        .metadata({ group: 'Items', operation: herbarium.crud.create, entity: Item })
        .usecase

more info: https://github.com/herbsjs/herbarium#adding-objects-and-metadata

Given that we are reinforcing the use of herbarium for this kind of metadata, I'm closing this issue.