Would totally recommend this book "Patterns of Enterprise Application Architecture" by Martin Fowler

https://martinfowler.com/books/eaa.html

Patterns of Enterprise Application Architecture. Pretty basic - looking for a good read though and my reading list is running dry. Manning is releasing some good stuff on reactive development that I'd recommend - the Reactive Design Patterns material that is available is super good.

Martin Fowler's Patterns of Enterprise Application Architecture was a great read. It goes into a ton of patterns and theory. It's worth a read, even though it's branded for the enterprise.

While the preamble said something along the line of "these books are valuable for 'enterprise' dev situation', I find that a lot of ideas from those books are fully applicable to startups/hot-tech-companies.

Release It! => applicable

Continuous Delivery => applicable

Effective Java => absolutely IF you use Java (see other 'effective' series such as Effective C#, Effective C++ [_the_ grandfather], Effective JavaScript)

Patterns of Enterprise Application Architecture => Guess where Rails come from? (hint: DHH name is also mentioned somewhere in the book)

Please do tell? Patterns of Enterprise Application Architecture (PEAA), Refactoring, Refactoring to Patterns, and the various Pragmatic books.

This one is supposed to be good: Patterns of Enterprise Application Architecture, by Martin Fowler
http://www.amazon.com/Patterns-Enterprise-Application-Archit...

I am trying to do the same thing as you, and I recently ordered this text based on a recommendation from a mentor.

They're not all writers, some just invented things like the Wiki. The original wiki, the portland pattern repository, was a hotbed of discussion among those programmers about the practices that eventually became known as agile. It was an amazing place to hang out and debate patterns, languages, and architecture with other passionate developers. There's been nothing like it since.

But from the writers:

    * Refactoring
    * Patterns of Enterprise Application Architecture
    * Smalltalk Best Practice Patterns
    * Agile Software Development, Principles, Patterns, and    Practices
    * Domain-Driven Design
    * Structure and Interpretation of Computer Programs
    * The Pragmatic Programmer
    * Design Patterns
    * Analysis Patterns
    * Implementation Patterns

Fowler is the most prolific writer of the bunch, but he was largely documenting and naming what he saw all of them doing.

Rails at least, was heavily inspired by the book Patterns of Enterprise Application Architecture from 2003. That - in turn - drew a lot from the Java world, that was the lingua franca at the time.

I like Patterns of Enterprise Application Architecture, which includes some domain logic patterns. A common one is SOA, by dividing the backend into services that your UI consumes.

I really like the look of the patterns of enterprise application architecture book also by Martin fowler but is there really nothing more recent covering the same subject. Surely a new edition is overdue?

My top priority books:

    Software Requirements - Karl Wiegers

    Programming TypeScript - Boris Cherny

    Associate Cloud Engineer Study - Dan Sullivan

    Design Patterns - Gang of Four

    Refactoring - Kent Beck, Martin Fowler

    Programming Pearls - Jon Bentley

    Patterns of Enterprise Application Architecture - Martin Fowler

    The Pragmatic Programmer - David Thomas, Andrew Hunt

    CSS: The Definitive Guide - Eric A. Meyer, Estelle Weyl

    Working Effectively with Legacy Code - Michael Feathers

    Head First Design Patterns - Eric Freeman, Bert Bates

    Code Complete - Steve McConnell

    Peopleware - Tim Lister, Tom DeMarco

    Clean Code - Robert C. Martin

    The Clean Coder - Robert C. Martin

    Clean Architecture - Robert C. Martin

    Don't Make Me Think - Steve Krug

    Functional Design Patterns for Express.js - Jonathan Lee Martin

    The Surrender Experiment - Michael A. Singer

The best books I've ever read:

    Principles - Ray Dalio

    The Power of Now - Eckhart Tolle

    The Effective Executive - Peter F. Drucker

    Think and Grow Rich - Napoleon Hill

    Extreme Ownership - Jocko Willink, Leif Babin

    Influence - Robert B. Cialdini

    The Startup Way - Eric Ries

    The Lean Startup - Eric Ries

    12 Rules for Life - Jordan B. Peterson

    Measure What Matters - John Doerr, Larry Page

    The Fish That Ate the Whale - Rich Cohen

    The E-Myth Revisited - Michael E. Gerber

    The Score Takes Care of Itself - Bill Walsh, Steve Jamison, Craig Walsh

    Management - Peter F. Drucker

    Thinking in Systems - Donella H. Meadows

    Blue Ocean Strategy - W. Chan Kim, Renee Mauborgne

RR, Ruby Rogues - https://devchat.tv/ruby-rogues
This was the one must fun and favorite, until panel split to https://www.greaterthancode.com

They had around 15 episodes where they discussed books with their authors, for example:

- RR Book Club: Smalltalk Best Practice Patterns with Kent Beck

- RR Book Club: Understanding Computation with Tom Stuart

- RR Book Club: Patterns of Enterprise Application Architecture with Martin Fowler

- RR Book Club: Refactoring Ruby with Martin Fowler

Another cool thing was picks at the end of each episode https://github.com/ryanburgess/ruby-rogues-picks

Software Engineering Radio - http://www.se-radio.net

FLOSS weekly - https://twit.tv/shows/floss-weekly

The Amp Hour - http://theamphour.com

I would recommend that you read a book a week, every week, for the rest of your life. :)

Just start with the ones in the article and Amazon/Kindle will get good at recommending books.

Here's some books recently read on my Kindle:

  - No Rules Rules
  - Never Split The Difference
  - The Manager's Path
  - The Almanack of Naval Ravikant
  - Ultralearning
  - The Hard Thing About Hard Things
  - What You Do is Who You Are
  - User Story Mapping
  - Inspired
  - The Lean Product Playbook
  - Competing Against Luck
  - Domain Driven Design
  - Patterns of Enterprise Application Architecture
  - Data-Driven Marketing
  - Designing Data-Intensive Applications
  - Monetizing Innovation
  - Super Thinking
  - The Great Mental Models
  - Nonviolent Communication
  - High Growth Handbook
  - Powerful
  - Trillion Dollar Coach

What do people recommend for learning about SOA / microservices? I liked Patterns of Enterprise Application Architecture and Enterprise integration patterns, but didn't have a great experience with the SOA design with Rails book - it felt much to focused on very basic details (e.g., here is how you consume JSON).

The facts that the book focuses on exactly the kind of patterns which are not abstractable into libraries in the popular OOP languages of the time (mostly true now, too), and that the implementation of each pattern is central to the presentation -- both of which arguably have quite good reasons based on the books intended role, to be sure -- I think promote this misunderstanding.

Certain other design patterns books in the software field (Patterns of Enterprise Application Architecture and Enterprise Integration Patterns, for examples that happen to be on the shelf next to me at the moment) don't share those features.

Patterns of Enterprise Application Architecture
by Martin Fowler

This book is actually two books in one. The first section is a short tutorial on developing enterprise applications, which you can read from start to finish to understand the scope of the book's lessons. The next section, the bulk of the book, is a detailed reference to the patterns themselves. Each pattern provides usage and implementation information, as well as detailed code examples in Java or C#. The entire book is also richly illustrated with UML diagrams to further explain the concepts.

Armed with this book, you will have the knowledge necessary to make important architectural decisions about building an enterprise application and the proven patterns for use when building them.

Edit: I meant Patterns of Enterprise Application Architecture by Fowler in my comment above. Recommended by DHH.

Hi, Obie! :-) If I hadn't discovered Python first, I probably would have been a Ruby fanatic, too. But yeah, I mostly do JavaScript now.

Ironically, I've a got a theory (I did confirm parts of this with Martin years ago, though), that it's all Martin's fault. Before Martin was into Ruby, for a brief period of time, he was a Python fan. But by the time we wrote Patterns of Enterprise Application Architecture, he was full-on into Ruby. Then DHH came along and wanted to implement one of the first patterns listed (Active Record). DHH wanted to to step away from PHP and write his new code in whatever Martin's favorite language was. And the rest is history. But within a small window of time, DHH's project might have been called Python on Rails. So, it's all Martin's fault that you (or DHH or half of ThoughtWorks) never became a Python fanatic. :-)

"Patterns of Enterprise Application Architecture" by Martin Fowler made a big difference for me at the time. Also, "Domain Driven Design" by Eric Evans. Both have a focus on high level architecture.

Of books that are more on the craft of programming, "Refactoring" (Also Fowler) is good. And I enjoyed "Practical Common Lisp" by Peter Seibel too.

In general, I suspect that the value of a book has more to do with where the reader is, than where the book is.

For me, there have been more than one. I'll list them in the order I read them. I have them all in an eBook form to read in my Kindle App on my Nexus 7.
1) Clean Code
2) Pragmatic Programmer
3) Patterns for Enterprise Application Architecture

There's some overlap in contents, but I feel they complement each other very well.

I would if I had time. Or they could just read the chapter of Patterns of Enterprise Application Architecture that they took the name from - it's the chapter right after Active Record :) Page 165. Martin Fowler went into a decent amount of depth in describing the pattern. His site also has a decent summary available for free.

I don't think this is exactly is lack of awareness on their part, though - as someone else has pointed out, Datamapper actually implements the Active Record pattern. Structurally the two are very different.

Finished: Where I Belong, Alan Doyle.
Light Christmas reading written by the lead singer of Great Big Sea. I recommend it to anyone who grew up in a small town!

Reading: Patterns of Enterprise Application Architecture, Martin Fowler
So far so good. The first bit is overview, good contrasting examples of when to use what pattern. I've slowed down now that I've hit the actual patterns.

Planning: Clean Code, Robert Martin.
Recommended by a coworker.

Patterns of Enterprise Application Architecture was a revelation for me. Not that I went on and directly applied the knowledge in that book for the most part (largely due to the fact I've never been a Java developer), but the thinking behind the book really helped me go from "hack shit together" to a thoughtful and disciplined programmer.

You're right, sorry. It's in the "Martin Fowler" Addison Wesley series of books, it's not written by Fowler. I've had the book on my shelf and read a good bit of it, and should have caught that!

"Martin Fowler" is on the cover in two different places, plus it looks just like the cover of Patterns of Enterprise Application Architecture, which he did write, so I've had that misconception in my brain for a while. Failure to test assumptions...

> it's getting from what needs to happen to how to decompose into classes/methods/libraries

Perhaps the problem doesn't fit into an object oriented solution. You could try learning a functional language and see if you find it fitting better. I struggled for years with OO and was never happy with my solutions. Learning functional was my road to Damascus experience.

If you have to go OO, there have been plenty of people who have thought long and hard about how to make OO a suitable solution. Some classic books you may want to consider :

- Design patterns : elements of reusable object-oriented software (Gang of four) - there are people who swear by this and turn it into their hammer for which everything becomes a nail.

- Patterns of Enterprise Application Architecture (Martin Fowler)

- Refactoring: Improving the Design of Existing Code (Martin Fowler and Kent Beck)

- Growing Object-Oriented Software, Guided by Tests (Steve Freeman)

Refactoring by Martin Fowler and Kent Beck.

Patterns of Enterprise Application Architecture by Martin Fowler.

Domain Driven Design by Eric Evans.

Growing Object-Oriented Software, guided by tests by Steve Freeman and Nat Pryce.

Patterns of Enterprise Application Architecture by Martin Fowler helped me make the jump from small systems built for myself to large, sophisticated systems built for others.

The Mythical Man Month by Fred Brooks really helped me learn to think about large projects from a personnel and planning perspective. There are some ideas there that have become part of the CS canon; "no silver bullet" and the slightly sexist but accurate metaphor for throwing more people at an overdue project, "nine women can't make a baby in one month." The Mythical Man Month was written in 1975, but it holds up remarkably well.

I disagree that Patterns of Enterprise Application Architecture is an excellent book. I found it to be poorly written and appallingly edited. (Martin Fowler is capable of much better.) More importantly, the patterns themselves give an impression of coherence and well-understoodness to a space that is in fact incoherent and poorly understood. This results in people thinking and talking more about patterns than about the problems they're actually trying to solve with software. In other words, the whole enterprise (pun intended) is premature optimization at a meta level.

Refactoring is better because it's on a smaller scale and thus able to deliver roughly what it promises.

As far as the enterprise-OO space goes, though, the best book by far IMO is Eric Evans' Domain Driven Design. One reason it's better (apart from being superbly written) is that it's much more exploratory: it doesn't pretend to have figured things out, but rather offers principles you can use to figure things out. Also, the principles, though deep, are easy to understand (as opposed to "enterprise application architecture patterns" which get more confusing the more you try to understand them). In fact, the only weak spots in DDD are the points at which it veers closer to the PEAA approach.

(Disclosure: I worked with Eric for several years. But my high opinion of his book was not caused by this; it was the other way around.)

Martin Folwer talks about several approaches for handling domain logic. Transaction Script, Domain Model, Table Module, and Service Logic. He explains the trade offs of each on the Patterns of Enterprise Application Architecture book.

It feels like arguing about colors from the whole spectrum of the rainbow without saying which color we're arguing about.

The point of patterns is to recognise things that reoccur all the time, ie. DFS is a pattern, FIFO queue as well, so stack, parser combinator, microservice, optimistic locking, proxy, demux etc.

The whole point it to use common volabulary where you can drop this "pattern" suffix when discussing things.

It can be anything, GoF described an idea and couple of patterns in OO context, there are many other books "Analysis Patterns", "Enterprise Integration Patterns", "Patterns of Enterprise Application Architecture" etc.

For the inexperienced, it might be informative to have a list of the most common mistakes & errors.

But then, you also can see at once that this post came directly from the Dark Ages when people believed in silver bullets named “Methodology”. The post even mentions Martin Fowler's bestiary (Patterns of Enterprise Application Architecture) as an inspiration. So don't say you haven't been warned...

The problem with any book list like this is the scope. Software is turning into a very diverse culture, a very heterogeneous ecosystem. Subjects that are very important to one area might not be as important to other areas. Design patterns are essential for enterprise development, not so much for AI and low level systems programming. Algorithms are essential for the latest but not for the former.

Given this, there are some books you might add or remove depending on the area you are interested (e.g.: Knuth's "Art of Computer Programming", Martin Fowler's "Patterns of Enterprise Application Architecture", ...)

To finish, 2 books people recommend a lot for beginning programmers:

"The Pragmatic Programmer"- Hunt, Thomas: a very good book, with sound advice and very easy to read. The only bad side is that it became so influential that its ideas became vulgarized in thousands of blogs.

"Code Complete" - Steve McConnel : A very dangerous book. It does give have a lot of sound advice. But, IMO, it has some big problems. First is that it gives the false impression that there is a lot of empirical evidence on what works on software engineering. Second, it perpetuates some myths that don't have such evidence: the "orders of magnitude programmer's productivity" and "the cone of uncertainty" (see: https://leanpub.com/leprechauns).

Personally I think this is a good starting point: http://gorban.org/post/32873465932/software-architecture-che...

In terms of books, I really like "The Architecture of Open Source Applications" (http://aosabook.org/) which is also mentioned in the blog post. For the enterprise world, "Patterns of Enterprise Application Architecture" (http://martinfowler.com/books/eaa.html) is a good choice.

However, before applying any technical software architecture methods, it is really important to understand what your stakeholders actually want/need. Unfortunately most of the time they don't even know it themselves. In my experience most software projects fail, not because of technical reasons but simply because the original problem hasn't been understood. This is where communication is key. I assume the reason why the authors of the blog post encouraged drawing diagrams and looking at different perspectives/views is to facilitate this communication.

I find high level abstractions more practical, and easier to understand, when I work on larger projects. I would recommend looking at larger open source products or picking up a few books on enterprise software design. You can skim through the academic theory, if you're already familiar with it, and concentrate on extending their code examples.

Patterns of Enterprise Application Architecture - by Martin Fowler
Domain Driven Design - by Eric Evans

Very good point about specializing the reading list for the areas developers are interested in. You're right, trying to come up with a one-size-fits-all reading list is foolhardy.

Re: The Pragmatic Programmer and Code Complete, I learned a ton from those books and I'd heartily recommend them to programmers starting their first job or internship, but likely not to someone with a few months before their first round of programming interviews. What do you think?

Maybe I will put together another list more tuned for general programming improvement versus interview-specific prep.

As an aside, Patterns of Enterprise Application Architecture looks very useful, thank you for the pointer.

Laurie, this is a good restatement of the age-old problem of Object/Relational impedance, the perennial bugaboo of many an architect, developer, and DBA. It's true that ORMs are merely bandaids on what is essentially an intractable set-theoretical problem, but we've learned over the years that in the right hands an ORM is a tremendous productivity boost, provided the team is aware of the limitations. In fact Martin Fowler's original definition of the ActiveRecord pattern in Patterns of Enterprise Application Architecture describes some of these limitations from the very beginning.

"Unfortunately, these advantages disappear as the project increases in complexity: the abstraction breaks down, forcing the dev to use and understand SQL"

"Forced" to use and understand SQL? I think you have a basic misunderstanding of the purpose of ORMs, Laurie. The developer who can't use and understand SQL really has no business going near the ORM. They probably need to stay somewhere near the front-end doing design, layout and UI-centric work.

The purpose of an ORM, properly used, is not at all to completely remove SQL from the developer's toolkit, but to help developers who fully understand SQL and Objects eliminate boilerplate SQL. This has a huge dual benefit of productivity boost plus elimination of bugs by the reduction of code/SQL duplication.

If an ORM developer is not aware of SQL (i.e., watching their rails log for odd queries/joins) and the natural problems that arise, such as n+1, etc. then they probably shouldn't be writing data-layer concerns. ORMs are for experienced developers who know how to use things like the ActiveRecord or DataMapper DSLs when appropriate, and can also drop into straight SQL when appropriate. ORMs are power tools for serious developers who can use them for what they do well, and know how to avoid their weaknesses, which you outline well here.

Because of their benefit and the cumulative experience we've had in the last 10 years or so getting to know how to use ORMs effectively, they're not going away any time soon. However, they certainly have their pitfalls and it's important that we have posts like these every few years or so to remind us what those pitfalls are. So thanks!

I usually read books when I'm trying to learn something new and complex, such as a new programming language. I have a few reasons for that:

- The information in books is complete. Tutorials on the web usually cover only a tiny fraction of everything there is to know about a specific technology. Tutorials often go deep into a specific part of the technology, or try to cover everything in a very shallow way. Books provide a thorough explanation of everything, nut just a tiny fraction.

- Books (if you make the right selection, I usually type "best [some technology] book" in google and read the suggestions on stackoverflow or other programming sites) are usually written by authoritative people in the industry. Very often by the author of the programming language that you're trying to learn. Not by some amateur who has some spare time and wants to write a blog post.

- It's much more pleasant to read long texts on paper than on a bright computer screen where you have to scroll all the time and cant place physical bookmarks.

As for your last question (what I read and can recommend):

Tech:

- Design patterns : elements of reusable object-oriented software

- Patterns of Enterprise Application Architecture

- Code Complete 2

- Clean Code

- Pro ASP.NET MVC (if you're into MS stuff like me)

- Scrum and XP from the trenches

Marketing/business:

- Business model generation

- Purple Cow

- Permission marketing

- Rework

(how to do these line breaks correct?)

I didn't like SICP. I can handle boring books, but this one is pretty extreme.

I'm currently reading Martin Fowler's "Patterns of Enterprise Application Architecture"[0] and I think that one of the main points that stuck with me is his recommendation for separation between the various layers and functions of a software system.

Basically the whole system should be a layer cake of smaller modules/systems, as "opaque" as needed to one another, but interacting with each other solely through a well defined "internal API".

I think the approach proposed in the article is good when starting or prototyping projects, but the object oriented and layering approach, even if it's a bit more challenging to visualize correctly at the start of the development of an app, is worth its weight in gold as features start piling up.

[0] http://www.amazon.com/Enterprise-Application-Architecture-Ad...

later edit: for clarity.

I stopped reading whole books about specific language or technology 5 years ago. But sometimes do buy them to look into a couple of chapters when needed. These kind of books I usually acquire in electronic form as they are easier to use as a reference that way. Plus they tend to get old in a couple of years at which point they'd only serve to gather dust.

Last book about a specific language I read from cover to cover was "Expert Python Programming" which is more about best practices, testing and packaging etc.
I feel I learn much more by looking at source code then reading books or tutorials on something.

Books like "Patterns of enterprise application architecture", "Programming collective intelligence", "RESTful Web Services" etc. I do buy and read from cover to cover at least once every quarter.

The book Patterns of Enterprise Application Architecture (PoEAA) laid the blueprints for Rails’ architecture. However, as applications growing more and more complex, developers are starting to realize these default architectural patterns come with Rails may not scale very well. In the post PoEAA on Rails, I walk you through some enterprise patterns from the same book that Rails’ architecture heavily base upon, and provide suggestions on scaling your Rails codebase.

There are defined Architect roles when you work at large companies where the division of labor requires more specific roles.

Like others have said, the focus should be on the bigger picture of the overall system(s) and how they inter-relate.

As you move around in your career, look for roles where you have more say in how the system is designed in the beginning. Take on more responsibility in how different modules/components interact.

Also read up on design patterns - including the book Patterns of Enterprise Application Architecture by Martin Fowler (and read his blog/site too).

Much of architecture is focusing on the parts of the system that have high risk and making them less risky, usually these are the parts where the systems interact with each other.

A few ideas. The data model. How to map and continually re-map the server side model to the client side model. The design patterns appropriate to the problem, for instance using redux middleware to implement an interceptor, and leveraging any number of message based programming patterns from the Patterns Of Enterprise Application Architecture book. The communication mechanism from client to server. The data serialization format. Establishing testing patterns that are reliable in preventing bugs and regressions.

Patterns of Enterprise Application Architecture is one of my all time favourites, though it hasn't been as influential as it should have been.

It's sitting proudly behind me next to The Mythical Man Month, the GOF book, the Dragon book, Refactoring, Code Complete and The Visual Display of Quantitative Information.