I compiled a reference of principles, concepts, methods and so forth on architecture in agile software development.
If you are a software architect or developer, this is for you.
Comments about what you like or your opinion on the topic are very welcome.
Urs’ comment: This book claims a lot, and delivers little. There are several good tips in this book, but overall I simply don’t like it. I don’t like the “tone” it is written in.
There are only few books about Agile and Lean software architecture, therefore I cannot really give a better alternative covering the same topic.
Ultimately, that means you have to read it in case you are in any kind responsible for the architecture in an Lean/Agile set-up.
The term microservices has been humming around in the industry quite a long time now. Several articles and videos have been posted. People have been arguing about whether their services are true microservices or not on twitter and other social media streams. Lately Martin Fowler published an article about microservices which quickly led to discussions, flamewars and a lot of blog posts about this topic. Here is my personal opinion about the microservices architecture style. You have the right to disagree 🙂
The term “Microservice Architecture” has sprung up over the last few years to describe a particular way of designing software applications as suites of independently deployable services. While there is no precise definition of this architectural style, there are certain common characteristics around organization around business capability, automated deployment, intelligence in the endpoints, and decentralized control of languages and data. Martin Fowler
I provided a small reading list at the bottom of this article which might help you get your own opinion. As I see the current hype going on with microservices is that it is just a new word for something which has been around for ages in Service Oriented Architecture. My call is that a microservice is just an Autonomous Component. Let us take a step back and see how a SOA service can be decomposed.
A very nice wrap-up about onion architecture, thank you for sharing the presentation!
However, there’s a something that’s bothering me. Sometimes, you may have need to interact with some infrastructure parts from the inner layers. A good example will be logging – domain service may need to log some details or exceptions. How you would approach that?
To keep the right direction for dependencies (if you’re really committed to it) I see two possible options:
– Incorporating abstractions for required infrastructure parts into your domain. For example a generic ILog definition that will be implemented in outer layers.
– The outer layers will be “watching” the inner layers through domain specific messages/callbacks/errors/events and reacting to it accordingly.
In your experience is this a problem? How you will solve it?
Here is my answer: Continue reading
This is the presentation handout for a presentation I gave at the bbv Techday 2013. Special thanks to Jeffrey Palermo for supporting me. Chopping onions usually makes you cry. This is not the case in software architecture. In contrary! The onion architecture, introduced by Jeffrey Palermo, puts the widely known layered architecture onto its head. Get to know the onion architecture and its merits with simple and practical examples. Combined with code structuring by feature your software is easy to understand, changeable and extendable. Turn your tears of sorrow into tears of delight.
cross-post from bbv blog
When software projects grow both in age and size the developers often struggle with the structure of the code. It gets more and more difficult to find the class you have to change for a new requirement. In this post, I’ll show you how we organize our code and how we derive our structure directly from the requirements.
These are the slides along with some comments from a presentation I gave lately in the bbv .Net System boot camp – the yearly education week of my division in my company.
Once upon a time, Agile Software development came to our software development country.
Like a monster, Agile software methodologies scared the hell out of us. Suddenly, we had to find ways how to build software so that we could keep up with the high rate of change, just-in-time requirements and a sacrificial offering – a product increment – every two weeks (our Sprint length).
The way we were used to build software was not up to this task. We were used to dig a big hole of new functionality and to build something great over months. The structure of our source code and our engineering practices were no good to match the Agile monster.
So we had to come up with some new “weapons” to stand a chance:
Updated: new version here!
I have compiled two cheat sheets about clean code (the ones mentioned in my post about Code Quality!).
The first covers clean code – code that is easy readable and keeps changeable. The second is about Test Driven Development. Both cheat sheets list principles, patterns, practices and smells.
Take a look!
I’d like to read your feedback in the comments section…
(just an unreadable preview 🙂 – click on link in text above)