Software Architecture Guide

Yes. And Computer Science is not a science, and Software Engineering is not an engineering.

Guides to it are more like guides to writing. Strunk and White, where is your empirical data? What's your control? Where are your PDE's?

Some also have aspects of business productivity books, with well-known common-sense ideas, like In Search of Excellence (which made up case studies, and a co-author said what's the problem?)

Even Fred Brooks' Mythical Man-Month - informed by his leadership of the massive bet-the-company "360" project at IBM - lacks data. It's still great though (in, uh... my subjective opinion, I guess).

Software development doesn't need to be an art and it doesn't need to be a science either.

By science I mean using data and statistical evidence to drive development, by Art I mean using your gut and your intuition to drive development.

A computer is a deterministic system. It is 100% predictable and follows an exact set of rules. Software development is amenable to proof, logic and theory. You don't need to make decisions driven by data or your gut if the problem space can be described by a logical and axiomatic theory.

The problem is that the current "theory" is incomplete and not all parts of systems are amenable to statistical measurement. Thus a proper system architect needs to unify Theory, Science and Art to form a cohesive framework of system architecture.

Theory is priority because it says definitive things about the system, Science is secondary and operates as a data driven backup for places theory is currently incomplete, and Art is basically the catch all admission that there is no data or theory to back up the problem space and you're just going to have to rely on your intuition.

The problem with Martin Fowler is that all his stuff is 100% Art. It's just made up stuff from intuition and buzz words. Art is largely ad-hoc and does involve a lot of guess work that is often wrong. People identify with Martin Fowlers stuff because they identify with it on the "gut" level. It "feels" right. Your feelings are not a good way to do engineering, you rely only on intuition when you have no choice.

Fowler is also a big Object Oriented Architect. The thing with Object Orientation is that it has no basis in theory or science and is almost 100% art. The pattern is starting to fall out of favor because people are realizing that they tend to build over-complicated systems when following the pattern because they are largely just relying on their gut intuition to build these things using primitives that are validated by the same flawed intuition.

People have asked for evidence on this thread, so let me share my experience. A couple of years ago, I was developing an E-Commerce platformm internally for my company. I follow Martin Fowlers' articles on using DDD (Domain Driven Design) and Microservices to architect applications. What should have been a month long project took us 8 months! I'm not including the time I took to read about, understand and practice DDD and the surrounding concepts. Every DDD book is atleast 500 pages or more. And none of them are clear on the concepts, and are mostly full of fluff.

To give you more details, our stack was based on Phoenix, but it used a concept called Umbrella applications (basically Micro services pattern). Along the way, I hit so many snags and I thought I must be doing it wrong. Because, that's what these authors kept saying all the time to people who had failed to implement their preachings. So, I met a couple of people who had actually done this DDD on a much larger scale than I had and even they shared the same experience and stories of failure and struggling. Still, I shrugged them off thinking it must be something we were doing wrong instead of DDD/Fowler's teachings itself. In the meantime, we were struggling to launch features for our E-Commerce software because our microservices architecture based on DDD was just a house of cards at this point. And then, I finally called up someone I knew who had done DDD successfully and asked him how he did it. He said one of the authors of a popular DDD related website, had offered to consult for his company. And they had no choice but to employ him because they were pretty invested at this point. After a while, I started meeting a bunch of such companies who got their DDD setup done by either authors or by some vendor these authors had a stake in.

And then BINGO, it all made sense - most of these patterns/shortcuts/discoveries/secret sauces by these authors are hardly tested by them. It's just a way to sell you more consulting and training.

A couple of weeks later, we hosted a casual meetup for tech talks in our area and we got to meet more folks who had followed the same path and failed. We finally decided to do a small hackathon over a weekend and get our projects done. In the end, in about 3 days from Fri-Sun, we had got done so much more with a monolithic architecture than we had ever gotten done with DDD and microservices. Today, my platform is in production and is a proud monolithic app and still going strong.

It was perhaps the most expensive lesson I've ever learnt, but one that I will remember for a long time.

It sounds more like someone actually sat down and thought about what to do before doing it.

I read danish. I have experience with it. I did not understand what the page was trying to say.

Providing your data through APIs are often a better way than rolling your own manual delta sync through reports every Sunday uploaded to your company FTP server with 5% downtime.

Not duplicating your data throughout various systems is not architecture it's just common sense.

> The thing with Object Orientation is that it has no basis in theory or science and is almost 100% art.

Absolutely incorrect.

The data part of OO is based on set theory as formalised in the database design research and type systems.

The dynamic part of OO is based on finite state machines.

The data abstraction and information hiding part is based on the work of barbara liskov (for which she won the Turing award) - https://en.wikipedia.org/wiki/Barbara_Liskov