1. 2

  2. 3

    I found this too vague and theoretical to be of use. I’m left without any idea of how to solve a specific problem with this architecture, so the claims at the end seem hyperbolic.

    Some examples might help. Not necessarily actual code, but something less hand-wavey. Else you’re still in the domain of the Monty Python “How To Do It!” Sketch.

    1. 1

      Agreed. Still coming at it from top-down, the next step is to take cynefin and map it to some sample onion code. Also take the CAS attributes and map it to code smells.

      Not impossible by any means. It’d be fun. I just felt that I had to stop somewhere, and 4,000 words is enough for any one essay.

    2. 3

      If you use the Onion Architecture, you and your friends will create little chunks of code that do one and only one thing and are simple to reason about from the outside.

      This seems naive to me. The available pieces of a system affect what its global dynamics can be. As a trivial example, you can’t implement distributed two phase commit unless you have some support in the individual data stores. It gets far more subtle from there. Consider the thundering herd phenomenon in handling retries. The choice of simple behavior in each client has profound implications on the global’s system’s dynamics.

      Type Theory is the basis of all computer science.

      Citation needed, perhaps? This is not at all obvious to me.

      1. 2

        Personally, I prefer the seasons of the Discordian calendar, which divide lifecycles into five periods:

        • Chaos: the system is emergent
        • Discord: people argue about what the system should do
        • Confusion: the system works, but nobody understands it
        • Bureaucracy: people are beholden to the rules of the system
        • The Aftermath: the system is part of society

        At no point are people required (or even allowed) to understand.