4 ms·

Agreed. If I can't refactor the architecture as easily as the domain code, it's too brittle.

• AlisdairO 12y ago
  A persistence layer might have literally millions of lines of code that (directly or indirectly) depend upon it. The operation 'get me this object' is potentially present throughout your architecture. I can't imagine how you would make that as easy to refactor as an encapsulated piece of code. Sure, you could do a programmatic refactor that changes all the calls to request an array of one item, but that's pointless. Actually changing the code so that it truly batch-oriented is inevitably a substantial task.
  • hawleyal 12y ago
    I don't understand how you would have a persistence layer or otherwise that can't be refactored without changing external code that depends on that layer. Batch is hard of course. But it's conceivable to have a crappy implementation (just looping single statements) and then later refactor it to do it database side, or perhaps in parallel (looping single statements simultanously). All the while without modifying the dependent code. No?
    • AlisdairO 12y ago
      That's exactly the approach I'm recommending :-). Basically, put thought into the api up front so that later, performance improvements are a master of improving local code, rather than architectural changes.
• dragonwriter 12y ago
  > If I can't refactor the architecture as easily as the domain code, it's too brittle. The thing is "refactoring architecture" often requires being able to abstract things in ways that popular programming languages make difficult, and which most programmers aren't familiar with dealing with and reasoning about. Its the same kind of problem that makes Haskell seem hostile to many programmers.