1 回答
TA贡献1775条经验 获得超8个赞
我认为您问题的答案首先取决于另一个问题:
这些状态在您的领域中有多重要?
这里重要的是在设计中考虑领域文献(又名无处不在的语言)。但实施细节实际上取决于问题的重要性。他们甚至可以是独立的实体!
entity.To(new ApprovedState());
如果状态转换只是一个标志数据,那么您在此处提供的第一个实现可能就足够了,但如果它更重要并且有更多的业务规则围绕它,您可以使用第二个实现,或者像 State 或 Strategy 这样的模式。
interface IState{...}
class Approved : IState {...}
class Requested : IState {...}
class Entity{
public IState State {get; set;}
}
最后你可以提供一层薄薄的 fluent API 来更精细地表达你的领域(当然你也可以这样设计......):
TheEntity.IfItsPossible().Approve();
更新
这里还有一件事。有时我们向实体添加字段,就像我们对数据库中的表执行相同操作一样。这就是数据库世界的工作方式!但我认为这在 DDD 中完全不同。也许这些不同的状态实际上扮演着不同实体的角色或隐藏的业务规则,需要深入挖掘。假设Request不是 Reload 实体的状态,而是人们在需要 Reload 时创建的实体。就像您在需要购买产品时创建订单一样。
public class Reload
{
}
public class Request
{
public string User { get; set; }
public DateTime Time { get; set; }
// and other logics about requests
}
public interface IFactory
{
Reload Create(Request request);
}
如果这真的是域中发生的事情,那么这些状态只不过是其他实体和域服务的内部工作的结果。例如,标准化状态就是我们所说的在队列中等待处理的重新加载,您可以从应用程序的模块中查询这些信息:
public interface IQueueService
{
void Push(Reload reload);
}
public IEnumerable<Reload> GetStandardizedReloads()
{
return _queueService.Items();
}
public IEnumerable<Request> GetRequests()
{
return _requestRepository.GetAll();
}
- 1 回答
- 0 关注
- 294 浏览
添加回答
举报