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

The Entity-Boundary-Interactor (EBI) Architecture has been made known by Robert C. Martin in his talks about Clean Architecture (of which I will talk in a later post).

However, this pattern was published by Ivar Jacobson back in 1992, in his book Object-Oriented Software Engineering: A use case driven approach. At the time, Jacobson actually called it Entity-Interface-Control, but the name was changed so that “Interface” would not be confused with the “Interface” language construct (which some languages don’t even have) nor with “User Interface”, and “Control” would not be confused with the MVC Controller.

Continue reading “EBI Architecture”

Advertisements

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

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”

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”