I am calling these series of posts “The Software Architecture Chronicles”, not because I think of myself as a great writer but because I find the name rather corny in a funny way! In this first post, I am going to talk about why I am writing this series of posts and what’s to come.

The importance of knowing our history

Those who fail to learn History are doomed to repeat it.

                                                                                                        Winston S. Churchill   

I find it important to learn from history, it can teach us a lot. At a personal level, we (eventually & hopefully) learn from our personal mistakes. As a country, history helps model our culture, helps create an idea of a group, an idea of ’us’, a national identity. It also helps us learn from our ancestor mistakes, like trusting people with very weird ideas, think WW2 …

For us, as developers, it helps us build on our predecessor developers knowledge. It helps us learn from their mistakes, from their paths, from their experiences: their knowledge. It helps us achieve higher grounds by “standing on the shoulders of giants“!

In my path to be a better developer, I’ve read a lot of articles, watched a lot of conference talks, and read plenty of books. I do my best to stand on the shoulders of giants!

One thing that puzzles me though, is that there are many opinions based on opinions based on opinions… And this works like the “Chinese whispering game”, where we end up with a distorted idea of what a paper, article or book really states.

So I set out to scavenge the internet for the original papers, articles, and books that state the concepts that I find of most importance for my work, and reason about them by myself.

These posts are the result of this reasoning, as I try to understand how these concepts came to be, in a somewhat chronological way.

Writing these posts forced me to read and reason a lot about all these subjects and helped me understand the techniques used today in software development and I hope these posts are helpful to more fellow developers.

Nevertheless, if you read something you don’t understand or disagree with, please let me know, I am perfectly open to discussing these subjects, learn from other people and change my point of view when I’m proven wrong.

Posts in The Software Architecture Chronicles

The Software Architecture Chronicles

Posts in The Software Architecture Chronicles

The Software Architecture Chronicles

Software Architecture Premises

Programming Language evolution

Architectural Styles vs. Architectural Patterns vs. Design Patterns

Monolithic Architecture

Layered Architecture

MVC and its alternatives

1979 – Model-View-Controller

1987/2000 – PAC / Hierarchical Model-View-Controller

1996 – Model-View-Presenter

1998 –”Model 1″ & “Model 2”

2005 – Model-View-ViewModel

???? – Model-View-Presenter-ViewModel

2008 – Resource-Method-Representation

2014 – Action-Domain-Responder

EBI Architecture

Packaging & namespacing

Domain-Driven Design

Ports & Adapters Architecture (aka Hexagonal Architecture)

Onion Architecture

Clean Architecture

Event-Driven Architecture

From CQS to CQRS

Service Oriented Architecture (SOA)

Explicit Architecture #01: DDD, Hexagonal, Onion, Clean, CQRS, … How I put it all together

Explicit Architecture #02: More than concentric layers

Explicit Architecture #03: Reflecting architecture and domain, in code

Symfony

Laravel

Zend

Aura

ReactJS

VueJS

Explicit Architecture #03: Evolving a project: from MVP to P

4 + 1 Architecture view model

Architecture quality attributes

Timeline

This is a rough timeline of software development evolution, as I perceive it after having read articles and books about all these subjects. I added links to where I found the date reference, and I put a “~” wherever I’m not very sure of the date, meaning “approximately”. We can also find a plethora of information about these things through the main Programming Paradigm page in Wikipedia.

I will talk about most of these subjects in this series of posts.

1950s

  Non-structured Programming

~1951 – Assembly

1960s

  Structured Programming

  Layering: 1 tier with the UI, Business Logic and Data Storage

~1958 – Algol

1970s

  Procedural / Functional Programming

~1970 – Pascal

~1972 – C

 1979 – Model-View-Controller

1980s

 Object Oriented Programming (first thoughts were in the late 1960s, though)

  Layering: 2 tier, the 1st tier with the UI, the 2nd tier with Business Logic and Data Storage

~1980 – C++

  CORBA – Common Object Request Broker Architecture (though the first stable version was only out in 1991, the first usages were during the 1980s)

~1986 – Erlang

~1987 – Perl

 1987 – PAC aka Hierarchical Model-View-Controller

 1988 – LSP (~SOLID)

1990s

  Layering: 3 tier, the 1st tier with the UI, the 2nd tier Business Logic (and the UI presentation logic in case of a browser as client), the 3rd tier with the Data Storage

~1991 – Message Bus

~1991 – Python

 1992 – Entity-Boundary-InteractorArchitecture aka EBC aka EIC

~1993 – Ruby

~1995 – Delphi, Java, Javascript, PHP

 1996 – Model-View-Presenter

 1996 – OCP, ISP, DIP (~SOLID), REP, CRP, CCP, ADP

 1997 – SDP, SAP

~1997 –Aspect Oriented Programming

~1997 – Web Services

~1997 – ESB – Enterprise Service Bus (although the book that coined the term was published in 2004, the concept was already used before)

2000s

2002 – SRP (~SOLID)

2003 – Domain-Driven Design

2005 – Model-View-ViewModel

2005 – Ports & Adapters Architecture aka Hexagonal Architecture

2006? – CQRS & ES (Command Query Responsibility Segregation & Event Sourcing)

2008 –Onion Architecture

2009 – Microservices (at Netflix)

2010s

2010 – Data-Context-Interaction Architecture 

2012 – Clean Architecture

2014 – C4 Model