
Software Architecture Guide - rspivak
https://martinfowler.com/architecture/
======
vikingcaffiene
I gotta say I am surprised and a little disheartened by all the negativity
around this post and Fowler in general. Fowler's writing has been a huge
inspiration to me in my career. I'm about to gift a copy of his book
"Refactoring" to one of the junior engineers I work with for instance.

I think the idea of an architecture as a social construct is very fitting.
Software is hard when multiple people are working on it with differing
backgrounds and experience. Having a rough outline (emphasis on rough here) of
"what lives where" and "what is allowed to talk to what" is absolutely
critical IMO. It's how your team can effectively reason about a system and add
new features to it. It should also be a living thing in that it's something
that is continually refined, discussed, and changed as the needs of the
business change. Done right, its an organic process that really helps deliver
more robust software that everyone involved has a high level understanding of.

Contrast that with an Architecture (capital A) done in Enterprise which
delivers a static artifact that does not allow for any creativity and
micromanages every aspect of it. It's split off into chunks and no one without
an expert level of knowledge can easily understand it. That kind of design
will almost certainly fall over the first time there needs to be a change to
it. It's important to point out the difference because that is NOT what Fowler
is recommending in his writings.

~~~
wpietri
Totally. In a side room at Java One in 1999 or 2000 I saw Fowler talking about
Refactoring, and he happened to bring Kent Beck up on stage to talk a bit. If
I hadn't been exposed to their ideas, I surely would have left software by
now.

Over and over, my experience was building something that slowly got less
tractable over time, where eventually we'd just want to do a big rewrite. It
sucked! I had tried the big-design-up-front approach, where I thought real
hard for a long time before building. That might push out the rewrite date
some, but definitely not forever. It was dispiriting, a slow, sticky death.
That combined with crunches and burnout was slowly making me hate something I
had loved doing.

But their main point was that code bases didn't have to end in an entropic
snarl. That with decent tests and a little elbow grease, code could get better
organized every time we touched it. That instead of death by papercut, we
could make things a little better every day. Better for the users, better for
the business, better for the developers. They weren't promoting silver
architecture bullets. They were saying that we should trust and empower teams
to figure it out. That if we gave them room and tools to figure it out,
everybody would end up happier.

It made a huge difference in my life, so it's weird to see people here
aggressively putting words in Fowler's mouth, words that seem entirely at odds
with my experience of him and his work.

~~~
vikingcaffiene
Thanks for taking the time to write this. I really hope that the latest
generation of developers don’t see all the negative HN hive mind comments and
discount writings like this.

------
Ozzie_osman
Lots of hate in this thread.. People asking for proof: what sort of evidence
would convince you? I take these blog posts, apply it to my experience, and
take what I think makes sense. Sometimes, an idea will solve an obvious pain
I've had. Sometimes, an idea will show me a pain I didn't know I have.
Sometimes I disagree with the idea because it won't work for me. That's fine.
I'm still much better off thanks to this literature, and I would be worse off
if it all had to be evidence-based.

If you think you can write better based on your experience, please go for it.
I'd love to have more literature to read, analyze, and learn from. If you
can't (pressed for time, etc), and only have time to post in HN comment
threads, then at least discuss concretely which parts you disagree with so we
can learn from that too (I'm serious, not being facetious). If you can't even
do THAT, then sorry, all your valuable experience is way less useful than
someone like Martin Fowler, because I'm not learning anything from you.

Having a good understanding of how to architect code is hard. Being able to
write about that in a way that's useful for others is even harder, and is a
skill of its own.

So personally, I thank Martin & Co for all their writing.

~~~
hyperpallium
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).

~~~
streetcat1
Software engineering is engineering in the same sense the mechanical
engineering is engineering.

The only difference is that with software your materials are descriptions.
I.e. you describe something, give to the computer and the computer turn itself
into this something .

In the end, there is a physical entity in the world (the hardware), which
turned itself into a unique machine based on your description (for example an
ATM).

While in mechanical engineering, you materials are physical, which might make
it easier to explain.

~~~
Ozzie_osman
I disagree. Engineering disciplines vary in how far removed they are from the
underlying physics and how malleable they are. Building a bridge (or civil
engineering) is very connected to the underlying physics. A set of equations
give you the answers. It's also not malleable. You design it once, then build
it, putting in some margins of safety to account for any variances in
underlying material or potential usage, then it's pretty much not malleable.

Mechanical engineering is a little more removed. You have moving parts,
interconnected pieces, wear and tear, etc. Now you have to lean heavily on
preventative maintenance, ability to replace worn parts, etc.

Hardware is more removed. Software is even more removed. The laws of physics
are there, but there are so many man-made layers of abstractions on top of it
that "good architecture" is a lot less like what you'd expect in a typical
engineering discipline.

Not saying any is easier than the other, just that they are very different
disciplines.

~~~
streetcat1
There is not such thing is "partial" engineering.

Engineering is the creation and ongoing management of any real world object
(building, cars, bridge, computer) which has affect on its environment. I.e.
they are placed in the real world to achieve some sort of a function.

The role of the engineer is:

1) Find out what function a machine should provide

2) Create this function by building the artifact on time, and in cost
effective manner.

An artist on the other hand:

1) Does not care about the function. I.e. if the thing is useful or not.

2) Does not care about the time/cost etc.

The fact that software is just a description (bunch of text files), does not
mean that it does not affect the real world.

As I said, the machine in the real world is the general propose computer. The
computer understand this text files, and turn itself into the machine.

~~~
Ozzie_osman
I didn't say anything about partial engineering. Just that engineering
disciplines are different. If you need to design a column to hold up some
load, a set of equations will tell you the dimensions of that column, how much
cement, sand, etc to put in the concrete mix, how many steel rebars of what
diameter and specification. Designing that column is _very_ different than
anything I do as a software engineer.

~~~
nitrogen
But, if you need to design a data processing system with a certain throughput,
a set of equations can tell you how many servers you will need, how much
storage, constraints on latency or network bandwidth, etc. So it's not so
different after all.

------
cliffcrosland
Reading an enumeration of architecture options can be helpful, but I've
probably found more value in works like Ousterhout's "A Philosophy of Software
Design" that cover fundamental design principles. Such principles seem to be
applicable no matter the project.

I appreciate that Ousterhout tries to support these principles with some data
from his own experience (building Tcl, RamCloud where Raft consensus was
discovered, etc) and from code reviews of student projects in his design
course, but he admits that there is a lack of data about things like design.

Sample principles from Ousterhout:

* When developing an interface, favor exposing a small number of functions each with deep functionality over exposing a large number of functions each with shallow functionality. For example, favor Unix file I/O interface (open, close, read, write, unlink) over Java file I/O interface (File, FileReader, BufferedReader, FileWriter, BufferedWriter, FileNotFoundException, ... etc.)

* When choosing between keeping your code specific and keeping your code general, favor "somewhat" general. For example, instead of exposing "deleteNextCharacter(text, pos), deleteNextWord(text, pos), deleteNextSentence(text, pos)", just expose "delete(text, pos, length)" and let the caller use it how they will.

~~~
blub
Yes, "A Philosophy of Software Design" is brilliant, precisely because the
author supports their statements through the many experiments they performed
with students and

The fact that they're the author of a well-known piece of software helps,
although we should not use this as the main criteria to evaluate a text.

Offering at least evidence based on experimentation is essential if we want to
move past personality cults and having entire teams work based on what someone
wrote on a blog somewhere.

~~~
sriku
I'm wondering whether another factor that might be at play is that as
consultants they may not be at liberty to discuss that kind of detail. Barring
that, it would be interesting to have Fowler sit in Ousterhout's class, take
on an advanced problem and see what they come up with.

------
EdwardDiego
> All I see is yet another reasonably sounding yet unsupported piece of
> folklore.

Another artefact of the fact that software developers are still craftspeople -
as in "someone skilled at making things by hand".

Software development output is something that no-one has yet successfully
quantified. There's no easy metric to assess a non-productive software
developer from a productive one. We can all tell the difference, but good luck
measuring it. In my country, which (thankfully) lacks America's "at-will"
employment contracts, it does mean that it's quite hard to fire an
underperforming dev, because how the hell do you prove they're
underperforming? What metric do you use?

Bug rate is a bad one, because very smart people working in a new problem
domain may register an significant uptick in bugs - doesn't mean that they're
incompetent, it's just the result of doing new stuff in an unfamiliar domain
in a highly complex environment.

Lines of code? The less said about that metric and how gameable it is, the
better.

Us still being craftspeople is also why we can command such high wages
relative to the rest of the economy - what we do is not yet automated, so we
can still draw a premium.

~~~
noobiemcfoob
> it does mean that it's quite hard to fire an underperforming dev, because
> how the hell do you prove they're underperforming? What metric do you use?

I think your criticism of 'at-will' employment is unfounded in this scenario.
Having lower guardrails on employment means it's not as pressing to figure out
performance metrics. If the company narrative is that an employee is helpful
to the mission, then there isn't much cause to fret for a more perfect metric.
And at-will means you can test more employees before committing to a few for
longer than a couple years.

~~~
EdwardDiego
I didn't express any direct or detailed criticism of at-will in my comment,
just my gladness that we don't have it.

Why, despite the difficulties it causes me when dealing with poor performing
devs, am I happy we don't have at-will?

Because at-will dramatically distorts the employer - employee social contract
in favour of the employer. And employers already have a disparately large
amount of power over their employees as it is. So there you go, that's my
criticism of at-will employment. It puts the well being of the employer ahead
of the well being of the employee.

You can have a trial period without "at-will".

~~~
noobiemcfoob
Gladness you don't have it _is_ criticism you're trying to hide behind
semantics.

You and I seem to have different ideas of an employment social contract (or
non-existence of one). Unless you're interested to dig into that difference, I
don't think we have anywhere else to go with this thread.

~~~
CraigJPerry
Gladness: "I'm glad i don't have a million dollars to manage in my bank
account, just getting the best from my small savings is stressing me out!"

Thankfully: "My bank account (thankfully) lacks a Bill Gates' sized stash of
greenbacks, it does mean that it's impossible to buy a mansion though"

I'm not criticising the concept of a million dollars in either of these
statements. Thankfully, as used in the original context means something quite
different to the meaning you've derived.

I might still actually have a bone fide criticism of a million dollars, but
that's neither here nor there in the context of either statement.

I think wrapping it up's a fair shout though so no hard feelings and all the
best.

------
jeswin
I looked at this thread a while back and closed the window, hoping that those
early comments don't influence the younger practitioners who are on HN.

As someone nearing 40 (mainly doing consulting work around boring business
apps for a long time), my view is that Martin Folwer's biggest contribution is
indeed the documentation, and defining the vocabulary to enable discussion
around frequently encountered (but perhaps mundane) problems in Enterprise
Application development. He isn't trying to break new ground, but I'm glad his
writings exist. To pick a very random example, here's CQRS defined in an
approachable manner[1]. It's a great link to send to a team of 50, out of
which quite a few will be fresh out of college. And I am pretty sure Martin
Folwer has seen plenty of real world code while he was working at
Thoughtworks. The ideas in his writings aren't conceived in some vaccuum.

Some of his early writing isn't perhaps as relevant today. For instance, he
talks about the flaws of Anemic Domain Model here [2]. Back in the day, many
of us tried to enrich the domain model with particular emphasis on
reusability. But those things are less relevant in today's heterogeous
environments where logic lives across in multiple services (many outside your
team's control). So just reading through his site will surface a lot of
outdated ideas; but that's helped a lot of companies along the way when we
didn't have to aim for web-scale tps. Actually, it might still work for 99% of
apps even today.

HN tilts towards the experiences of Startups and young founders, but one good
lesson to learn early is that we should be more open minded.

1:
[https://martinfowler.com/bliki/CQRS.html](https://martinfowler.com/bliki/CQRS.html)
2:
[https://martinfowler.com/bliki/AnemicDomainModel.html](https://martinfowler.com/bliki/AnemicDomainModel.html)

~~~
extra_rice
I don't understand how anemic domain models are irrelevant now especially in a
time where a lot of software practitioners seem to observe domain driven
design. In the age of microservices, it is very important to determine clear
context boundaries. "Logic lives across multiple services" sounds more like a
design smell to me. In this case, changing even very simple business
requirements could mean changes in multiple parts of the system, which could
mean multiple redeployments of many different services. Also implies more
complex integration (even e2e) testing.

~~~
jbmsf
I'm definitely guilty of using and promoting anemic models. I find that teams
have a hard time deciding whether logic is service or domain or whatever and
gravitate towards putting everything in one place _if_ domain objects are
allowed to be at all smart. On the other hand, people do well with the rule
that logic belongs in procedural layers with clear names and some sort of
maximum size/complexity.

I also find that these discussions matter less in microservices because the
size of each service is so small that you usually don't need more than two
layers: one for business logic and one for persistence.

I very much agree that microservices create their own challenges at service
interfaces, but since these boundaries are usually expressed as http
operations instead of object oriented function calls, I look for different
solutions, especially various forms of system-wide introspection and testing.

~~~
Spearchucker
First, anemic models work well in service contexts. You can't send a business
rule from a web page to a web service as part of a data entity. And so such
models have a valid place in the world.

Micro services are still services. As such we always validate data crossing a
trust boundary - whether monolith or micro service. The rules to do that
validation cannot travel with the data.

So guilt because anemic strikes me as... odd. Modern connected apps aren't
written as single-tier Smalltalk apps.

~~~
lonelappde
You wouldn't send a business rule from a web page, you'd put it in the domain
model on the server.

The web page has a UI model, not a domain model.

~~~
Spearchucker
That's the point. And yet Fowler objects because it violates encapsulation and
information hiding, because it requires a service layer and makes a model less
expressive.

~~~
extra_rice
You can easily serialise a well fleshed out (i.e. non-anemic) object. Does the
view layer in this particular example need to know the encapsulated business
rule? In my experience, not usually. Otherwise, there's most likely a problem
with responsibilities. And when that data comes back from the UI, it's also
relatively easy to reconstitute it back to well fleshed out objects.

~~~
Spearchucker
This I know. The point isn't how one might do it, or whether it can be done¹.
The point is that Fowler has issues with anemic objects, even though there are
patterns in distrubuted computing best solved by anemic objects.

¹ Note that reconstitution does not do away with anemic objects -
reconstitution does not implement logic in a purely object-oriented way, i.e.
the logic does not travel, but the data does.

------
Merrill
The Enterprise Architect's job is rather more like that of an Urban Renewal
Planner than an architect. There are many pre-existing structures, many
interested parties with varying degrees of control, and many economic and
technical constraints to be satisfied within a larger political system.

------
neya
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.

~~~
MiyamotoAkira
2015:
[https://www.martinfowler.com/bliki/MonolithFirst.html](https://www.martinfowler.com/bliki/MonolithFirst.html)

~~~
neya
I remember this article very well. When it was published, it was too late as
we were already following his articles on DDD before that. This is what I
meant when I said the authors said we were doing it wrong. This was published
after realizing a lot of people who took these authors' advice and went down
the DDD path weren't happy and shot themselves in the foot.

~~~
balfirevic
There is some ongoing confusion here. Using domain-driven design has no
bearing on microservices vs. monolithic architecture.

------
gregdoesit
I have been building large scale/distributed systems myself and reviewing
designs of systems like these being built around me, for years now. I have
never come across any of the type of ivory tower architecture that this post
and other sofware architects write about. We're talking about real-world
systems that are high-load and somewhat novel, with battle-scarred engineers
building them.

I find it ironic that that many of the people who write about architecture are
consultants or writers. Consultants usually come into a project, make some
decisions and write some code in a few months. Then they leave, without having
to maintain the application. Of course they bring in fancy-named architecture
patterns as one-size-fits-all solutions, leaving before the cracks on the
approach show. Ever notice how little writing there is about iterative
software design?

For writers, it seems they build a simple proof-of-concept solution, that is
never deployed in production, documenting this process and showing it off as
an example.

Yet, when it comes to writing about software architecture, this is 90% of the
materials. Engineers who build this day in, day out, design systems from
inception, iterate on them, code and deploy, then maintain and operate them
for years - they barely share what approach they took. And it's none of this
fancy-talk in articles like this one. It's not UML or other formal methods.
It's simple documents, simple diagrams, lots of discussion about tradeoffs and
tons of back-and-forth comments over Google Docs/O365 and in real life.

I'm at the point where I'm serioulsly debating writing something more
substantial on how _actual_ software design works at tech companies, when
you're not a consultant or a writer, but an engineer who does this full-time,
end-to-end, living with all the consequences of decisions and fixing mistakes
after.

On the importance of prototyping, extensible MVPs, whiteboarding, documenting
an initial design and getting feedback, iterating on it, architecture jams,
design war rooms - and when starting again when the world/business changes
substantially, keeping things running and migrating things over to the new
system.

~~~
tootie
I've worked in both a big IT orgs and consulting and the Ivory Tower
Architecture people are 10X more prevalent in IT orgs. They're the ones who
establish architecture review boards and request extensive documentation and
rounds of approval before allowing a project to proceed. On the consulting
side, we typically define an approach which might as simple as saying "We're
going to write microservices, mostly in Python and our main data store will be
Redis until we pick something better" and then start iterating.

~~~
wolco
When consulting I love those guys. So many billable hours and project delays
with pay.

------
alanfranz
Martin always has good points. What I miss from him is proofs. The weeks vs
months part crossover for internal quality... How is it measured? Is it just a
thought, or a wish?

~~~
moksly
In the public sector of Denmark we’ve been on a decade long journey toward
better Enterprise Architecture. We have national guidelines for how we want
public system/services to be build and how they should be able to transfer
data through APIs. We don’t get completely technical, telling you what tools
you need to use to build your software, only how your software needs to fit
into the environment that is public sector digitalisation.

The reason we do this is because we’ve seen what happens when we don’t.

The municipality where I work operate a pretty common amount of IT systems. We
don’t know exactly how many because there isn’t a centralised unit to handle
them all, but our guess is 300 different IT systems. There is a lot of common
things these systems need, like authentication. That used to be terrible.
Before web-services and federated IDPs it was quite literally maintaining our
organisational hierarchy in 300 different IT systems manually. And that’s just
our place, in Denmark we have 98 municipalities that all have 300 IT systems
run by different suppliers. With a common architecture we defined how
organisational data needs to be interpreted by these systems, we also build a
single co-owner database where each municipality could make these data
available in the same defined format, through the same APIs.

It’s already saving us millions, just from this tiny piece of the much bigger
picture. It’s not been without backlash either, because as it turns out,
private tech companies don’t actually want to build the smartest systems. They
want to sell us silo systems, because then they can sell us access to our data
300 x, where 1x could be organisation data and another x could be statistics.

Anyway, I think we have evidence that architectural choices matter a great
deal. At least when you look at it from an enterprise sized point of view.

With that said, I’m not sure I buy detailed application architecture, where
you design everything in your favourite markup-language, either. We certainly
have no evidence to support that this sort of architecture isn’t just a waste
of time. But for the big picture, in enterprise sized organisations, you can’t
live without IT-architecture if you want to be efficient.

If you want to read more about it, you can at:
[http://info.rammearkitektur.dk/index.php/Forside](http://info.rammearkitektur.dk/index.php/Forside)
but it’s in Danish.

~~~
peheje
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.

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

I wish you were right about that, I really do. Unfortunately only 7 of our 300
IT systems do this today. As rammearkitektur compliance is now a required part
of public procurements that number is going to go up, but only because we’re
forcing this architecture upon the private tech houses.

If we didn’t we would never see 95% the APIs we so desperately need, and the
last 5% would cost us half a million each. That’s how it’s been for 30 years,
and it’s only changing because of enterprise architecture.

------
Spearchucker
Oh man. Another diatribe from Martin Fowler™.

Takes me back to the 90's when I was in awe of teh architectures and
architects, understanding of which was always just beyond my grasp.

99% of software I've encountered has some kind of interface, a domain it
operates in, and data it operates on. Call these three things layers. It also
has some cross-cutting things that are universally available in the software -
broadly, security, comms and exception management.

You deploy these things on desktops, phones, and devices. Other parts of the
things live on servers or on clusters, mabe. Call these places (hardware)
tiers.

There. Architecture done. From micro services to huge banking monoliths. Start
there. Everything else is the usual let's think about what we're doing before
we do it.

But I guess keeping it simple and dealing with exceptions as they arise isn't
as glamorous as using fancy new names, working for a hipster consultancy or
generally saying X or Y is teh new futures.

If you harbour doubt great, questions are good. I suggest obtaining a copy of
Wicked Problems, Rightous Solutions (ISBN-10: 013590126X). It will show you
that we had EXACTLY the same problems of today, back in 1990. We just call
them new things.

~~~
stephen
Fancy new names is basically the antithesis of Fowler's approach (it's driving
shared language/canonical definitions).

And personally in the mid-2000s I found Fowler's material to, contrary to your
assertions/experience, actually be a source of simplicity (by at least
explaining pros/cons/alternatives in a comprehensive/vendor/platform agnostic
manner) vs the other "just run this huge EJB server, np!" approaches there
were mainstream at the time (and personally who I think would be a better
target of your ire than Fowler and ThoughtWorks).

~~~
camgunz
I have what I feel like are cultural disagreements with Fowler (e.g.
"Enterprise Architecture" is oxymoronic to me) so adjust for my bias
accordingly. But perhaps his most famous book is "Refactoring", where he gives
(fancy, new) names to things he found in the wild. It's basically what he does
and arguably his most influential contribution to the industry.

------
jeffdavis
Architecture is your chance to decide which problems will be easy and which
problems will be hard.

In a microservice architecture, failure handling is easy. State management is
hard.

In a centralized database architecture, failure handling is hard. State
management is easy.

~~~
ris
> In a microservice architecture, failure handling is easy

I'm not sure I would agree with this - it's still incredibly hard to be able
to make the rest of your architecture do something useful when a significant
part of it goes away. Multiply the possibility of one of your important
services going down by the number of important services you have...

------
Kortaggio
The author's statement that "My view is that applications are a social
construction" I think hints at a deeper truth, that while _code_ is run by
machines, managing a _codebase_ is more like raising a plant in a garden and
not like changing the oil in a machine. Reminds me of "A Codebase is An
Organism"[1].

[1] [https://meltingasphalt.com/a-codebase-is-an-
organism/](https://meltingasphalt.com/a-codebase-is-an-organism/)

~~~
dredmorbius
See also: Conway's Law.

[http://melconway.com/Home/Conways_Law.html](http://melconway.com/Home/Conways_Law.html)

------
blub
Whenever I see yet another article by Martin Fowler, Kent Beck, Robert Martin
& co I ask myself - where is the evidence for what they are preaching? What
are the graphs based on? What is the evidence behind the proposed rules?

These authors are clearly accomplished blog and book writers, but anyone whose
_software-related_ accomplishments are not open source or at least well known
should have their statements scrutinized more closely.

I don't see any studies cited, case studies presented or concrete examples.
All I see is yet another reasonably sounding yet unsupported piece of
folklore.

~~~
chrisseaton
For some of these speakers, I’ve literally never seen any evidence that
they’ve written a single line of code. Why should we listen to Fowler? What
large successful projects has he created using his ideas are there that I can
look at? Where’s the data behind his slides? It’s all just talk talk talk.

I’d listen to someone like Chris Lattner talk about how to design and write
software because I can see whatever approach he uses must work well. I should
listen to these full-time speakers because... I don’t really know and perhaps
we should start challenging their talks by asking for the data behind them.

~~~
scarface74
Chris Lattner knows how to write system software and compilers which are
completely separate beasts from the typical bespoke enterprise or software as
a service apps that most developers write every day.

~~~
vfc1
Exactly, many times these famous authors advocate for practices that make
sense for building compilers and frameworks or libraries, but that make little
sense for building applications.

Building applications is very different, because an application is the very
end of the software tree dependency. Some practices make sense for both types
of software, but many others don't and some of these authors don't seem to be
able to make the difference.

~~~
scarface74
And sometimes it makes sense to take shortcuts that don’t make sense from a
long term maintenance standpoint just to survive long enough to get product
market fit. Get funding and survive.

Twitter is a perfect example of this. Everyone agrees that Twitter made some
bad architectural decisions that caused the frequent appearance of the “fail
whale”. But eventually, they got enough funding via combination of the VC
funding and later the public market to rearchitect their system.

------
dvlsg
His biggest contribution may be the documentation and defining the vocabulary,
but when he defines a pattern with a word that has an obvious negative
connotation ("anemic"), it feels manipulative.

A while ago I was told by members of a separate team that I was writing the
core of my javascript application incorrectly. I was following "functional
core, imperative shell"[1] and intentionally separating my data from my
functions[2]. Specifically, the code was considered to be wrong because it was
"anemic", and I was sent a link straight to that 16 year old page about anemic
domain models[3]. The suggestion to fix was to add a bunch of mutable state.

Don't get me wrong - I still almost always appreciate Martin Fowler's writing,
as it's often quite good, including the original post. But I also understand
some of the skepticism here.

\---

1:
[https://www.destroyallsoftware.com/screencasts/catalog/funct...](https://www.destroyallsoftware.com/screencasts/catalog/functional-
core-imperative-shell)

2:
[https://softwareengineering.stackexchange.com/q/203077](https://softwareengineering.stackexchange.com/q/203077)

3:
[https://martinfowler.com/bliki/AnemicDomainModel.html](https://martinfowler.com/bliki/AnemicDomainModel.html)

~~~
charlieflowers
I think that's a case of misguided developers with tunnel vision misusing
Fowler's material.

I have never met Fowler and I'm completely speculating here, but I would bet
money he is both well-versed in, and a big fan of, the "functional core,
imperative shell" concept when it is a good fit.

Devs often get overly dogmatic, and when they do, they often reach for Fowler
quotes to back themselves up. But don't blame Fowler for that.

------
karmakaze
Let's talk about any good parts.

The architecture of systems varies enough that there isn't a good concrete
definition. An aspect that's important for one system isn't for another so
it's hard to say which aspects are part of an architecture. Unless you're
always architecting the same types of systems, this will carry some weight.

The other idea that architecture is present but not visible is a great one.
It's the important bits that are underlying or overarching or otherwise
permeates the system without necessarily being separately visible. I've had so
many difficult chats talking past one another about different levels of
concern. When one side only sees what's named or in the diffs, it's hard to
convey why something else is more important when there's a lack of 'shared
understanding'.

I did have this experience when I was making a relay service which handled a
headless browser and audio streams. Each of these ended up using a state
machine so I separated the state machine mechanics and implemented each using
it. The result ended up having many state machine visible parts than the
interesting (for the use-case) non-state-machine parts. I undid all that and
made each back to primarily do its job as a state-machine but it was far less
visible. This isn't the best of examples but it's one where I learned that
sometimes you want things to be less invisible even when it's important.

------
mrkeen
Martin Fowler: "Architecture is hard to define, but I'll try. Good
architecture allows the system to evolve. Bad architecture attracts cruft and
makes change hard."

HN: "Fuck this ivory tower bullshit! Where's the evidence?!?!"

~~~
mjburgess
My objection is the "ivory-tower bullshit" is wrong.

He goes to pains to fail to define architecture and rejects a reasonable
definition for a confused genetic fallacy about social construction.

"Architecture" isn't _understanding_. Understanding is _of_ Architecture. If
architecture were merely "the common understanding of what's important" there
could be no disagreement or understanding of the software. Disagreement would
be hopelessly social: you could never say "this is too complex", but only,
"your understanding is wrong".

> "My view is that applications are a social construction"

Deeply confuses many issues. Applications are made by people, as are tables,
but neither are "social constructs" \-- which mean they are irreducibly
subjective group phenomenon.

Software runs on machines. The running machine isn't a subjective group
phenomenon. "1 + 2" is code, mathematics isn't a "social construct".

"Architecture" refers to the structural elements of a domain (ie., how the
domain objects are related to each other, and how these relations are related
to each other, etc.).

It is a relative term, but not a subjective one. eg., The "architecture" of a
animal is how its parts fit together. The "architecture" of a leg is _its_
pieces fit together. And so on.

~~~
reilly3000
Mathematics is totally a social construct. The UR patterns of our reality are
immutable and await discovery. The ways in which humans explain their
mathematical observations to each other is via a set of symbols that are
socially agreed upon.

My problem with mathematical syntax is that it is so esoteric and arbitrary
that many people struggle to use math to communicate with each other. Delving
deeper into mathematics is an exercise in learning new symbols and their
contexts. The understanding, acceptance, and advancement of mathematical
concepts happens through social consensus.

For example, what does K mean? In an equation, strictly speaking it is a
variable. But sometimes its a reserved constant. Others, its a unit. Is math
'universal' if the language of math is largely Eurocentric? In fact, several
fundamental math ideas emerged from China far before they were expressed in
Western culture. Their syntax differed from Western syntax to express largely,
but not entirely, the same concepts.

Brett Victor[1] describes how the development of mathematical notation
unleashed a clearer level of thinking, and a flowering of mathematical ideas,
proofs, and science to follow. This requires agreement... consensus.

Take a look at Wikipedia's History of Mathematical notation and see what
smells of culture you can find. [2]

Mathematics is the practice of translating observations about real-world
things or abstract ideas from one person to another or many. A smart animal or
intrepid alien sentience would not be guaranteed to understand what 3, 3%, or
3º means to us, but they could certainly understand 3 bananas vs 2, or a
portion of a whole, or rotation.

Code is a social construct that is well-documented. Developers give trust to
language authors and their compilers to generate correct bytecode. They in
turn trust systems engineers to interpret their instructions correctly, and so
on. Of course there are arguments and different perspectives on what the best
way there is to express everything. These things get hashed out on this very
social platform, and many others.

Architecture is about imposing one's will on the act of creating long-lived
artifacts. It isn't system engineering. Its about arguing that things ought to
be built out of arches, because they are durable, and look interesting, and
especially because they have a rich symbolism associated with passage into new
time and space. The will of an architect is usually something like enduring
harmony with its inhabitants and surroundings. Software architecture I feel
attempts to create durable systems for people to inhabit with their knowledge,
and that is as social as it gets.

Sure, you may think of a software architecture as a formalized design on how
to stitch together bits of data across network boundaries, maybe using
packaged services from Cloud vendors. It is, but good architecture accounts
for who is building it and who will own it, use it, and maintain it. It makes
sure information isn't lost and people's simultaneous actions don't result in
collisions. It attempts to resist loss, against a wide variety of classes of
threats.

Look, I've been intrigued by event-sourcing, and also have heard of lots of
gnarly consequences of trying to adopt it. Like any other pattern, its mileage
may vary depending on the problem domain. An "ivory-tower bullshit" pattern
may be widely a considered a "wrong" practice for the domains of today, but
that doesn't mean you can prove that its fundamentally invalid in all cases.

If software architects made blueprints, I would think of the work of making
said blueprint is "architecture". the work of software architecture is social,
considering the needs of users, developers, and its financiers. What I read in
your comment is referring to the blueprint as "architecture", or an
architecture. Whatever the artifact of software architecture work is, the work
itself is equal parts social and technical, and always in the context of the
raw materials available at the time.

[1] Brett Victor, The Humane Representation of Thought
[https://vimeo.com/115154289](https://vimeo.com/115154289) [2]
[https://en.wikipedia.org/wiki/History_of_mathematical_notati...](https://en.wikipedia.org/wiki/History_of_mathematical_notation)

~~~
mjburgess
You have to separate social-subjective elements from individually-subjective
elements from objective elements.

The objective elements are, simply put, "what is true _of_ the object". And
the subjective elements are "what is true _of_ the subject.

Where "object" is the _target_ of understanding, and "subject" is the
"understander" \-- ie., not the human (as holding organs) but the human (as
holding experiences).

When I say, "the code has 100 lines" that is _true_ in virtue of the object.
It is _meaningful_ in virtue of various conventions about what a "line" is and
what "code" is.

Let's not confuse _what is being said_ for _how it is said_. The latter is
subject-relative, the former is object-relative (ie., objective).

Mathematics is _about_ order. The target of mathematical description is
objective (it is instanced by objects, not by experiences). However
_mathematics_ as a language is conventional (ie., social-subjective).

 _What is being said_ (eg., that there are infinitely many primes) can be said
many ways. Each of those ways is only _meaningful_ given a social background.

Likewise, "Architecture" is a term grouping together some -- but not all --
facts _about_ software. (eg., inheritance dependencies, but not comment symbol
choice). _What is being said_ requires _conventions in which to say it_.

OP article seems to confuse these issues mightily and I think would impair
someone looking to understand "architecture" without prior experience. It _is
not_ merely "what's important". Many things are important.

------
goatinaboat
The key to understanding Fowler and similar, and Thoughtworks, that the
methodology _is_ their product. They sell consulting and training and seminars
and conferences and books.

If any useful, working software is produced that is at best by sheer
coincidence and more likely _despite_ their involvement.

------
tsarquitech
We see that Martin Fowler is influenced by Ralph Johnson in deriving for
himself a definition of architecture. In particular,

 _there was no objective way to define what was fundamental, or high level_

And goes on to lean heavily on the idea that ‘application architecture' is a
social construct. But I am then left with a thought that if application
architecture is a social construct, that means there should be identifiable
social characteristics that make-up the application architecture,
characteristics that can be further quantified to an acceptable degree, such
that they can be defined as fundamental.

Taking a step back from Martin’s influence & conclusion, and ask ourselves,
“couldn’t software architecture, or architecture in general, be defined by a
set of heuristics that lead to objectively defining what is fundamental to a
particular context?“

Suppose we create three rules that need to be defined before reaching our
conclusion:

\- context: what scale does the architecture in question reference?

\- collection of computing elements: what are the computing elements (this can
range from machines to software)

\- connectedness: how are the computing elements connected?

For example, in order to determine the architecture of my web scraping local
machine setup I would go through the rules:

\- context: a single script file with code written to accomplish the task

\- collection: functions that are used to perform the task of scraping the
webpage

\- connectedness: functions pass data to other functions to perform specific
tasks of scraping

In this example we have a guide to achieve objectively what is fundamental to
our architecture.

------
z3t4
I start with a raw stone, and carve away the crud ... then I bring the duct-
tape ...

------
eddieh
Would it help if instead of software "architecture," we called in software
"organization?" It seems like nobody would demand "proof" if Martin was
arguing that it is faster and easier to find a book in a library than it is to
find a book at the dump.

------
JBSay
I started reading his sample chapter on refactoring and I'm constantly put off
by some really rookie mistakes and bad code practices like naming a function
after nouns instead of action verbs (e.g. "amountFor" instead of
"computeAmount").

------
contingencies
_Head closer to the rocks of chaos rather than suffocating control. But being
on that side of the channel still means we have to avoid the rocks, and a way
to maximize local decision making in a way that minimizes the real costs
involved._ \- Martin Fowler

... added to
[https://github.com/globalcitizen/taoup](https://github.com/globalcitizen/taoup)

------
kevindeasis
The only thing missing is Martin Fowler having his own vlog

------
akayoshi1
Lovers gonna love, haters gonna hate.

------
chewyshine
Unusually useless post. An aggregator that says little. Too bad.

~~~
omk
I would really like to read through a solid post that details Enterprise
Software Architecture. As the author mentions, it certainly is hazy and I
wonder if you can bring in 2 architects form different firms to talk the same
language.

Wonder if HN has a recommendation.

~~~
perlgeek
Not an article, but a book:

"Enterprise Integration Patterns: Designing, Building, and Deploying Messaging
Solution" by Hohpe and Woolf

(You don't need to read all the patterns in detail; reading the overview will
be enough to get you a pretty good idea. You only need to read the details
when you seriously consider implementing a pattern).

