The Architect´s Napkin

Software Architecture on the Back of a Napkin
posts - 69 , comments - 229 , trackbacks - 0

My Links

News

Archives

Post Categories

Software architecture

IODA Architecture by Example
The IODA Architecture to me is fundamental. But as many fundamental notions it might be a bit abstract. That's why I want to provide an example of how to design and implement software based on it. I keep things easy, but not trivial. So here is a scenario: Build an application that translates a roman number entered by the user into an arabic number and vice versa. This sounds easy, doesn't it. It's more than the code kata Roman Numerals requires, but not much. Requirements analysis Before I start ......

Posted On Saturday, May 2, 2015 2:19 PM | Comments (2) | Filed Under [ Software architecture ]

The IODA Architecture
The common architectural patterns are all pretty much the same. Layered architecture, MVC, Hexagonal architecture, Onion Architecture, Clean architecture… they all do two things: Define domains of responsibility Put functional dependencies in order Look at these depictions of some of the patterns: What you find are shapes (rectangles, circles) with the responsibility to produce part of the required behavior of a software. All models forsee certain responsibilities like interaction with the user, ......

Posted On Wednesday, April 29, 2015 3:15 PM | Comments (10) | Filed Under [ Thinking outside of the box Software architecture ]

Sweet Aspects
When a module has a single responsibility that means it’s focused on producing the behavior of a single aspect. That’s how I described the Single Responsibility Principle (SRP) in my previous article. Since the SRP is so important and at the same time a bit elusive, I thought, I try to illustrate this “traits and aspects thing” a bit more. Maybe you can even develop a taste for the SRP :-) Look at this heap of sweets: Let them represent logic in your code. You know, those 5,000 lines of code in a ......

Posted On Monday, April 27, 2015 8:59 PM | Comments (0) | Filed Under [ Thinking outside of the box Software architecture ]

Evolution of a Basic Software Anatomy
In the beginning there was, well, chaos. Software had no particular anatomy, i.e. agreed upon fundamental structure. It consisted of several different “modules” which where dependent on each other in arbitrary ways: (Please note the line end symbol I´m using to denote dependencies. You´ll see in a minute why I´m deviating from the traditional arrow.) Then came along the multi-layer architecture. A very successful pattern to bring order into chaos. Its benefits were twofold: Multi-layer architecture ......

Posted On Saturday, March 22, 2014 10:42 PM | Comments (3) | Filed Under [ Software architecture ]

Lightweight Software Architecture on Napkins
Doing explicit software architecture is nothing for the faint of heart, it seems. Software architecture carries the nimbus of heavy weight, of something better left to specialists – or to eschew altogether. Both views are highly counterproductive, though. Leaving architecture to specialists builds walls where there should be none; it hampers feedback and flexibility. And not explicitly architecting (or just designing) software leads to less than desirable evolvability as well as collective software ......

Posted On Sunday, March 16, 2014 7:15 PM | Comments (0) | Filed Under [ Why a napkin? Software architecture ]

Powered by: