Hybrid Software Architecture
One of the core elements you always need for every software project, regarding of its type, is the architecture. In many of my recent projects, I have
tried to use the inception and elaboration phases to establish a kind of a framework, that should provide the architectural basement like layering,
generic solutions for CRUDs, crosscut-concern functionality etc. thus making the upcoming development easier. Additionally such a framework should
provide style and coding guidelines, in consequence rising up the quality of the system being developed.
My first project frameworks were big, heavy and... oversized. The reason for that was the idea of "reusability". Yes, it is actually not a bad
initiative but simply unrealistic to fulfill. With those frameworks, I have tried to cover all possible functional and non-functional requirements of
my potential, future projects. Maybe you have noticed I've written "frameworks" not "framework". The problem that I had was (I know it now) very
natural, simple and caused by the learning effect of every project I have done. Every framework I have prepared at the start of one project was "now so
prefect" as I planned at the end of the project, thus simply not reusable in the upcoming another project. Actually after each project I had some new
ideas how to establish a better framework comparing to the last one. As a result I have produced a lot of unused, generic, oversized, thus difficult to
understand and maintain code... clearly saying a lot of waste. That was a dead end.
After some one-to-one ;) brainstorming sessions I have decided to change my way of "doing architecture". "Simplicity", that was the keyword. My
frameworks were suddenly light-weighted defining only the core foundation based on the Domain Driven Design by Eric Evans. This solution was a big
improvement. My last framework took only about 2k lines of code. However, even of that I had still sometimes to write a lot of code for a functionality
that actually didn't need it e.g. maintenance of meta data of an application.
The next step of optimization was the idea of reducing waste based on lean software development principles. See my post below for the detailed
discussion about it. Shortly I have decided to provide code for the required functionality only e.g. in case of CRUDs, we have developed only "update"
functionality, leaving other functions empty. It was almost perfect :).
However the final solution for the best modern style of a software architecture, especially in case of agile projects, is what I'm calling the Hybrid Software Architecture.
Hybrid Software Architecture allows to use two or more architectural patterns within one project. I would compare this model to the architecture of a
house with a garage and a garden house. I think it is clear that not all of those object have to be built using the same architecture, due to different
requirements, lifetime, complexity and other factors. Similar differences we can observe in every software project. Core domain functionality might be
60-80% of the whole system and should be built using best, well-know architectural patterns, but the rest could be developed using simplified
architecture. In my current experimental project http://silenta.com (coming soon...) I have used simplified 2-layers architecture based on direct data
binding between UI controls and repositories. In parallel I have provided n-tier architecture with full-blown DDD for the core search functionality of
the system. As a result my hybrid software architecture allowed to save over 50% of time I would need to create same functionality using homogeneous
architecture only. Done :).
Hybrid Software Architecture is the next step in the architectural evolution we have observed over the last two decades and it is an
ideal co-player in case of an agile software development. Try to think about it when you start your next project. It pays.
---
tried to use the inception and elaboration phases to establish a kind of a framework, that should provide the architectural basement like layering,
generic solutions for CRUDs, crosscut-concern functionality etc. thus making the upcoming development easier. Additionally such a framework should
provide style and coding guidelines, in consequence rising up the quality of the system being developed.
My first project frameworks were big, heavy and... oversized. The reason for that was the idea of "reusability". Yes, it is actually not a bad
initiative but simply unrealistic to fulfill. With those frameworks, I have tried to cover all possible functional and non-functional requirements of
my potential, future projects. Maybe you have noticed I've written "frameworks" not "framework". The problem that I had was (I know it now) very
natural, simple and caused by the learning effect of every project I have done. Every framework I have prepared at the start of one project was "now so
prefect" as I planned at the end of the project, thus simply not reusable in the upcoming another project. Actually after each project I had some new
ideas how to establish a better framework comparing to the last one. As a result I have produced a lot of unused, generic, oversized, thus difficult to
understand and maintain code... clearly saying a lot of waste. That was a dead end.
After some one-to-one ;) brainstorming sessions I have decided to change my way of "doing architecture". "Simplicity", that was the keyword. My
frameworks were suddenly light-weighted defining only the core foundation based on the Domain Driven Design by Eric Evans. This solution was a big
improvement. My last framework took only about 2k lines of code. However, even of that I had still sometimes to write a lot of code for a functionality
that actually didn't need it e.g. maintenance of meta data of an application.
The next step of optimization was the idea of reducing waste based on lean software development principles. See my post below for the detailed
discussion about it. Shortly I have decided to provide code for the required functionality only e.g. in case of CRUDs, we have developed only "update"
functionality, leaving other functions empty. It was almost perfect :).
However the final solution for the best modern style of a software architecture, especially in case of agile projects, is what I'm calling the Hybrid Software Architecture.
Hybrid Software Architecture allows to use two or more architectural patterns within one project. I would compare this model to the architecture of a
house with a garage and a garden house. I think it is clear that not all of those object have to be built using the same architecture, due to different
requirements, lifetime, complexity and other factors. Similar differences we can observe in every software project. Core domain functionality might be
60-80% of the whole system and should be built using best, well-know architectural patterns, but the rest could be developed using simplified
architecture. In my current experimental project http://silenta.com (coming soon...) I have used simplified 2-layers architecture based on direct data
binding between UI controls and repositories. In parallel I have provided n-tier architecture with full-blown DDD for the core search functionality of
the system. As a result my hybrid software architecture allowed to save over 50% of time I would need to create same functionality using homogeneous
architecture only. Done :).
Hybrid Software Architecture is the next step in the architectural evolution we have observed over the last two decades and it is an
ideal co-player in case of an agile software development. Try to think about it when you start your next project. It pays.
---
Comments
Post a Comment