Tag: software developement

MVC and its alternatives

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 about 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.

Creating maintainable applications has always been the real long-term challenge of building applications.

Not long ago, I worked for a company whose core business application was a SaaS platform, used by a few thousands of client companies. That crucial application was three years old and had code files with HTML, CSS, business logic and SQL mixed up. Of course, two years after being released, the company decided to rebuild it from scratch. Although these situations still happen, today many of us know these practices are wrong and know how to avoid them.

However, back in the 1970s, mixing responsibilities was the common practice and people were still trying to discover how to do it better. As application complexity grew, making changes to the UI would inevitably imply changes to the business logic as well, increasing the complexity of the changes, the time spent to do those changes and the likelihood of bugs (because there would be more code changed).

MCV came into play to solve those problems, by promoting “separation of concerns” between front-end and back-end.

Continue reading “MVC and its alternatives” →

Advertisement

Layered Architecture

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.

Layering is a common practice to separate and organise code units by their role/responsibilities in the system.

In an object-oriented program, UI, database, and other support code often gets written directly into the business objects. Additional business logic is embedded in the behaviour of UI widgets and database scripts. This happens because it is the easiest way to make things work, in the short run.

When the domain-related code is diffused through such a large amount of other code, it becomes extremely difficult to see and to reason about. Superficial changes to the UI can actually change business logic. To change a business rule may require meticulous tracing of UI code, database code, or other program elements. Implementing coherent, model-driven objects becomes impractical. Automated testing is awkward. With all the technologies and logic involved in each activity, a program must be kept very simple or it becomes impossible to understand.

Eric Evans 2014, Domain-Driven Design Reference

Continue reading “Layered Architecture” →

Monolithic Architecture

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 the beginning, there was the Monolith… 😀

Building a monolith has always been the default Architectural Style. I mean, in the very beginning we had one file per application, then we started having applications with several files, and only since the 1990s we started to see applications composed of other applications (although the first experimentations were during the 1980s).

Continue reading “Monolithic Architecture” →

Architectural Styles vs. Architectural Patterns vs. Design Patterns

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 the last post, I wrote about how programming languages have evolved and what it tells us: that they evolved always in the direction of providing for more modularity and encapsulation.

In the following posts, I will write about Architectural Styles and Architectural Patterns evolution, so today I will write about what is an Architectural Style and what is an Architectural Pattern.

Continue reading “Architectural Styles vs. Architectural Patterns vs. Design Patterns” →

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” →