Example Design of a Feature

Requirements for editing a widget

Suppose we are building a feature to edit widgets. Here is a rough outline of the requirements around how it should work:

1. A user views a form where they can edit a widget’s metadata.
2. The user submits the form with a validation error.
3. The form is rerendered, showing their errors.
4. The user corrects the error and submits the edit again.
5. The system then updates the database.
6. When the widget is updated, two things have to happen:
   • Depending on the widget’s manufacturer, we need to notify an admin to approve the changes.
   • If the widget is of a particular type, we must update an inventory table used for reporting.
7. The user sees a result screen.
8. Eventually, an email is sent to the right person.

This is not an uncommon amount of complexity. We’ll have to write a bit of code to make this work, and it’s necessarily going to be in several places. A controller will need to receive the HTTP request, a view will need to render the form, a model must help with validation, a mailer will need to be created for the emails we’ll send, and somewhere in there, we have a bit of our own logic.

The figure below shows the classes and files that would be involved in this feature. The WidgetEditingService is probably sticking out to us.