On Tue, Nov 1, 2016 at 2:25 AM, Kasey Speakman <[email protected]> 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
