[aamar]

Probably worth bringing up Steve Yegge's 2006 "Execution in the Kingdom of the Nouns": http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom...

I don't think there is a single right answer that is applicable in all cases. But over time, I've come to believe that as a default, code works well when it resembles how you'd ideally explain the service to an extremely intelligent, non-technical person with domain experience. This makes for code that is easy to understand, collaborate around, and modify given changing objectives.

That means creating "Policy" and especially "Service" models--extra nouns--very sparingly. For example, an Elevator was once a nounification of a verb, but people understood it, so it makes sense as a class. ElevatorDoor's good too, but ElevatorDoorOpeningService is probably not good. This is absolutely at odds with strict application of the Single Responsibility Principle.

[aculver]

The "Ubiquitous Language" is the label I've seen applied to the idea you're describing. For example: http://martinfowler.com/bliki/UbiquitousLanguage.html

This idea of having an ubiquitous domain language and keeping applications and APIs RESTful have been two of the most beneficial ideas I've incorporated into my development in recent years.