3 ms·
We've come around to something like the "imperative shell, functional core" pattern. All the business logic is purely functional (so no database calls or side
by bontaq 5y ago
We've come around to something like the "imperative shell, functional core" pattern. All the business logic is purely functional (so no database calls or side effects), and any data needs are done as close to the edge of the system as possible.
You can do it in any language, FP languages can help enforce the distinction. For going even more functional, in FP languages that support it, free monads and effect systems allow you to define interpreters for effects and you can write code more or less like you would non-functionally, but the interpretation can be pure (say hardcoded results for a query) for tests, and impure for actually running. Basically fancy dependency injection, but for everything.
- luftbbb 5y agoWhen you say imperitave shell, am I correct in interpreting this shell to be the external interfaces to other systems - both incoming and outgoing eg api and dB layers? At this juncture you'd then take the data and process it in the domain core functionally? It seems like a plausible solution but it is not purely functional which leaves my question open.. How does one do it purely functional? By going "more functional" with the free monad and effect system approach, do you mean the Result design pattern as seen in rust and F#? If you have any working example I can dig in to that would be welcome
- ledauphin 5y agoagreed on IS/FC. and though I've not yet had the opportunity to use "proper" effects, I've ended up writing some micro effect systems that apply to specific systems we interact with a lot. it makes testing and reasoning about the system so much saner.