Category: Architecture

Programming Language evolution

This post is part of The Software Architecture Chronicles, a series of posts about Software Architecture. In them, I write about what I’ve learned on Software Architecture, how I think of it, and how I use that knowledge. The contents of this post might make more sense if you read the previous posts in this series.

Programming languages themselves are not an artefact of architecture, but I would feel that The Chronicles of Software Architecture would be missing something if I wouldn’t write about it.

So, let’s make a quick review of programming languages history, its evolution and check what we can learn from it. I’ve added some dates to the post just as a curiosity, they should be seen as rough estimates, the important is the evolution sequence and the problems they were trying to solve.

Continue reading “Programming Language evolution” →

Software Architecture Premises

This post is part of The Software Architecture Chronicles, a series of posts about Software Architecture. In them, I write about what I’ve learned on Software Architecture, how I think of it, and how I use that knowledge. The contents of this post might make more sense if you read the previous posts in this series.

In this post, I establish the very first concepts about Software Architecture, that will be needed in order to better understand the following posts.

Continue reading “Software Architecture Premises” →

The Software Architecture Chronicles

This post is the first of a series of posts about Software Architecture. In them, I write about what I’ve learned about Software Architecture, how I think of it, and how I use that knowledge.

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.

Continue reading “The Software Architecture Chronicles” →

Architecture 1st design step: Partitioning

There are many ways of partitioning an application. Usually, what we do is actually classify the code according to some criteria and organise the code following that criteria.

This chapter of the book explores four criteria:

  • Functionality vs. Domain;
  • Conway’s Law;
  • Geographic constraints;
  • Cultural concerns.

All in all, the idea is that we partition our codebase with long-term local autonomy in mind, according to history, standards and conventions, experience and common sense (Coplien 2010, p.91).

Continue reading “Architecture 1st design step: Partitioning” →

What is Lean and Agile about Software Architecture

Good Software Architecture embodies several Lean and Agile principles, always with the same goal of long-term productivity and lightweight feature development.

Delaying structural decisions will outcome in undisciplined structure, which in turn outcomes in waste. Therefore we must think of Software Architecture as an investment that we need to make now to get medium and long term gain.

Continue reading “What is Lean and Agile about Software Architecture” →

Microservices architecture: What the gurus say about it

About a year ago I was very interested in learning as much as possible about the subject and gathered as much information as I could about it. I watched several conference talks and I read several articles from very knowledgeable and experienced people, like Martin Fowler, Fred George, Adrian Cockcroft, or Chris Richardson, in order to learn as much as possible about microservices, and this post is the result of that.

This post talks about:

Continue reading “Microservices architecture: What the gurus say about it” →

Stakeholder engagement: The end-users

There are five major stakeholder areas :

  • End-users
  • Business
  • Customers
  • Domain experts
  • Developers

Both Agile and Lean tell us to break the traditional approach of contacting the stakeholders at a specific moment of the project development, and instead keep a permanent contact with them throughout the project development.

Continue reading “Stakeholder engagement: The end-users” →