Should Repository be parameterised (object, id type)?

[lloydmeta]

Currently making my way through the book in detail (awesome btw), and I realised that in Chapter 5, AccountService is parameterised on Account, Amount, and Balance, which is awesome, but AccountRepository on which it depends is not; I was curious if it should be ?

frdomain/src/main/scala/frdomain/ch5/domain/service/AccountService.scala

Lines 17 to 35 in 48664c3

	trait AccountService[Account, Amount, Balance] {
	type AccountOperation[A] = Kleisli[Valid, AccountRepository, A]
	def open(no: String, name: String, rate: Option[BigDecimal], openingDate: Option[Date],
	accountType: AccountType): AccountOperation[Account]
	def close(no: String, closeDate: Option[Date]): AccountOperation[Account]
	def debit(no: String, amount: Amount): AccountOperation[Account]
	def credit(no: String, amount: Amount): AccountOperation[Account]
	def balance(no: String): AccountOperation[Balance]
	def transfer(from: String, to: String, amount: Amount): AccountOperation[(Account, Account)] = for {
	a <- debit(from, amount)
	b <- credit(to, amount)
	} yield ((a, b))
	}

frdomain/src/main/scala/frdomain/ch5/domain/repository/AccountRepository.scala

Lines 11 to 21 in 48664c3

	trait AccountRepository {
	def query(no: String): \/[NonEmptyList[String], Option[Account]]
	def store(a: Account): \/[NonEmptyList[String], Account]
	def balance(no: String): \/[NonEmptyList[String], Balance] = query(no) match {
	case \/-(Some(a)) => a.balance.right
	case \/-(None) => NonEmptyList(s"No account exists with no $no").left[Balance]
	case a @ -\/(_) => a
	}
	def query(openedOn: Date): \/[NonEmptyList[String], Seq[Account]]
	def all: \/[NonEmptyList[String], Seq[Account]]
	}

In effect, doesn't this mean that AccountService is coupled to the concrete models due to

frdomain/src/main/scala/frdomain/ch5/domain/service/AccountService.scala

Line 18 in 48664c3

type AccountOperation[A] = Kleisli[Valid, AccountRepository, A]

?

[debasishg]

Thanks for your comments ..

Regarding AccountRepository, it's not an implementation, it's a trait for which u can have multiple implementations. And the trait is injected into AccountService through a Kleisli, which is a ReaderT. So the repository is injected into the service from the environment - hence no coupling. And this is done at the end of the world when u implement the Application https://github.com/debasishg/frdomain/blob/master/src/main/scala/frdomain/ch5/domain/app/app.scala#L57) ..

[lloydmeta]

Right, but the algebra of the AccountRepository is hard-coded to use the concrete Account model

frdomain/src/main/scala/frdomain/ch5/domain/repository/AccountRepository.scala

Line 9 in 48664c3

import model.{ Account, Balance }

That in turn shows up in the algebra of the AccountService through the Kleisli

frdomain/src/main/scala/frdomain/ch5/domain/service/AccountService.scala

Line 21 in 48664c3

accountType: AccountType): AccountOperation[Account]

In other words, AccountService#open for instance is basically:

trait AccountService[Account /* this is parameterized, which is good */] { 
  def open(
    no: String,
    name: String,
    rate: Option[BigDecimal],
    openingDate: Option[Date],
    accountType: AccountType
  )(repository: { def store(a: models.Account /* here we leak the concrete Account model */): \/[NonEmptyList[String], Account] }): Valid[Account]
}

EDIT: My question essentially boils down to: if we're going through the trouble of parameterising AcocuntService on Account type, wouldn't it make sense to do so for the AccountRepository as well? As it is, it seems clear that the only kind of Account that could be used with AccountService is the concrete model.Account, same for Amount.

[debasishg]

ah .. I get what you say. You are correct! It would certainly be better to parameterize the algebra of repository with the domain entities as type parameters.