Opinions regarding use of gerunds (e.g. Ordering, Billing, Scheduling) as context names

Hey all.

I’d like to know your thoughts on whether it would be helpful to review the notion of establishing the standard of using gerunds for contexts names.

This comes from the notion of considering a given business as a facility that facilitates the performance of various operations by its interfacers.

Each facilitation would be regarded as contexts comprising interconnected operations, some pretty familiar examples would be cataloguing, carting, ordering, billing, scheduling, registering, etc. This also helps ameliorate the use of explicitness with which contexts and resources are separated as a standard practice.

I know this isn’t groundbreaking or anything, and the shift from the current approach to the suggested one might seem insignificant, but I think the use of gerunds ensures that the operations of the business are the main point of consideration.

Anyway, I’d appreciate your views, I’m currently just working through setting up some holistic steps for implementing some cool web features using the framework and this occurred to me.

The phoenix framework supports pretty rapid development.

I wouldn’t want to require one or the other. In my experience, sometimes it makes sense to use a gerund and sometimes it doesn’t.

Never heard the word gerund before.

1 Like

Just out of curiosity when wouldn’t it make sense to use a gerund? I ask because the contexts pertain to the business logic, and generally that amounts to the business doing, or facilitating the doing of something.

The standard would just be an additional mental aid for the avoidance of accidentally making a context pertain simply to the managing of one resource’s functionality, or the functionality of too many loosely connected resources, simply by suggesting (by lexical convention) that the context pertains to tightly related operations that the business facilitates.

Not everything is about a business doing something. If the app was a database, would you need to call the part related to storage Storing? I would call it Storage.

1 Like

Accounts is another pretty common one

1 Like

My point was not really that the context pertains to the business doing something but that it pertains to the business facilitating interfacers doing something, such as, in your example, the facilitation of data storing.

Under this context of data storing there may be various other operations like processing and cleaning of data, categorising data, and summarising if the data is to be used for reports etc.

If I say Accounts, I could also say Applicants, or Services, Branches. It feels a lot like a resource, whereas if I say, Registering I’m asking myself what is being facilitated by this area of functionality, while also thinking about what other operations might come under such facilitation.

Registering is obviously too granular and wouldn’t be a context in and of itself.

Edit: Then again, registering need not pertain only to registering the account alone, but also registering all interactions with the business under that account, including account modification, transactions, account closure etc, since an account is ultimately a means by which a user’s personal interaction with the business is registered.