Confreaks
10 HN recommenders · recommended in 11 months, 2013–2022
1:06:39 · 172K views · Jan 18, 2012
Robert C. Martin's Ruby Midwest 2011 keynote argues that software architecture should express the application's intent rather than its framework. He covers separating entities, interactors and boundaries so the web, database and framework are details.
Frequently recommended as an influential talk on decoupled, testable architecture, though some commenters push back on Martin's TDD advocacy.
14 comments from Hacker News
> Many people will argue that not using a framework means write everything yourself. This is a false dichotomy. We can use libraries and frameworks just fine. ... > But we should give them a clear, and well-isolated place in our project. ... There's an excellent, if older, presentation called "Architecture, the Lost Years" that addresses exactly this problem and gives very specific, actionable guidance on how to solve it: this video But how to pull off this decoupling? The answer is both obvious and surprising. Define a boundary. On one side is the framework. On the other side is your code. Through the boundary, only dumb data structure can pass. JSON works. So do structs. So does XML. The point is that these are behaviorless blobs of data. This buys you a lot. You can run your application completely detached from the network, a database, and other expensive dependencies. So testing becomes much simpler and easier. And of course, you can replace the framework by writing new boundary code. The other big lesson has something to do with why frameworks get added to a project in the first place. When designing a system, the goal should be to defer major decisions for a long as possible. That's when the best information is available. Sometimes you can just defer until the point becomes moot, which is a major win. Reaching for a framework before being forced to do so sets up the kind of situation the author is talking about.
Excellent riposte! Mine was going to be somewhat less polite :-) Can't stress enough that TDD is not about testing (sth. DHH, like many if not most critics gets wrong). It is about development and design. The fact that you get a pretty decent test suite out of it is a nice side effect. (Love me those side-effects, wouldn't want to program without 'em). I also find that whenever I skimp, it always comes back to bite me. And usually it was because I hadn't understood the problem-space well enough to write a proper test. That's one important part of TDD for me: I have to understand the requirements well enough to actually write a test for them. And the OP is also right in that Rails is a bad environment for TDD, as far as I can tell, because all the magic and auto-integration gets in the way and has to be laboriously stubbed/mocked etc. Maybe it's time the community got over Rails. (See also Uncle Bob's excellent architecture talk: this video ).
The talk that had the most influence on how I write software is Robert 'Uncle Bob' Martin's "Architecture: The Lost Years" [1]. Being a Ruby conference keynote, it helps if you know how Ruby on Rails works, but the lessons apply to all software. Another one would be "Let It Crash! The Erlang Approach to Building Reliable Services" by Brian Troutwine. [2] I don't know if you would call it "technical" but Brett Slatkin's talk on Cohort Analysis is something anyone interested in tools to analyze how our users behave should watch. [3] [1] this video [2] [LINK] [3] [LINK]
Here's Uncle Bob talking on his version of the idea extensively: this video The main idea is to separate the system into entities, interactors and boundaries, which correspond roughly to model, controllers and interfaces+DTOs (Data Transfer Objects), but with the difference that model classes are not exposed through the interfaces. Rather, the DTOs are used to communicate the changes in the data. We have been using this approach for a year now, with REST on top, and it so far has worked beautifully. The entities map naturally to REST resources and DTOs makes nice request and response classes. Armed with CQRS (now I sound enterprise-y), the data storage is easy to work with using the same DTOs (the data storage and its interface do not know anything about the entities either). On the DB implementation level, we work on the DTOs, which are trivial to store to the database (even without ORM, although it does remove much of the boilerplate). Only one class - the entity repository - is needed to convert the DTOs to entities, and this only happens on create, update, and delete. Reads (due to CQRS) go directly to DB without instantiating any entities - neat. We also use 'unit of work' -pattern to abstract the notion of transaction on create, update, and delete operations, which simplifies the interactor code, hiding the nature of the data storage (making it a swappable in this respect too). But to stay on topic, our tests are fast too as the interactors can be tested by injecting an in
> Although the design above is perfectly valid in terms of OOP, neither of these classes are actually unit-testable. Because LocationProvider depends on its own instance of HttpClient and SolarCalculator in turn depends on LocationProvider, it’s impossible to isolate the business logic that may be contained within methods of these classes. The design of those classes is bad, and the perceived need to reach for mocks (or interfaces) is telling you that. The next step the author takes is to go for interfaces. That's not what I'd do. Instead, I'd decouple network from calculation with intermediate dumb data structures. The network side produces the data structure and the calculation side consumes it. The network side can further be broken down with a transformation of the API call result into the dumb data structure used for calculations. This idea comes from an old Bob Martin presentation [1]. The whole thing is worth watching to put it into context. This is the kind of thing that never seems to get discussed in these pieces praising integration tests over unit tests. For even better results, ditch the classes altogether and just use functions. It's quite surprising how badly designs come off the rails with the "everything is a class" model. [1] this video