title: Service-Orientation vs Object-Orientation - can they coexist?
body: <p>There's been a lot of interest in <a href="http://en.wikipedia.org/wiki/Service-oriented_architecture" rel="noreferrer">Service-Oriented Architecture</a> (SOA) at my company recently. Whenever I try to see how we might use it, I always run up against a mental block. Crudely:</p>
  
  <ul>
  <li><p>Object-orientation says: "keep data and methods that manipulate data (business processes) together";</p></li>
  <li><p>Service-orientation says: "keep the business process in the service, and pass data to it".</p></li>
  </ul>
  
  <p>Previous attempts to develop SOA have ended up converting object-oriented code into data structures and separate procedures (services) that manipulate them, which seems like a step backwards.</p>
  
  <p>My question is: <strong>what patterns, architectures, strategies etc. allow SOA and OO to work together?</strong></p>
  
  <hr>
  
  <p><strong>Edit:</strong> The answers saying "OO for internals, SOA for system boundaries" are great and useful, but this isn't quite what I was getting at. </p>
  
  <p>Let's say you have an <code>Account</code> object which has a business operation called <code>Merge</code> that combines it with another account. A typical OO approach would look like this:</p>
  
  <pre><code>Account mainAccount = database.loadAccount(mainId);
  Account lesserAccount = database.loadAccount(lesserId);
  
  mainAccount.mergeWith(lesserAccount);
  
  mainAccount.save();
  lesserAccount.delete();
  </code></pre>
  
  <p>Whereas the SOA equivalent I've seen looks like this:</p>
  
  <pre><code>Account mainAccount = accountService.loadAccount(mainId);
  Account lesserAccount = accountService.loadAccount(lesserId);
  
  accountService.merge(mainAccount, lesserAccount);
  // save and delete handled by the service
  </code></pre>
  
  <p>In the OO case the business logic (and entity awareness thanks to an ActiveRecord pattern) are baked into the <code>Account</code> class. In the SOA case the <code>Account</code> object is really just a structure, since all of the business rules are buried in the service.</p>
  
  <p><strong>Can I have rich, functional classes and reusable services at the same time?</strong></p>