Arquitectura de Software

• The Hillside Group
  
  • Kent Beck
    
  • Grady Booch
    
  • Ralph Johnson (Gang of Four, Dessign Patterns)
    
  • Ward Cunningham (Creator of the Wiki)
    
  • Richard Gabriel
    
• The eXtreme Programming (XP) Group
  
  • Kent Beck
    
  • Ward Cunningham (Creator of the Wiki)
    
  • Martin Fowler
    
  • Michael Feathers (Working Effectively with Legacy Code)
    
  • Ron Jeffries
    
• ThoughtWorks London
  
  • Lean enterprise, Devops Handbook, Accelerate (Books)
    
  • Jez Humble, Dave Farley (Ontinuous Delivery)
    
  • Dan North (BDD)
    
  • Nat Pryce
    
  • Sam Newman (Microservices)
    
• Stack Overflow creators
  
  • Coding Horror (Jeff Atwood)
    
  • Joel on Software (Joel Spolsky)
    

• https://zwischenzugs.com
  
• https://lukeplant.me.uk
  
• https://thevaluable.dev/
  
• https://www.destroyallsoftware.com
  
• https://blog.sunfishcode.online/
  
• https://jessitron.com/
  
• https://jvns.ca/
  
• https://lethain.com/
  
• EA Voices – Aggregated enterprise architecture wisdom
  Want to get an overview of what the enterprise architecture community blogs about? I did, so I created this ‘planet’.
  A river of news and opinions about enterprise architecture, EA Voices is a thematic aggregator of enterprise architecture blog feeds.
  A robot fetches blog posts from over 250 enterprise architecture bloggers within the hour of being published to the original blog.
  

I have a mantra for suffering-oriented programming: “First make it possible. Then make it beautiful. Then make it fast.”

Functional programming seems necessary only when dealing with distributed systems.
Therefore, unless you’re dealing with a distributed enough system, you can get away with not using functional programming, i.e., imperative

• Backups (maximum consistency, no liveness)
  
• Version control (as an extension of backups)
  
• Tests
  

                                      CRP (ISP)
                                Split to avoid unneeded releases
                                exclusive (smaller components)

                                          /\
                                         /  \
                                        /    \
                                       /      \
                                      /        \
                                     /          \
                                    /            \
                                   /              \
                                  /                \
                                 /                  \
                                /                    \
                               /                      \
                              /                        \
                             /                          \
                  Too many  /                            \ hard
                components /                              \ to
                   change /                                \ reuse
                         /                                  \
                        /                                    \
                       /                                      \
                      /                                        \
                     /                                          \
                    /                                            \
                   /                                              \
                  /                                                \
                 /                                                  \
                /                                                    \
               /                                                      \
              /                                                        \
             /__________________________________________________________\
                              Too many unneeded releases
    REP (weak)                                                           CCP (SRP, ~OCP)
    Regroup for reusers                                                  Group for maintenance
    reusability                                                          developability
    inclusive (larger components)                                        inclusive (larger components)

Composable: plays well with others
Unix philosophy: does one thing well
Predictable: does what you expect
Idiomatic: feels natural
Domain-based: the solution domain models the problem domain in language and structure

https://www.reddit.com/r/programming/comments/txw5s6/in_defense_of_complicated_programming_languages/

https://bellmar.medium.com/five-koans-of-software-architecture-f9f7305598c2

1. “Those who should decide on the architecture are those that will be on call for it”
   
2. “Build it the stupid way first”
   
3. “Optimization is death”
   
4. “Graph databases are lies”
   
5. “Don’t let dependencies own the logic”
   Now what the value of the technology you’re building is and know where the logic that creates that value lives. And then make damn sure you own that logic.
   

—

• Architecture Is Easier When It’s Harder
  You shouldn’t jump in with brilliant ideas if you’re not going to own them.
  You should keep things simple for as long as possible until you know what your usage goals are.
  You shouldn’t assume technology you don’t understand has some magic or secret sauce under the hood.
  You shouldn’t default to products and tools owned by other people until you know what value your software brings to the table.
  

https://lukeplant.me.uk/blog/posts/everything-is-an-x-pattern/
At the end, this is standarization
“Everything is an X” is a very high level pattern
When we say “everything” here, we’re talking very loosely — many things in the system are not, in fact, instances of “X”, but are something lower level, or just completely different. “Everything is an X” really means “a surprising number of things in this system are an X”.

The real abstraction here is just Lots Of Things Are Streams.

All non-trivial abstractions, to some degree, are leaky.
Abstractions fail. Sometimes a little, sometimes a lot. There’s leakage. Things go wrong. It happens all over the place when you have abstractions.
https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/
«A leaky abstraction can be falling from simple to complicated or even chaotic, according to Cynefin Framework»

https://lukeplant.me.uk/blog/posts/test-smarter-not-harder/

• Same concept as Configs suck, use code
  
• Write explicitlly all the tests vs generate them using code
  

• The “test harder” religion interprets this as:
  

    For every entry point
        Write a test that
            Ensures non-authenticated requests return 403
  

  That’s a lot of tests, and even worse is that you have to remember to write them.
  

• “Test smarter” says:
  

    Write a test that
        For every entry point
            Ensures non-authenticated requests return 403
  

  That’s one test. “Write a test” is executed in developer time, so in the first example the loop (“For every entry point”) is also executed in developer time. Push the loop inside the test, and it gets executed in computer time instead.
  

While much attention has been focused on high-level software architectural patterns, what is, in effect, the de-facto standard software architecture is seldom discussed. This paper examines this most frequently deployed of software architectures: the BIG BALL OF MUD. A BIG BALL OF MUD is a casually, even haphazardly, structured system. Its organization, if one can call it that, is dictated more by expediency than design. Yet, its enduring popularity cannot merely be indicative of a general disregard for architecture.
These patterns explore the forces that encourage the emergence of a BIG BALL OF MUD, and the undeniable effectiveness of this approach to software architecture. What are the people who build them doing right? If more high-minded architectural approaches are to compete, we must understand what the forces that lead to a BIG BALL OF MUD are, and examine alternative ways to resolve them.
A number of additional patterns emerge out of the BIG BALL OF MUD. We discuss them in turn. Two principal questions underlie these patterns: Why are so many existing systems architecturally undistinguished, and what can we do to improve them?

http://www.laputan.org/mud/mud.html

https://www.reddit.com/r/programming/comments/rznxd0/desired_state_systems_how_react_kubernetes_and/

OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things.
I’m sorry that I long ago coined the term “objects” for this topic because it gets many people to focus on the lesser idea. The big idea is messaging.
Alan Kay

Notably, inheritance and subclass polymorphism were NOT considered essential ingredients of OOP

tldr; Use https://en.wikipedia.org/wiki/Tz_database unless you’re working in the energy business and have to consider time differences between countries

tldr; Use an internal representation of datetime type as long as possible and then convert to str when necessary
By keeping it as a datetime you gain flexibility as you can add/substract timedeltas

https://www.reddit.com/r/programming/comments/u21syc/innovating_beyond_libraries_and_frameworks/

• I have been a big fan of the write libraries, not frameworks argument. we should start to value principles over patterns, patterns over libraries, and libraries over frameworks.
  
• Definitions
  
  • Framework: Usually someone else’s code that calls your code. Your code will need to conform to constraints/boundaries/conventions
    
    • ↓ often hard to code around these constraints
      
    • ↑ quicker coding since you tend to get a lot of useful functionality out of the box
      
  • Library: usually someone else’s code that you call from your code. A library tends to be some code that imposes fewer constraints on your code as compared to frameworks. By using one or more libraries you’re able to reuse someone else’s code to solve your problems. Libraries are easier to combine and interchange, while putting frameworks on top of frameworks can lead to a bad time.
    
    • ↑ fewer constraints that a framework
      
    • ↑ reuse someone else’s code to solve your problems
      
    • ↑ easier to combine an interchange
      
  • Pattern: descriptive, reusable approach to writing your code (see: software design pattern). Patterns range in their vaguenes, applicability and prescriptiveness.
    Examples of programming patterns include early-return pattern, builder-pattern, actor model, model-view-controller, onion architecture, microservices, majestic monolith, monorepos, and flux architecture.
    
  • Principle: This is some general guidance or philosophy expressed as rules (like a rule of thumb) that helps you write good code.
    Examples of principles include SOLID principles, Don’t repeat yourself (DRY), You Aren’t Gonna Need It (YAGNI), Agile manifesto, Law of Demeter, Hyrum’s law. There are many more to be found out there, and as I write this I just discovered this site that collects programming principles, nice!
    

caution here about not to overuse them and/or apply them in ill-fit contexts (see: Law of the instrument). For example The Wrong Abstraction → critique of developers’ tendency to apply the DRY principle at all costs.

Producer-consumer problem → When using a framework, your code is a producer and the framework is a consumer. When using a library, your code is the consumer and the library is a producer

IoC inverts the flow of control as compared to traditional control flow. In IoC, custom-written portions of a computer program receive the flow of control from a generic framework.
Inversion of control carries the strong connotation that the reusable code and the problem-specific code are developed independently even though they operate together in an application.
Callbacks, schedulers, event loops, dependency injection, and the template method are examples of design patterns that follow the inversion of control principle, although the term is most commonly used in the context of object-oriented programming.
Inversion of control serves the following design purposes:

• To decouple the execution of a task from implementation.
  
• To focus a module on the task it is designed for.
  
• To free modules from assumptions about how other systems do what they do and instead rely on contracts.
  
• To prevent side effects when replacing a module.
  

Inversion of control is sometimes facetiously referred to as the “Hollywood Principle: Don’t call us, we’ll call you”.

In object-oriented programming, there are several basic techniques to implement inversion of control. These are:

• Using a service locator pattern
  
• Using dependency injection; for example,
  
  • Constructor injection
    
  • Parameter injection
    
  • Setter injection
    
  • Interface injection
    
  • Method Injection
    
• Using a contextualized lookup
  
• Using the template method design pattern
  
• Using the strategy design pattern
  

This wiki is a place to collect, examine, and discuss software design knowledge in a systematic way. Currently there is a strong focus on (object-oriented) design principles (SOLID, GRASP, DRY, KISS, …)