Packaging & namespacing

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 architecture of a system is the high-level view of that system, the big picture, the system design in broad strokes. The architectural decisions are the structural decisions in the system, the ones that affect the whole code base, the ones that define where everything else will be built on top of.

Amongst other things, architecture is responsible for deciding the systems:

  • Components
  • Relationships between components
  • Principles guiding the design and evolution of components and relationships

In other words, these are the design decisions that are more difficult to change as the system evolves, it’s the foundations that give support to feature development.

Continue reading

Advertisements

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

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

Lean and Agile in Software Development

As this post is quite long, you can get it in PDF here.

Some time ago, at the company where I am currently working, I suggested that we could create some posters about Lean and Agile so that people would keep it in the back of their heads on their day to day work. I also made myself available to explain, to the IT department, what Lean and Agile are all about, but because of lack of time, that explanation ended up never happening.

Lately, I’ve found that there are some people around me that have the desire and need to know a bit more about Lean and Agile, about what they stand for, how their practices should impact our day to day work, and what’s there to gain from it. So I decided to write this post in an attempt to cover that.

I’ve talked about Lean and Agile before, in a post titled What is Lean and Agile about Software Architecture but it had a very restricted spectrum. In this post, however, I want to take it a bit further.

Continue reading

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