Build vs Buy vs CQRS/DDD and OOP Common Wistom

I recently watched Greg Young's CQRS/DDD talk thanks to the Clojure Gazette. Even before I finished watching the video I had forwarded it to several people. I lot of it resonated with me. The desires of the business partners vs the "OOP" patterns and thinking that created the systems never seemed to line up.

There were two points Greg made which really stood out to me:

1. DDD is really expensive.
2. Methods belong on the data object.

1. DDD is Expensive?

He spoke about DDD being very expensive and only fit for competitive advantage domains with high complexity because of that expense. I'd like to understand is this a Build vs Buy argument? Or DDD vs the popular OOP/CRUD methodologies? Because Build vs Buy I get. For example I agree that it doesn't make sense to custom build a Customer Relation Management (CRM) solution anymore unless there is something different about your sales process that off-the-shelf solutions can't provide. What are about a domain where there isn't an off-the-shelf solution and competitive advantage is arguable at best.

For simple systems with low data volume and low-to-no batch processing I can see how "common wisdom" (Rails, ORMs, JEE, Spring, etc) can seem like the right choice. As Greg said "We'll use X, Y, and Z, now what are we going to build?" is pretty common. Especially for getting it made quickly maybe go-with-what-you-know is the right choice.

I guess I'd just like to understand the cost of doing DDD better and how it compares to popular development.

2. Methods belong on the Data Object?

For a while now I've had a growing opinion that domain objects shouldn't have methods at all. My experiences have almost entirely been modeling inanimate business data. In the real world an insurance policy has no actions of it's own, it is entirely acted upon. The common example of putting a walk() method on a Dog object breaks down. And the actions upon the data change more frequently than the structure of the data.

The way I was taught Object-Oriented Programming seems like a bad fit for modeling a data domain. In my experiences trying to do that has caused more problems than it solves. I've seen it cause poor data store designs in relational databases. It also seems to encourage coupling and conflating of contexts. "We've already got a Policy object and ORM mapping for it, let's just tack this other context onto that." Inheritance often doesn't apply or is misused to once again bind and conflate separate contexts together.

Maybe I've just spent too much time playing around with Clojure and other functional languages.