On Tue, Nov 1, 2016 at 2:25 AM, Kasey Speakman <kjspeak...@gmail.com> wrote: > > So here's a concrete example of how we did it wrong in our legacy system. > To close a trainee's registration as "No Show", an employee has to create > an exam against that registration and grade it as 1%. This is an implicit > concept which our employees and our software understand as "No Show". > Instead of making it explicit by programming in a No Show > button/action/status, we have to *program the employees* (current and > future) to recognize this situation. >
Wow... this is so silly that it almost looks like a joke. Unfortunately, I've seen enough to know that it happens. However, looking at a fresh system that one might want to design it seams to me like there are 3 possible layers Layer 3. Business Objects Layer - concerned with validity of state transactions Layer 2. Data Modeling Layer - concerned with what needs to be persistent Layer 1. Storage Layer - concerned with connections, locations, raw entity storage Layer 1 would be the implementation of the library I would like to have in Elm. Ideally, something similar to Datomic. Layer 2 would be implemented by the user using Layer 1 in a declarative way similar to Json.Decode Layer 3 would be implemented by the user using Layer 2 in a way that is similar to the Elm Architecture (layer 2 Model + some update) What do you think? Am I misunderstanding what you described? -- There is NO FATE, we are the creators. blog: http://damoc.ro/ -- 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.
