
Ask HN: CS papers for software architecture and design? - avrmav
Can you please point me to some papers that you consider very influential for your work or that you believe they played significant role on how we structure our software nowdays?
======
Maro
I used to be very interested in Software Architecture, in fact I've read many
of the papers cited here.

When I did a startup many years ago, I committed the mistake of paying too
much attention to the architecture of the software [1] I was writing, and not
enough attention to the product/customer side of it.

The last couple of years I've been de-emphasizing software architecture as an
interest, and have been paying much more attention to how product teams build
successful products, what the patterns are, etc. I was lucky enough to work at
Facebook for a while and got to see (and learn) a very successful working
model of product development.

So, while I'm not saying that software architecture is not important (it is),
also pay attention to the product/customer side: what choices (software,
organizational, hiring, business) allow you to move fast and iterate, to
release early and often, to run A/B tests, etc.

I think good software engineers are just as much product guys (and data guys)
as they are software guys.

-

[1]
[https://github.com/scalien/scaliendb](https://github.com/scalien/scaliendb)

~~~
Clubber
Agreed, good architecture doesn't come into play until you need to add a lot
of complex features or scale significantly. Initially architecture doesn't
really mean squat. I would concentrate on making the codebase flexible, but
that's about it. I've regretted making some of my software with a cool but
complex architecture when I should have been focused on what the product does.

~~~
humanrebar
> I would concentrate on making the codebase flexible, but that's about it

Arguably that's the property of good architecture. Standardizing your entire
codebase also works, but only as long as those initial standards stay smart
(1), and even then, that relies on discipline, tools, and incentives that are
typically not all in place.

(1) A standard might be "all webservers will be written in Java 6". The
benefits of choosing that standard tend to be front-loaded with a gradual
decline into net-negative with no affordable path to a better standard.

~~~
qznc
To design your software perfectly requires to know the future. You want the
things that will change flexible and the rest simple. In practice, you will
not hit the sweet spot and either over-engineer too much or hardcode too much
(or both in different parts).

~~~
gregmac
I tend to place the most emphasis on loose coupling, and being very strict
about interfaces between components -- both in terms of documentation and
addition/changes. Ideally documentation includes unit or integration tests.
This applies to separate high level services as well as it does to internal
code structure (classes/modules/etc).

Well documented and tested interfaces of a component make that component easy
to replace or rewrite if needed.

Nearly anytime I have worked on or been involved with a project where I or
someone else tried to design specifically for a vague future requirement that
wasn't entirely clear or guaranteed, it didn't work out: either the
requirement never happened, or was so materially different that what we wrote
was wrong. As a result, the code we wrote went unused or worse, just got in
the way and ended up as unnecessary technical debt.

------
davedx
For me, the most influential was "Out of the Tar Pit".

From the abstract: "Complexity is the single major difficulty in the
successful development of large-scale software systems. Following Brooks we
distinguish accidental from essential difficulty, but disagree with his
premise that most complexity remaining in contemporary systems is essential."

[1] [https://github.com/papers-we-love/papers-we-
love/blob/master...](https://github.com/papers-we-love/papers-we-
love/blob/master/design/out-of-the-tar-pit.pdf)

~~~
fermigier
I agree that's a wonderful paper to read, but has it had significant influence
in the mainstream?

~~~
chubot
I read this more than 5 years ago, I think from a recommendation on HN. But I
must have gotten something different out of it than most people.

It is advocating a particular architecture. But that architecture is
essentially LAMP, as far as I can tell. It's what we ALREADY do!!!

From the paper:

 _FRP is currently a purely hypothetical approach to system architecture that
has not in any way been proven in practice. It is however based firmly on
principles from other areas (the relational model, functional and logic
programming) which have been widely proven._

 _In FRP all essential state takes the form of relations, and the essential
logic is expressed using relational algebra extended with (pure) user- defined
[18] functions._

 _[18] By user-defined we mean specific to this particular FRP system (as
opposed to pre- provided by an underlying infrastructure)_

\-----

\- _All essential state takes the form of relations_ This is a database. (SQL
deviates from the relational model, but I don't view that as important here.
An SQL database stores everything as relations.)

\- _Logic is expressed using pure user-defined functions_ This is PHP / CGI /
FastCGI. PHP is imperative, but the entire program is a pure function, because
the request state is cleared between every request.

What am I missing? I'm being totally serious -- this is what I got out of it
when I read it 5 years ago.

You can quibble with the details of PHP or Rails not being pure functions, but
I believe what's important is the architecture, not how the source code looks.
The _essential state_ is in the database, in the form of relation. Accidental
state is thrown away.

TL;DR -- PHP/MySQL is functional and relational.

~~~
DenisM
FRP is a constrained environment, which makes it easier to reason about. PHP
is comparatively unconstrained, so when reading code you can’t make as many
shortcut assumptions. Of course you could write in PHP in accordance to the
rules, but subsequent maintainers, including the future you, cannot trust this
self-imposed discipline. In other words, you wouldn’t argue that assembler is
just fine because through vigor and discipline you can build PHP-like
application. Similarly, PHP is not well-suited to stand in for FRP.

~~~
chubot
I probably shouldn't have said PHP, since people have reactions to that
language that may confuse the issue.

I should have said stateless Python front ends. Not even CGI/FastCGI, but just
plain HTTP front ends. Many large websites use this architecture (YouTube,
Instagram, etc.)

An example of something that doesn't follow the architecture is a stateful
node.js or Go server.

I would say that the typical web architecture is similar to what they are
talking about, with the benefit of existence :)

But you're right in the sense that they are trying to be more strict, starting
on page 50:

\- benefits for state -- avoid useless accidental state. This is the same
philosophy behind SQL.

\- benefits for control -- They are being more strict here, but I think it is
missing a lot, because sometimes you need control flow.

\- benefits for code volume -- I would need to see a real system to evaluate
this claim. It's not fair to compare systems that exist with ones that don't
:)

\- benefits for data abstraction -- SQL agrees here. You don't abstract data.
People sometimes make this mistake in their OOP languages, but's incidental.

~~~
DenisM
I see what you mean. I was thinking of smaller granularity, less than an
entire HTTP request. You have a good point.

------
fabuzaid
I'm surprised no one has mentioned the David Parnas papers: "On the Criteria
To Be Used in Decomposing Systems into Modules" is an all-time classic [1].
Much more philosophical than most of the suggestions here so far, but this
paper really drove home to me the importance of abstraction in software
design. (Also covered in the Morning Paper [2].)

[1]
[https://www.cs.umd.edu/class/spring2003/cmsc838p/Design/crit...](https://www.cs.umd.edu/class/spring2003/cmsc838p/Design/criteria.pdf).
[2] [https://blog.acolyer.org/2016/09/05/on-the-criteria-to-be-
us...](https://blog.acolyer.org/2016/09/05/on-the-criteria-to-be-used-in-
decomposing-systems-into-modules/)

~~~
jonjacky
An excellent textbook that teaches Parnas' approach is "Software Engineering:
Planning for Change" by David Alex Lamb. The chapter Detailed Design is
especially pertinent to this thread. The book is from 1988. I once wrote the
author to ask if there would be another edition. He replied, "publishers
aren't interested because it isn't object oriented". In fact, its lessons are
as relevant to object-oriented programs as any others.

------
zaptheimpaler
DynamoDB paper [1] - one of the big AP, KV stores that kicked off the NoSQL
wave.

Paper about Akamai[2] - "Nuggets in content delivery"

Also, acolyers blog "the morning paper". He reviews and explains one paper
every day. its great because you get a sense of whats current.

[1][http://www.allthingsdistributed.com/files/amazon-dynamo-
sosp...](http://www.allthingsdistributed.com/files/amazon-dynamo-sosp2007.pdf)

[2][https://www.akamai.com/cn/zh/multimedia/documents/technical-...](https://www.akamai.com/cn/zh/multimedia/documents/technical-
publication/algorithmic-nuggets-in-content-delivery-technical-publication.pdf)

~~~
godelmachine
The Morning Paper's Adrian Colyer is a human Machine. I religiously read his
papers.

------
sriram_malhar
Hints for Computer System Design, Butler Lampson.
[https://www.microsoft.com/en-us/research/wp-
content/uploads/...](https://www.microsoft.com/en-us/research/wp-
content/uploads/2016/02/acrobat-17.pdf)

End-to-End Arguments in System Design,
[http://web.mit.edu/Saltzer/www/publications/endtoend/endtoen...](http://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf)

I think Rich Hickey (of Clojure) makes lovely points about application system
design. I know you are looking for papers, but Rich's talks have influenced me
greatly of late. [https://github.com/tallesl/Rich-Hickey-
fanclub](https://github.com/tallesl/Rich-Hickey-fanclub)

~~~
EdwardCoffin
Lampson has done an update of his hints paper, in the form of a presentation
[1] (the video of the talk), [2] (the slides).

[1] [http://www.heidelberg-laureate-
forum.org/blog/video/lecture-...](http://www.heidelberg-laureate-
forum.org/blog/video/lecture-friday-september-27-butler-w-lampson/)

[2]
[http://bwlampson.site/Slides/Hints%20and%20principles%20(HLF...](http://bwlampson.site/Slides/Hints%20and%20principles%20\(HLF%202015\).pdf)

Edit: added link to slides

------
mindvirus
Here are some books, talks and papers that I've found really influential:

Clean Architecture
([https://www.amazon.com/dp/0134494164](https://www.amazon.com/dp/0134494164))
- Uncle Bob has been talking about this for years, but it's a really good
exploration of how to build systems.

Turning the Database Inside Out is a talk that really made Apache Kafka and
stream processing click with me. [https://www.confluent.io/blog/turning-the-
database-inside-ou...](https://www.confluent.io/blog/turning-the-database-
inside-out-with-apache-samza/)

Going through and implementing the Raft algorithm was also very formative for
me - it's the first time I really started to grok the challenges with building
large scale distributed systems.
[https://raft.github.io/](https://raft.github.io/)

And to add a paper to the list to not totally go off topic - Birrell's paper
"An Introduction to Programming with Threads" I thought was a very useful read
- in part for the historical context, but he also breaks down many fundamental
concepts that will look very familiar to the modern reader (it was written
nearly 30 years ago). It's also very readable.
[https://birrell.org/andrew/papers/035-Threads.pdf](https://birrell.org/andrew/papers/035-Threads.pdf)

------
einarvollset
In general, CS (the science) does not often concern itself with the kind of
architecture decisions day-to-day programmers deal with. Instead, the field
tends to offer architecture advice in particularly hairy areas (DB design,
distributed FT consensus, etc). In my opinion, that’s how it should be - the
goals of academics are very different to those shipping code in the real
world. A great developer will be aware of when to turn to academia and when to
turn to industry best practice - too often developers are not aware that they
are wondering into a hairy area, and end up re-inventing flawed and
inefficient versions that are well understood.

~~~
drharby
That last line of yours is so very true. Whenever i find myself going down the
rabbit hole i pick up the nearest relevant academic text and just speedread
the relevant chapter to tailor my search doe relevant readymade solutions.

Developer life is like googlefu xtreme edition

------
mtrn
I liked reading: Program design in the UNIX environment by Rob Pike.
Sometimes, when I think about which features to add to a program I step back
to see, whether a combination of program would actually yield better results.
A practical view into what orthogonality could mean in the tooling world.

[1]
[https://nymity.ch/sybilhunting/pdf/Pike1983a.pdf](https://nymity.ch/sybilhunting/pdf/Pike1983a.pdf)

~~~
igolden
Awesome recommendation

~~~
santix
Good one.

At the bottom of page 3 it says that on UNIX V7 they added an _unbuffered_
(-u) option to _cat_ and then removed it on V8. Does anybody know why they
removed it?

I checked out the man for the GNU version and it says

    
    
      -u     (ignored)

------
elvinyung
I think one of the most useful papers about scaling modern web architectures
is Armando Fox and Eric Brewer's _Harvest, Yield, and Scalable Tolerant
Systems_ :
[https://pdfs.semanticscholar.org/5015/8bc1a8a67295ab7bce0550...](https://pdfs.semanticscholar.org/5015/8bc1a8a67295ab7bce0550886a9859000dc2.pdf)

Not only was it the paper that first put into written word the CAP theorem,
but it also prescribes design principles for scaling out applications with
graceful degradation and "orthogonal decomposition" (i.e. service-oriented
architectures).

It's also a fairly short and easy read at only 4 pages, and I'd definitely
recommend everyone interested in practical modern distributed systems to take
a look.

------
qznc
Conway's Law [0] is an essential aspect for large scale software development:

> Any organization that designs a system (defined broadly) will produce a
> design whose structure is a copy of the organization's communication
> structure.

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

~~~
godelmachine
Nice point. Will keep that in mind.

------
DyslexicAtheist
I compiled a list some time ago, I'm still actively updating it (if you have
ideas for work that should be included please let me know):

"An incomplete list of classic papers every Software Architect should read"
[https://blog.valbonne-consulting.com/2014/06/09/an-
incomplet...](https://blog.valbonne-consulting.com/2014/06/09/an-incomplete-
list-of-classic-papers-every-software-architect-should-read/)

------
chatmasta
Classic reference is Architecture of Open Source Applications [0]

[0] [http://aosabook.org/en/index.html](http://aosabook.org/en/index.html)

~~~
Kagerjay
thats neat there's a full spreadsheet application on there too in this
jsfiddle
[http://jsfiddle.net/audreyt/LtDyP/](http://jsfiddle.net/audreyt/LtDyP/). No
external libraries used either, 99 lines

------
jph
LISP. Recursive Functions of Symbolic Expressions Their Computation by Machine
by John McCarthy at MIT.

[https://aiplaybook.a16z.com/reference-
material/mccarthy-1960...](https://aiplaybook.a16z.com/reference-
material/mccarthy-1960.pdf)

"Introduction: A programming system called LISP (for LISt Processor) has been
developed for the IBM 704 computer by the Artificial Intelligence group at
M.I.T. The system was designed to facilitate experiments with a proposed
system called the Advice Taker, whereby a machine could be instructed to
handle declarative as well as imperative sentences and could exhibit "common
sense" in carrying out its instructions."

------
lachenmayer
Not sure it says a lot about 'architecture', but in terms of 'design', Daniel
Jackson's "Rethinking Software Design" has been an absolute eye-opener:
[https://www.youtube.com/watch?v=cNe6g0qczxE](https://www.youtube.com/watch?v=cNe6g0qczxE)

The premise of the talk is that while software engineering goals & processes
are well-defined and well-understood, the same does not apply for software
design. He sets up a framework of 'purposes' and 'concepts', which in an ideal
design should be a 1:1 mapping. He points out many examples of 'design
smells', where this 1:1 mapping is violated, for whatever reason (engineering
reasons, product management failures, etc.)

Definitely useful not just to developers, but anyone involved in writing
software/affected by the process of writing software.

~~~
charlysl
I am a big fan of Daniel Jackson's approach to teaching programming, and
really like his courses, in particular the mindblowing "Elements of Software
Construction" [1], which is, by a mile, the best programming course I have
come across, and which I believe is sadly underrated; I know there are more
recent versions of this course, by a different professor, that use the more
popular (at least in this forum) Python instead of Java, but IMHO with all due
respect, they are a bit dumbed down and I believe that you won't get the same
out of them. It is not really a Java course, it has improved my programming
(and, very specially, design) in general, in any language. It completely
changed the way I look at design patterns, for instance; it made me really
understand functional programming and state machines; what OO really is about;
how to choose a software paradigm for a given problem; and now I use JSP
stream processing to model many programs (nothing to do with java JSP, it was
created by his dad in the 70s, "the other Michael Jackson").

To really appreciate how much thought went into the design of this course, I
recommend reading "A New Approach to Teaching Programming" [2]

As for the Concepts and Purposes you refer to, there is more on this in [3]
[4] [5] in the MIT 6.170

[1] [https://ocw.mit.edu/courses/electrical-engineering-and-
compu...](https://ocw.mit.edu/courses/electrical-engineering-and-computer-
science/6-005-elements-of-software-construction-fall-2008/)

[2]
[http://people.csail.mit.edu/dnj/articles/teaching-6005.pdf](http://people.csail.mit.edu/dnj/articles/teaching-6005.pdf)

[3]
[https://stellar.mit.edu/S/course/6/fa16/6.170/courseMaterial...](https://stellar.mit.edu/S/course/6/fa16/6.170/courseMaterial/topics/topic2/lectureNotes/L12_-_concept-
slides/L12_-_concept-slides.pdf)

[4]
[https://stellar.mit.edu/S/course/6/fa16/6.170/courseMaterial...](https://stellar.mit.edu/S/course/6/fa16/6.170/courseMaterial/topics/topic2/lectureNotes/L14_-_concepts-
part-2/L14_-_concepts-part-2.pdf)

[5]
[https://stellar.mit.edu/S/course/6/fa16/6.170/courseMaterial...](https://stellar.mit.edu/S/course/6/fa16/6.170/courseMaterial/topics/topic3/resource/Recitation_8_-_Concepts/Recitation_8_-_Concepts.pdf)

------
markc
Kreps and Kleppmann on stream processing, log abstraction, event sourcing:

[https://engineering.linkedin.com/distributed-systems/log-
wha...](https://engineering.linkedin.com/distributed-systems/log-what-every-
software-engineer-should-know-about-real-time-datas-unifying)

[https://martin.kleppmann.com/2015/03/04/turning-the-
database...](https://martin.kleppmann.com/2015/03/04/turning-the-database-
inside-out.html)

[https://www.confluent.io/blog/making-sense-of-stream-
process...](https://www.confluent.io/blog/making-sense-of-stream-processing/)

------
jesperlang
A lot of good suggestions, but quite technical. Are there any good ones
focusing on the design process, with a bias towards CS?

I found this very intriguing:

Towards a Theory of Conceptual Design for Software
[https://groups.csail.mit.edu/sdg/pubs/2015/concept-
essay.pdf](https://groups.csail.mit.edu/sdg/pubs/2015/concept-essay.pdf)

------
fermigier
"Scripting: Higher- Level Programming for the 21st Century" by J. Ousterhout
was certainly very influencial (cf. Python, Ruby, etc.)

[https://web.stanford.edu/~ouster/cgi-
bin/papers/scripting.pd...](https://web.stanford.edu/~ouster/cgi-
bin/papers/scripting.pdf)

Not sure the paper in itself aged so well.

Also, see:

[https://en.wikipedia.org/wiki/List_of_important_publications...](https://en.wikipedia.org/wiki/List_of_important_publications_in_computer_science#Software_engineering)

~~~
charlysl
Thx for the wikipedia link, this is probably the best paper list I've seen so
far

------
tonyspiro
The folks at Heroku have the 12 Factor App
[https://12factor.net](https://12factor.net)

------
q3k
Oldie but goodie: Large-scale cluster management at Google with Borg [1].
Kicked off the mainstream idea that maybe (dev)ops shouldn't care about
servers and Linux service configuration or where exactly their code runs.

[1] -
[https://static.googleusercontent.com/media/research.google.c...](https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/43438.pdf)

------
charlysl
[1] Joe Armstrong 2003. "Making reliable distributed systems in the presence
of software errors" (the Erlang paper, perhaps the most famous implementation
of message passing concurrency).

[2] John Backus 1979. "Can programming be liberated from the von Neumann
style? A functional style and its algebra of programs." (a famous case for
functional programming)

[3] Victor R. Basili and Albert J. Turner. 1975 "Iterative enhancement: A
practical technique for software development" (Agile in 1975? Actually it
seems iterative development can be traced back to the 50s)

[4] Andrew D. Birrell and Bruce Jay Nelson 1984 "Implementing remote procedure
calls" (The idea of making a distributed language operation similar to a local
language operation)

[5] Edsger W. Dijkstra. "Go To statement considered harmful" (the mother of
all those "considered harmful" titles)

[6] Carl Hewitt 1977. "Viewing control structures as patterns of passing
messages". (seminal study of asynchronous messaging)

[7] Carl Hewitt, Peter Bishop, and Richard Steiger 1973. "A universal modular
ACTOR formalism for artificial intelligence" (idem)

[8] Charles Antony Richard Hoare 1974. "Monitors: An operating system
structuring concept". (an early refinement of a very influential concurrency
concept)

[9] Charles Antony Richard Hoare 1979. Communicating sequential processes (an
early presentation of invariants for state machines)

[10] deleted

[11] Gilles Kahn and David B. MacQueen 1977. "Coroutines and networks of
parallel processes" (non preemptive concurrency, an alternative to threads for
collaborative concurrency)

[12] Robert A. Kowalski 1979. "Algorithm = logic + control". (A logic program
can be “read” in two ways: either as a set of logical axioms (the what) or as
a set of commands (the how); the idea behind relational programming, like in
prolog)

[13] Nancy Leveson and Clark S. Turner 1993. "An investigation of the
Therac-25 accidents." (the mother of all race conditions papers? Focuses the
mind about the dangers of interleavings)

[14] Henry Lieberman. 1986 "Using prototypical objects to implement shared
behavior in object- oriented systems." (influenced js? Understanding
delegation)

[15] George A. Miller. 1956 "The magical number seven, plus or minus two: Some
limits on our capacity for processing information." (this might be pushing it,
but maybe the original case for managing complexity)

[16] Chris Okasaki. 1998 "Purely Functional Data Structures." (how to design
functional algorithms)

[17] John C. Reynolds 1975. "User-defined types and procedural data structures
as complementary approaches to data abstraction." (the fundamental abstract
data types concept)

[1]
[http://erlang.org/download/armstrong_thesis_2003.pdf](http://erlang.org/download/armstrong_thesis_2003.pdf)

[2]
[https://www.thocp.net/biographies/papers/backus_turingaward_...](https://www.thocp.net/biographies/papers/backus_turingaward_lecture.pdf)

[3]
[https://www.cs.umd.edu/~basili/publications/journals/J04.pdf](https://www.cs.umd.edu/~basili/publications/journals/J04.pdf)
[4]
[http://www.bighole.nl/pub/mirror/www.bitsavers.org/pdf/xerox...](http://www.bighole.nl/pub/mirror/www.bitsavers.org/pdf/xerox/parc/techReports/CSL-83-7_Implementing_Remote_Procedure_Calls.pdf)

[5]
[https://homepages.cwi.nl/~storm/teaching/reader/Dijkstra68.p...](https://homepages.cwi.nl/~storm/teaching/reader/Dijkstra68.pdf)

[6]
[https://www.cypherpunks.to/erights/history/actors/AIM-410.pd...](https://www.cypherpunks.to/erights/history/actors/AIM-410.pdf)

[7] [http://worrydream.com/refs/Hewitt-
ActorModel.pdf](http://worrydream.com/refs/Hewitt-ActorModel.pdf)

[8] [http://www.cs.unm.edu/~cris/481/hoare-
monitors.pdf](http://www.cs.unm.edu/~cris/481/hoare-monitors.pdf)

[9]
[http://lass.cs.umass.edu/~shenoy/courses/677/readings/Hoare....](http://lass.cs.umass.edu/~shenoy/courses/677/readings/Hoare.pdf)

[11]
[https://hal.inria.fr/inria-00306565/PDF/rr_iria202.pdf](https://hal.inria.fr/inria-00306565/PDF/rr_iria202.pdf)

[12]
[http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.472...](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.472.9550&rep=rep1&type=pdf)

[13]
[https://www.cs.umd.edu/class/spring2003/cmsc838p/Misc/therac...](https://www.cs.umd.edu/class/spring2003/cmsc838p/Misc/therac.pdf)

[14]
[http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.48.6...](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.48.69)

[15]
[http://www.sns.ias.edu/~tlusty/courses/InfoInBio/Papers/Mill...](http://www.sns.ias.edu/~tlusty/courses/InfoInBio/Papers/Miller1956.pdf)

[16]
[https://www.cs.cmu.edu/~rwh/theses/okasaki.pdf](https://www.cs.cmu.edu/~rwh/theses/okasaki.pdf)

[17]
[https://pdfs.semanticscholar.org/71db/39fe3e2a6b80c52b18bd24...](https://pdfs.semanticscholar.org/71db/39fe3e2a6b80c52b18bd24b025428d4a7f44.pdf)

~~~
ramchip
+1 for "Making reliable distributed systems in the presence of software
errors". It's a long read, but it has completely changed the way I approach
programming.

------
fabiopetrillo
Philippe Kruchten's The 4+1 view model of architecture is a very influential
work for software architecture/design:
[https://pdfs.semanticscholar.org/450b/1e34bc072589ed83f72f6f...](https://pdfs.semanticscholar.org/450b/1e34bc072589ed83f72f6f9b00af6d39b311.pdf)
.

------
cpeterso
Eric Evans' _" Domain-Driven Design: Tackling Complexity in the Heart of
Software"_ book is long and pretty dry, but it's immediately practical and
opened my mind to how object-oriented design is supposed to work.

[https://amzn.com/0321125215](https://amzn.com/0321125215)

[https://en.wikipedia.org/wiki/Domain-
driven_design](https://en.wikipedia.org/wiki/Domain-driven_design)

~~~
darethas
Is there a world of software architecture that exists outside the "OOP"
patterns we have seen in the last 2 decades? A quarter of the way through my
career and I have already grown weary of OOP. It's promises are never
realized. It is full of zealots who can argue with you for ages but don't
deliver very much on real world, performant software.

------
osullivj
Brad Cox: Planning the Software Industrial Revolution. A classic from the
creator of Objective-C. Incredibly far sighted in 1990, and still very
relevant today.

[1]
[http://bat8.inria.fr/~lang/hotlist/free/licence/papers/cox/C...](http://bat8.inria.fr/~lang/hotlist/free/licence/papers/cox/CoxPSIR.html)

------
tuukkah
An open graph visualization system and its applications to software
engineering:
[http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.106....](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.106.5621)

------
yogeshp
Here are some links (papers & talks) on scalable software architecture

[https://github.com/Developer-Y/Scalable-Software-
Architectur...](https://github.com/Developer-Y/Scalable-Software-Architecture)

------
eternalban
> .. how we structure our software nowdays

The current trends were mostly blog driven. (Notable exception being the
design approach to _distributed systems and databases_ , which has been noted
by many in this thread. Brewer's CAP theorem, etc., of course, were hugely
influential.)

In terms of "CS" papers, there were a few that argued _against_ the then
prevailing canon such as object orientation. In terms of _theory_ , the
theoretical foundation of much of the current approach can be found
(surprisingly) in papers from the 70s and 80s, e.g. Hoare's CSP (which
influenced Go) is circa '85.

------
westurner
"The Architecture of Open Source Applications" Volumes I & II
[http://aosabook.org/en/](http://aosabook.org/en/)

"Manifesto for Agile Software Development"
[https://en.wikipedia.org/wiki/Agile_software_development#The...](https://en.wikipedia.org/wiki/Agile_software_development#The_Agile_Manifesto)

"Catalog of Patterns of Enterprise Application Architecture"
[https://martinfowler.com/eaaCatalog/](https://martinfowler.com/eaaCatalog/)

Fowler > Publications ("Refactoring ",)
[https://en.wikipedia.org/wiki/Martin_Fowler#Publications](https://en.wikipedia.org/wiki/Martin_Fowler#Publications)

"Design Patterns: Elements of Reusable Object-Oriented Software" (GoF book)
[https://en.wikipedia.org/wiki/Design_Patterns](https://en.wikipedia.org/wiki/Design_Patterns)

.

UNIX Philosophy
[https://en.wikipedia.org/wiki/Unix_philosophy](https://en.wikipedia.org/wiki/Unix_philosophy)

Plan 9
[https://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs](https://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs)

## Distributed Systems

CORBA > Problems and Criticism (monolithic standards, oversimplification,):
[https://en.wikipedia.org/wiki/Common_Object_Request_Broker_A...](https://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture#Problems_and_criticism)

Bulk Synchronous Parallel:
[https://en.wikipedia.org/wiki/Bulk_synchronous_parallel](https://en.wikipedia.org/wiki/Bulk_synchronous_parallel)

Paxos:
[https://en.wikipedia.org/wiki/Paxos_(computer_science)](https://en.wikipedia.org/wiki/Paxos_\(computer_science\))

Raft:
[https://en.wikipedia.org/wiki/Raft_(computer_science)](https://en.wikipedia.org/wiki/Raft_\(computer_science\))
#Safety

CAP theorem:
[https://en.wikipedia.org/wiki/CAP_theorem](https://en.wikipedia.org/wiki/CAP_theorem)

------
inopinatus
Not a paper, but Martin Fowler's book "Refactoring" changed the way I
structure my domain models forever.

------
justonepost
Decouple and cohesion. Beyond that it's pretty domain dependent.

------
JeroenRansijn
Write code that is easy to participate in.

------
frantzmiccoli
I would recommend Martin Fowler articles
[https://martinfowler.com/](https://martinfowler.com/)

------
harishneit
For me, it would be:

1\. actor model of computation
([https://arxiv.org/abs/1008.1459](https://arxiv.org/abs/1008.1459)) 2\. map
reduce
([https://research.google.com/archive/mapreduce.html](https://research.google.com/archive/mapreduce.html))

~~~
macintux
On the industrial side, Jim Gray's paper complements Hewitt's nicely.

[http://www.hpl.hp.com/techreports/tandem/TR-85.7.pdf](http://www.hpl.hp.com/techreports/tandem/TR-85.7.pdf)

(On second thought it helps to have Armstong's thesis on Erlang as a bridge
between them, but I can't find an easily downloadable link at the moment.)

~~~
EdwardCoffin
I also like the set of slides _Paranoid Programming - Techniques for
Constructing Robust Software_ [1] from Stratus Computer. They were discussed
here earlier this year [2]

[1]
[http://ftp.stratus.com/vos/doc/papers/RobustProgramming.ps](http://ftp.stratus.com/vos/doc/papers/RobustProgramming.ps)

[2]
[https://news.ycombinator.com/item?id=13678251](https://news.ycombinator.com/item?id=13678251)

