When talking about having a rich domain model successfully, in real applications, it needs to, somehow, access some abstraction of complex functionality (instead of being a row state calculator the way we see in most examples).
But, is there any problem in using abstract classes with polymorphic properties to do this, like this:
Interface and implementation
interface IPasswordHasher {
hashPassword(password: string): string;
}
class Sha256PasswordHasher implements IPasswordHasher {
hashPassword(password: string) {
return password;
}
}
Abstract class and implementation
abstract class AbstractAccount {
protected abstract passwordHasher: IPasswordHasher;
private _email: string;
get email() {
return this._email;
}
protected hashedPassword: string;
constructor() {}
login(email: string, password: string) {
this._email = email;
const hashedPassword = this.passwordHasher.hashPassword(password);
if (this.hashedPassword === hashedPassword) {
return true;
}
throw new Error("Invalid password");
}
register(email: string, password: string) {
this._email = email;
this.hashedPassword = this.passwordHasher.hashPassword(password);
}
}
class Sha256PasswordHasher implements IPasswordHasher {
hashPassword(password: string) {
return password;
}
}
class Account extends AbstractAccount {
passwordHasher = new Sha256PasswordHasher();
}
The only, drawback I saw in this is that domain models cannot consume other domain models directly (since they will be abstract), but this can be easily solved by declaring abstract factories Factories that return this other domain model.
Obs 1: By domain model, I'm not liming this question to how they are used in a DDD context, but I'm talking about the patterns that Martin Fowler defines as a pattern to isolate domain logic into objects that represent business entities.
Obs 2: Note that I'm not asking how to make domain models consume abstractions, but if there is a problem with this way of consuming them.