Martin Fowler - Software Architecture - Making Architecture matter

 https://martinfowler.com/architecture/

One can appreciate the point of this presentation when one's sense of code smell is trained, functional and utilized. Those controlling the budget as well as developer leads should understand the design stamina hypothesis, so that the appropriate focus and priority is given to internal quality - otherwise pay a high price soon.

Andrew Farrell

8 months ago

I love that he was able to give an important lesson on the “How?” of software architecture at the very end: delegate decisions to those with the time to focus on them.

Very nice and straight-forward talk about the value of software architecture

For me, architecture is the distribution of complexity in a system. And also, how subsystems communicate with each other.

A battle between craftmanship and the economics and economics always win...

https://hackernoon.com/applying-clean-architecture-on-web-application-with-modular-pattern-7b11f1b89011

1. Independent of Frameworks

2. Testable

3. Independent of UI

4. Independent of Database

5. Independent of any external agency.

Architecture: deferring technological decisions

Applying the proposed set of layers as well as the dependency rule gives you a lot of options:

* You can develop many use cases before making decisions like "which database am I going to use?". You can easily use different databases for different use cases as well.

* You can even decide later on which (web) framework you're going to use. This prevents your application from becoming "a Symfony application" or "a Laravel project".

* Frameworks and libraries will be put on a safe distance from domain and application layer code. This helps with upgrading to newer (major) versions of those frameworks and libraries. It also prevents you from having to rewrite the system if you ever like to use, say, Symfony 3 instead of Zend Framework 1.

https://matthiasnoback.nl/2017/08/layers-ports-and-adapters-part-2-layers/

This, to me, is a very attractive idea: I want to keep my options open, and I want to make the right technological decisions; not at the beginning of a project, but only when I know, based on what the use cases of my application are starting to look like, which solutions will be the best ones for the situation at hand.

Having seen a lot of legacy code in my career, I also believe that applying correct layering as well as enforcing the dependency rule helps prevent you from producing legacy code. At least, it helps you prevent making framework and library calls all over the code base. After all, replacing those calls with something more up-to-date, proves to be one of the biggest challenges of working with legacy code. If you have it all in one layer, and if you always apply the dependency inversion principle, it'll be much easier to do so.

Create the Repository

Before we create a repository for the Order model, let's define an interface to specify all the methods which the repository must declare. Instead of relying directly on the repository class, our controller (and any order component we may build in the future) will depend on the interface.

This makes our code flexible because, should it become necessary to make a change in the future, the controller remains unaffected. For instance, if we decided to outsource order management to a 3rd party application, we can build a new module that conforms to OrderRepositoryInterface's signature and swap the binding declarations and our controller will work exactly as expected - without touching a single line of code in the controller.

https://www.martinfowler.com/articles/programs-in-product-mode.html