Savelenko

(*
An exercise in modeling. Users can be verified or banned. A user can be banned only if their username is "offensive".

We assume the Onion architecture. Modules `User` and `Verification` belong to the model. Module `UserVerification`
belongs to the application layer. Data access layer is omitted completely; it should be fairly trivial.

Note that the verified/banned aspect of a user is modeled "externally" to the notion of user itself. In particular,
there are no "aggregates" below which combine all aspects of a user.
*)

Banashek

open Fable.Core
open Fable.Core.PyInterop
open Fable.Python.Json

[<ImportAll("sys")>]
let sys: obj = nativeOnly

let prettymaps: obj = importAll "prettymaps"
let matplotlib: obj = importAll "matplotlib"

akhansari

// ========= Event Sourcing in a nutshell

(*
    FriendlyName: string
        Aggregate friendly name.

    Initial: 'State
        Initial (empty) state we will start with.

    Decide: 'Command -> 'State -> 'Event list

JordanMarr

module DragDropPage

open Feliz
open Fable.React
open Fable.React.Props
open ReactDND

type Language = {
    Name: string
}

swlaschin

Architecture

• Use Onion architecture

  • Dependencies go inwards. That is, the Core domain doesn't know about outside layers

• Use pipeline model to implement workflows/use-cases/stories

  • Business logic makes decisions
  • IO does storage with minimal logic
  • Keep Business logic and IO separate

• Keep IO at edges

swlaschin

(*
CapabilityBasedSecurity_ConfigExample.fsx

An example of a simple capability-based design.

Related blog post: http://fsharpforfunandprofit.com/posts/capability-based-security/
*)
 
/// Configuration system
module Config =