Software Architecture

Home/Software Architecture

Designing a DSL to Describe Software Architecture (Part 1)

Software architecture defines the different parts of a software system and how they relate to each other. Keeping a code base matching its architectural blueprint is crucial for keeping a complex piece of software maintainable over its lifetime. Sure, the architecture will evolve over time, but it is always better to have an architecture and

Laziness as a Virtue in Software Architecture

Laziness may be one of the Seven Deadly Sins, but it can be a virtue in software development. As Matt Osbun observed: I often refer to myself as a lazy developer. Occurred to me that people might not get the reference.— Matt Osbun (@MattOsbun) February 6, 2015 Robert Heinlein noted the benefits of laziness:

Microservices, SOA, and EITA: Where To Draw the Line? Why to Draw the Line?

In my part of the world, it's not uncommon for people to say that someone wouldn't recognize something if it "bit them in the [rude rump reference]". For many organizations, that seems to be the explanation for the state of their enterprise IT architecture. For while we might claim to understand terms like "design", "encapsulation",

Microservices, Monoliths, Modularity – Shearing Layers for Flexibility

Over the last fifteen months, many electrons have been expended discussing the relative merits of the application architecture styles commonly referred to as microservices and monoliths. Both styles have their advocates, and the interesting aspect is not their differences, but their agreement on one core principle - modularity. Both camps seem to agree that "good"

Microservice Mistakes – Complexity as a Service

Technical Empathy - the ability to see the system from the point of view of the caller of your code, not just the point of view of your code— Michael Feathers (@mfeathers) January 26, 2015 Michael Feathers' tweet about technical empathy packs a lot of wisdom into 140 characters. Lack of technical empathy can lead

Love Your Architecture

(Repost from: By Alexander Von Zitzewitz The single best thing you can do for the long term health, quality and maintainability of a non-trivial software system is to carefully manage and control the dependencies between its different elements and components by defining and enforcing an architectural blueprint over its lifetime. Unfortunately this is something that is rarely done