Case class design in Scala
I believe that in addition to the stated Java -> Scala OO question, that you may also be wondering about a good way to "organize" Models/DAOs/Controllers in Play 2. So I will incorporate that in my answer.

I would have asked in a comment, but I don't seem to have the rep yet...

A few notes before we get into an answer:


fedesilvia is correct, that case classes can extend traits and/or classes.
Model classes generally should be case classes. They're a nice, easy-to-use construct that provides your "equals" method, "toString" method, and "hashcode" method. Also, many libraries have provided great mechanisms for working with case classes for a variety of purposes. Not to mention matching, immutable by default, etc...


Let's take a look at how to organize this from top to bottom.

Controllers

As you know, Play's Router sends requests in from the HTTP client to your Controller. It is my opinion that the Controllers then have 3 core responsibilities:


Deserialize the request.
Serialize the response.
Handle any errors appropriately.


Missing between responsibilities 1 and 2, is the actual "handling" of the request. For a CRUD app, this could be where your DAOs come in.

DAOs

In my application, DAOs are Objects that extend a MongoDAO trait. The trait "knows" how to interact the the database drivers (get a connection), and supplies basic utilities. For instance:

/** Basic DAO Behavior for MongoDB documents. */
trait MongoDao {
  /** Name of the MongoDB Collection. */
  protected def colName: String

  /** Returns the default database. */
  protected def db = ReactiveMongoPlugin.db

  /** The actual collection used by the DAO. */
  protected def col: JSONCollection =
    db.collection[JSONCollection](colName)

  /** Returns the first result, if any, for the given query. */
  def findOne[DOC](q: JsObject)(implicit reads: Reads[DOC]) =
    col.find(q).cursor[DOC].headOption

  ...


I also have an abstract class that extends MongoDAO called, "AssetDAO". AssetDao provides 90% to 100% of the DAO implementation for 13 of the Models in my App. Here is it's type:

/** Common DAO behavior for all Assets. */
abstract class AssetDao[A &lt;: AssetModel]
  (override val colName: String)(implicit format: Format[A])
extends MongoDao with ModulePermissions {


The DAO implementations can look like this:

object ArchetypeDao extends AssetDao[Archetype]("archetypes")


But most of them also have a couple methods that are all their own. Usually when I need to make use of Model specific properties in a query.

Model Companion Objects

Given the libraries that I'm using (notably play.api.lib.json), I find it best to put (de-)serialization code in the Companion Objects. For instance:

object Archetype {
  /** Converts Archetype to/from its MongoDB representation */
  implicit val fmt = Json.format[Archetype]

  /** Reads that are used for both Create and Update. */
  val coreReads = (
    (__ \ "name"   ).json.pickBranch(smlReqStr) and
    (__ \ "summary").json.pickBranch(medReqStr) and

    ((__ \ "description").json.pickBranch(fullText) or emptyObj)
  ) reduce
}


As you can see, the Companion Object contains all of the information it needs to (de-)serialize the case class to/from its MongoDB representation; and to/from its "client" representation. So the DAO ends up using the Json.format and the Controller uses the JSON Transformers.

Models

In this setup, all Models are simple case classes that represent persisted data. For instance:

case class Archetype (
  _id:         BSONObjectID,
  module_id:   BSONObjectID,
  doc_meta:    DocMeta,
  name:        String,
  summary:     String,
  description: Option[String]
) extends AssetModel


And here is the AssetModel trait that Archetype implements:

/** Describes some common behavior of asset types */
trait AssetModel {
  def _id:       BSONObjectID
  def module_id: BSONObjectID
  def doc_meta:  DocMeta
}


You may have noticed earlier that Archetype.coreReads doesn't reference all the fields the model has. That's because the "AssetControllers" are taking care of the rest of the fields for every AssetModel. Implementing AssetModel here is what makes that work.

To do it again, I might have the AssetModel Companion Objects extend a trait that provides the common field (de)serialization.

Conclusion

Hopefully, this answer has provided you with:


A better understanding of using OO in Scala.
Some ideas for organizing your Play App to write DRY code.