There is a danger in focusing on data over use cases. It's not a guarantee that you make this mistake (I have), but you know you've gone too far with it when most workflows are Load/Edit/Save (or Create/Save). And the user is left to know what field to change to have a specific effect in the system. I've seen this termed as data-centric. Seems okay at first but after a few years in production this leads to long user training times, brittle workflows, and high support loads.
Most businesses invest in custom software to accelerate businesses processes. So those should be the focus. For just data storage, low-code solutions could do that much cheaper. That said, CRUD is a part of almost all custom software because data must be collected to fulfill use cases (usually for the human factor, like seeing names instead of just IDs). Often the easiest place to start is with CRUD, because you need a way to populate data to work with anyway. But the database structure is the wrong thing to center a design on. On Saturday, October 29, 2016 at 8:34:48 AM UTC-5, Rupert Smith wrote: > > On Friday, October 28, 2016 at 10:58:34 PM UTC+1, Rupert Smith wrote: >> >> For example, if a user account must have an email address associated with >> it, if there is validation on the format of the email address and it cannot >> be null, then there is not need to write a specific transactional end-point >> to allow a user to update their email address, you can just let them modify >> and save the account record and they can still only perform that operation >> in a way that produces correct data. >> >> I take your point though about being able to hook into changes relating >> to specific events. >> > > I inadvertently picked an example with the email address that shows why > you want to hook into specific business events, because in this case you > might want to send a confirmation email with a link in it to confirm the > address when the email address is changed. In that case I would not allow > the email address to be set as part of a more generic 'save' endpoint, and > add a new end-point for the change email address as its own operation. Its > either that or add some code to detect the email change somehow - but I > think you are right, it better to have an explicit endpoint for it, then > very easy to hook into it as an 'event'. I like to start quickly by > starting with the open and generic data modelling with CRUD over entities, > and then refine things from there. > -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
