How to name a new service in OFN


Follow up from discussion about location of services here where we define most OFN services will end up in app/services (or within engine_name/app/services/. And we will have some folders like app/services/reports, etc.

I create this thread to clarify and get consensus about services naming and structure.

The current list of services we have is this:

  • cart_service
  • create_mail_method
  • create_order_cycle
  • embedded_page_service
  • line_item_syncer
  • order_cycle_form
  • order_factory
  • order_syncer
  • order_update_issues
  • reset_order_service
  • restart_checkout
  • search_orders
  • subscription_estimator
  • subscription_form
  • subscription_validator
  • subscriptions_count

We should decide how to name a service.
In 16 services, we have 6 different approaches here!!!

  1. named service - pattern <resource.>_<actor.>
    • examples: subscription_estimator, subscription_validator, order_syncer, line_item_syncer, order_factory
  2. named action - pattern <action.>_<resource.>
    • examples: create_mail_method, create_order_cycle, restart_checkout, search_orders
  3. resource service - pattern <resource.>_service
    • examples: cart_service, embedded_page_service
  4. named action service - pattern <action.>_<resource.>_service - a mix of 2 and 3
    • examples: reset_order_service
  5. named action with resource first - pattern <resource.>_<action.> - a variation on 2 with resource name first and then action name
    • examples: order_update_issues, subscriptions_count
  6. resource - pattern <resource.> - like in option 1, no indication of action allows for more than one action
    • examples: order_cycle_form, subscription_form

It’s a mess :smiley:

I believe we can accept two of these but not more than 2. Let’s choose?

Additionally there is the question of what is the method name inside. We have some services where we use the method call(). We can 1. be flexible and allow both call() and something else, or 2. we can disallow call or 3. we can enforce call on most services.

My opinion:
I accept the (new for me) fact of only having single action services which means excluding options 1, 3 and 6 as long as we keep the resource name in the beginning of the file name (so different services/actions on the same resource stay together in the list), which means excluding 2 and 4. This is my logic to vote for one single option acceptable which is 5.
Re the method name, I don’t like the pattern… I am not sure what’s the best convention here.

What do you guys think? :smiley:


Thank you Luis, this is a great summary. I’m not exactly sure which one is my favourite, but there are some I dislike. Maybe we can reduce the options and then discuss them in more detail.

    1. named action like search_orders: I don’t like how different actions of the same object are not grouped together in a file list. For example search_orders and update_orders are in different places. We would have similar actions together though: search_line_items and search_orders would be together, but that is not a benefit to me.
    1. resource service like cart_service: The suffix _service is redundant. The only content in the name is the name of the resource. So what’s the difference to the model? We need to put the purpose of the service into the name.
    1. named action service like reset_order_service: The suffix _service is redundant again. If we omit it we have the same as number 2 named action.
    1. resource like subscription_form: It smells like a model. If it’s a service, it should be about an action. If it’s about holding data, it’s a model.

Qualities I like:

  • Describing the action or field of actions, because services are about actions.
  • Grouping similar files together, for example subscription_estimator and subscription_validator are close together in the file list.
  • Describe the domain of the service instead of the resource. For example, I prefer stock_updater over variant_updater or variant_stock. A StockUpdater could actually change the stock for products or stock items as well. These feature would be nice together.

So after writing this, I do have a favourite: named service
And as an alternative I like 5. resource named action for single method services that we extract from a model. It’s one step in the refactoring towards the named service that can combine several methods or be applicable to several models.


All controllers do have the _controller and from outside, for example, when a service is used in a controller, having or is very different.

This makes me think of a 7th option, a mix between 4 and 5:
7. named action service with resource first** - pattern <resource.>_<action.>_service
- example: order_reset_service or subscription_count_service, mail_method_create_service

I prefer smaller services. I prefer resources rather than domains, for simplicity. We can keep all resources of the same domain together under a folder, so we can have /app/services/stock/variant_updater, same for subscriptions.

Yes, services are mostly about actions BUT they should do DTO stuff, we shouldnt put data logic in the models just because it’s data, specially if it doesnt depend on the ORM mappings.

That’s why I think we need to keep 6 for these case:
how would you call this service?

I keep my vote on 5. 1 and 7 are ok.


I would call that one StockLevelAggregator. But I’m also wondering if it should be a data structure:

stock =, requested_variant_ids)

It could use proper OOP data structures instead of hashes and make the intention of wrap_json_infinity even more clear.

That infinity problem should be solved in a JSON encoding library though. It’s independent of OFN.


Yes, I agree the hashes are very bad, but without changing the code, what name would you give it?

  1. stock_levels_aggregator
  2. aggregate_stock_levels
  3. stock_levels_service
  4. aggregate_stock_levels_service
  5. stock_levels_aggregate
  6. stock_levels
  7. stock_levels_aggregate_service

in this case we could have resource as stock_levels only or with variant_stock_levels.

I’ll do the create_mail_method:

  1. mail_method_factory
  2. create_mail_method
  3. mail_method_service
  4. create_mail_method_service
  5. mail_method_create
  6. mail_method
  7. mail_method_create_service

and the * reset_order_service:

  1. order_resetter
  2. reset_order
  3. order_service
  4. reset_order_service
  5. order_reset
  6. order
  7. order_reset_service