It would be awesome to have a more complex but practical example that captures this.
The reservation scenario from the second post looks like an interesting use-case. I will think more about it. On Tue, Nov 1, 2016 at 3:33 PM, Kasey Speakman <[email protected]> wrote: > Oh, and yes, most of these layers are on the server side if we are talking > about an Elm client application. Generally speaking, the client app serves > to collect and prepare data to submit use cases. So it reads data from an > API and submits data to an API. > > > On Tuesday, November 1, 2016 at 8:16:40 AM UTC-5, Kasey Speakman wrote: >> >> It is silly, and I don't know why it was done this way. But that's the >> world I live in now. It's easy to justify one case at a time, but all >> tolled it adds up. >> >> As far as "layers", you should check out these two posts in order. >> >> http://blog.ploeh.dk/2013/12/03/layers-onions-ports-adapters >> -its-all-the-same/ >> http://blog.ploeh.dk/2016/03/18/functional-architecture-is-p >> orts-and-adapters/ >> >> On Tuesday, November 1, 2016 at 3:31:07 AM UTC-5, Peter Damoc wrote: >>> >>> 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. > -- 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.
