>5. There is no “sense” of n-tier design. You code against
> an object with CRUD methods. It internally may have a
> data layer, but that’s hidden. Business rules/processes/workflows
> are built into the objects themselves (since the transaction
> root is the object).

Wow! This is the first time I heard such comment on MM. I would be interested in hearing what definition of n-tier was used to come to this conclusion.

> You ‘typically’ wouldn’t have a business and data tier in
> this case; you just call methods on objects from the
> presentation tier.

Could you clarify in what case you would typically wouldn't have this?

Due to the comments on point 4 I suspect you guys are trying to implement a Service Oriented Architecture.

If you decide to use SOA, you still can/should implement each service with an OO/n-tier approach regardless of how lose the integration between applications at the service level is.

Keep in mind that service oriented architecture (SOA) is different from n-tier architecture. A lot of people mix them both and this causes lots of confusion.