CODEWITHSUNDEEP
scala
user1052610
user1052610

Reputation: 4719

Modelling domain classes in scala

Our application requires a domain model with perhaps seventy or more fields. Many of the fields can logically be grouped together.

My initial idea is to use several case classes, and composition. For illustration:

case class UserEvents(e1:String, e2:String, e3:String, e4:String...)
case class UserPreferences(p1:String, p2:String, p3;String, p4:String ...)
case class UserHistory(hi:String, h2:String, h3:String, h4:String ...)
case class User(id:Int, name:String, ue:UserEvents, up:UserPreferences, uh:UserHistory)

Is this good design?

An alternative would be to model UserEvents, UserPreferences and UserHistory as traits, and have User extend those. Which approach would be better?

Also: I understand that in Scala, being a functional language, it is considered good practice to keep domain classes lean, and place the logic that acts upon the domain classes in separate objects (the anemic domain model). Is this correct?

Thanks

Upvotes: 2

Views: 653

Answers (1)

Paul Draper
Paul Draper

Reputation: 83245

Generally, Scala lacks opinions on best practices, and allows for many possible paradigms. It's a very flexible (Scalable) language.

An alternative would be to model UserEvents, UserPreferences and UserHistory as traits, and have User extend those. Which approach would be better?

In an OO-paradigm, you'd ask the question of whether the relationship was a has-a relationship (composition), or a is-a relationship (inheritance). But's that just OO-design.

The other question that could be asked is whether the relationship will be any different than 1:1. If so, you must use composition.

I typically prefer composition because I find it easier to understand, and there no diamond dependency problem, e.g. with generics.

Also: I understand that in Scala, being a functional language, it is considered good practice to keep domain classes lean, and place the logic that acts upon the domain classes in separate objects (the anemic domain model). Is this correct?

Again, it depends.

Scala makes it much easier to define data types than, say, Java. So a lot of people use this capability.

I prefer the anemic domain model, as I find separating data and logic helpful. But again, you won't get a canonical answer to this question.

Upvotes: 3

Related Questions