在清洁架构中设计实体的最佳实践是什么？

Question

我试图使用Kotlin实现干净的架构。这一过程的流程将是：

usecase-->从DB获取rowresult-->将rowresult映射到实体-->usecase用于检查业务规则的实体

代码示例：

UserTable
------------------
id (varchar)
email (varchar)
password (varchar)
gender (varchar)
phone (varchar)
anotherAttribute1
anotherAttribute2
.
anotherAttributeN

class UserEntity {
    val id: String,
    val email: String,
    val password: String,
    //Business rules
    fun isUserAllowedToLogin(): Boolean {
        //validate password
    }
}

interface UserDataStore {
    fun getUser(email: String): User
}

class UserDataStoreImplementation {
    fun getUser(email: String): User {
        //query to DB
        val resultRow = db.query("SELECT id, email, password from UserTable where email=${email}")
        //map to UserEntity
        val user: UserEntity = Mapper.toUserEntity(userResultRow)
        return user
    }
}

class LoginUseCase {
    fun execute(emailInput: String, passwordInput: String): Boolean {
        val user = UserDataStore().getUser(emailInput)
        if (!user.isUserAllowedToLogin) {
            //do something
        }
        return result
    }
}

class UserEntity {
    val id: String,
    val email: String,
    val password: String,
    val gender: String,
    val phone: String,
    //more attributes
    .
    .
    //more complex object
    val Staff: Staff
    fun isUserAllowedToLogin(): Boolean {
        //validate password
    }
    fun checkStaffStatus(): Boolean {
        //do something
    }
}

class UserDataStoreImplementation {
    fun getUser(email: String): User {
        //query from DB which will have a lot of attributes
        val resultRow = db.query("SELECT * from UserTable where email=${email}")
        //map to UserEntity
        val user: UserEntity = Mapper.toUserEntity(userResultRow)
    }
}

Answer 1

问题1。假设我有另一个UseCase（GetUserFullDetailAndStaffDetail UseCase）将使用更复杂的用户属性，我是否应该为GetUserFullDetailAndStaffDetail UseCase使用相同的UserEntity？

实体是域对象，LoginUser与UserDetail不同。我们经常认为只有一个用户。但是用户有不同的视角。你可以把它们看作是一种角色。

public class LoginUser {
  private String name;
  private String email;

  // ...
}

或DetailUser。

public class DetailUser {
  private String name;
  private String email;
  private String phone; 
  private String gender;
  // ...
}

这并不违反干燥原则，因为你不重复自己。我同意我们必须消除重复的代码，但是LoginUser和DetailUser会因为不同的原因而改变。因此它们不会重复。这就是唯一的责任。

它们看起来相似，但相似只是重复的暗示。你得问自己更多的问题，看看它们是否真的是重复的。让我们考虑一下对登录用例的更改。也许只应该显示名字。那么这两个实体将只有一个共同的属性--名称。他们在commen中必须有多少属性才能复制？

如果在实体中实现业务逻辑，您将意识到有些方法只能在两个用例中的一个中调用，并且这些方法只使用属性的子集。然后你会看到这两个实体是不同的。

如果您只对所有用例使用一个存储库接口，您将很快意识到它将不断增长，直到包含数十个方法。最后，这一个界面将变得混乱。有些方法相似，但不同，你会试图找到疯狂的名字来区分他们。

public interface UserRepository {
 
   public User findSimpleUser();

   public User findAllUserInfo();

   public User findAllUserInfoForOrderProcess();

   // ... maybe dozens more
}

实现类将很大。也许很多方法是通过私有实用程序方法耦合的，因此对该共享代码的更改会影响其他用例，等等。

将接口分开是个好主意。也许您从不同的接口开始，但只有一个实现来实现这两个接口。也许您想在以后情况变得更糟时分解实现。但是，您已经有了分离的接口，您不必改变您的用例。