到目前为止,很容易。如果我们试图将规范应用到存储库,而又不破坏DDD模式或存在性能问题,那么问题就会出现。
应用规范的可能方法:
1)经典方法:在领域层使用领域模型进行规范
3)与2)类似,但将规范作为持久层的一部分
4)与3类似,但使用抽象规范作为接口
最后一种方法是创建某种查询API,它被传递到规范中,存储库/持久性层将从它生成一个表达式树,以传递给.where
子句,它使用一个接口来声明所有可筛选的字段。
我也朝这个方向做了几次尝试,但对结果不太满意。类似于
public interface IQuery<T>
{
IQuery<T> Where(Expression<Func<T, T>> predicate);
}
public interface IQueryFilter<TFilter>
{
TFilter And(TFilter other);
TFilter Or(TFilter other);
TFilter Not(TFilter other);
}
public interface IQueryField<TSource, IQueryFilter>
{
IQueryFilter Equal(TSource other);
IQueryFilter GreaterThan(TSource other);
IQueryFilter Greater(TSource other);
IQueryFilter LesserThan(TSource other);
IQueryFilter Lesser(TSource other);
}
public interface IPersonQueryFilter : IQueryFilter<IPersonQueryFilter>
{
IQueryField<int, IPersonQueryFilter> ID { get; }
IQueryField<string, IPersonQueryFilter> Name { get; }
IQueryField<int, IPersonQueryFilter> Age { get; }
}
在规范中,我们将把IQuery
传递给规范构造函数,然后在使用或组合它时将规范应用于它。
IQuery<IGridQueryFilter> query = null;
query.Where(f => f.Name.Equal("Bob") );
有没有任何框架可以用两种方法之一(查询生成器类似于表达式树的语法或表达式树翻译器)来解决上述问题?
我认为规范模式不是为查询条件设计的。实际上,DDD的整个概念也不是。如果有过多的查询需求,请考虑CQRS。
规范模式有助于开发无处不在的语言,我认为它就像一种DSL。它声明的是做什么而不是如何做。例如,在订购上下文中,如果下单但未在30分钟内支付,则订单被视为过期。使用规范模式,您的团队可以使用一个简短但唯一的术语:OverdueOrderSpecification进行对话。想象一下下面的讨论:
案例-1
Business people: I want to find out all overdue orders and ...
Developer: I can do that, it is easy to find all satisfying orders with an overdue order specification and..
Business people: I want to find out all orders which were placed before 30 minutes and still unpaid...
Developer: I can do that, it is easy to filter order from tbl_order where placed_at is less that 30minutes before sysdate....
class OrderMonitorApplication {
public void alarm() {
// The specification pattern keeps the overdue order ubiquitous language in domain
List<Order> overdueOrders = orderRepository.findBy(new OverdueSpecification());
for (Order order: overdueOrders) {
//notify admin
}
}
}
class HibernateOrderRepository implements orderRepository {
public List<Order> findBy(OrderSpecification spec) {
criteria.le("whenPlaced", spec.placedBefore())//returns sysdate - 30
criteria.eq("status", spec.status());//returns WAIT_PAYMENT
return ...
}
}
我正在学习DDD概念,为了加强我的理解,我正在研究一些现实世界的例子。 我知道一个聚合应该只有一个通过根实体的入口点,一个聚合应该只有一个存储库(如果我完全理解错了,请纠正我) 现在假设有特定类型的消耗品,并且这些消耗品是从配送中心发送的。发送特定类型的消耗品取决于它们的数量,我的意思是,如果其中一个消费者对A型和B型的临界数量为10,并且这些项目的数量低于10,那么配送中心发送A型和B型消耗品。
本文向大家介绍谈一下领域驱动设计相关面试题,主要包含被问及谈一下领域驱动设计时的应答技巧和注意事项,需要的朋友参考一下 主要关注核心领域逻辑。基于领域的模型检测复杂设计。这涉及与公司层面领域方面的专家定期合作,以解决与领域相关的问题并改进应用程序的模型。在回答这个微服务面试问题时,您还需要提及DDD的核心基础知识。他们是: DDD主要关注领域逻辑和领域本身。 复杂的设计完全基于领域的模型。 为了改
本文向大家介绍什么是领域驱动设计(DDD)相关面试题,主要包含被问及什么是领域驱动设计(DDD)时的应答技巧和注意事项,需要的朋友参考一下 专注于核心领域逻辑 在模型上找到综合的设计 不断与领域专家合作,改进应用程序模型并解决与领域相关的问题
Eric Evans在DDD中谈了很多关于模型进化的话题,所以重构似乎对DDD是必不可少的。当一个人拥有世界的关系持久化状态时,可以通过迁移来处理模型更改,从而更改数据库模式。 使用事件源时,如何应对模型更改?如果对聚合有不兼容的更改,这将阻止事件的重播,是否有某种最佳实践?还是只是不要?
3.8 ABP领域层 - 规约模式 3.8.1 简介 规约模式 是一种特别的软件设计模式,通过链接业务规则与使用boolean逻辑来重组业务规则。 实际上,它主要是用来对实体和其它业务对象构造可重用的过滤器。 3.8.2 示例 在这节,我们会了解到规约模式的必要性。这节中说到的都是通用的与ABP的实现无关。 假设有个统计客户数量的方法;如下所示: public class CustomerMana
了解如何在 XD 中使用设计规范。 在 XD 中使用设计规范可为设计人员和开发人员的工作流程带来突破性改变。设计规范旨在节省时间、简化设计人员与开发人员之间的沟通、加快工作流程并为双方带来便利,它毫无疑问是 XD 中的一项实用功能。 现在,只需单击一个简单的 URL 即可访问设计规范。优势不止于此:您可以获得完全控制,能够选择您的代码所需的文件格式和分辨率。您还可以查看用户体验工作流程,从而更深入