本文主要介绍了多应用层的问题,包括原因和实现.通过理解介绍了如何区分领域逻辑和应用逻辑,哪些是正确的实践,哪些是不推荐的或者错误的实践. 一.多应用层的问题 1.多应用层介绍   不知道你们是否会遇到一种情况,通过ABP构建了一个后端的API项目,刚开始是为Web端项目(比如,Vue)提供后端接口服务的,随着项目的发展和业务的复杂,增加了移动端的App,或者公众号.小程序等,这样不仅要为Web端提供API服务,而且还需要为移动端的App,或者公众号.小程序等提供API服务.这个场景就是多应用

在上一章节中,我们处理了MVC多级目录问题,参见<二.处理MVC多级目录问题——以ABP为基础架构的一个中等规模的OA开发日志>.从这章开始,我们将进入正式的开发过程.首先,我们要完成系统的基础设置模块(在后续的功能中,需要大量使用这些基础设置信息).和一般的OA系统不同,在律所OA系统中,用户类别管理是基础模块中非常重要.使用频率非常高的一个基础模块.虽然此功能只是很小的一个字典项设置,但是其中涉及了锁.并发处理.领域服务于应用服务的划分等繁琐问题. UI功能页面介绍(因用户功能未完成,欠缺

目录 如何运用DDD - 领域服务 概述 什么是领域服务 从实际场景下手 更贴近现实 领域服务VS应用服务 扩展上面的需求 最常见的认证授权是领域服务吗 使用领域服务 不要过多的使用领域服务 不要将过多的行为都给了领域服务 总结 小彩蛋 如何运用DDD - 领域服务 概述 本文将介绍领域驱动设计(DDD)战术模式中另一个非常重要的概念 - 领域服务.在前面两篇博文中,我们已经学习到了什么是值对象和实体,并且能够比较清晰的定位它们自身的行为.但是在某些时候,你会发现某一些业务行为好像不容易落到单个

返回总目录 本篇目录 介绍 IDomainService接口和DomainService类 样例 创建一个接口 服务实现 调用应用服务 一些讨论 何不只使用应用服务 如何强制使用领域服务 介绍 领域服务(或DDD中的服务)用于执行领域操作和业务规则.Eric Evans描述了一个好的服务应该具备下面三个特征: 和领域概念相关的操作不是一个实体或者值对象的本质部分. 接口定义在领域模型其他元素的条款中. 操作是无状态的. 跟获得或返回一个数据传输对象的应用服务方法(DTO)不同,领域服务获得或者返

ABP入门系列目录--学习Abp框架之实操演练 源码路径:Github-LearningMpaAbp 1.引言 自上次更新有一个多月了,发现越往下写,越不知如何去写.特别是当遇到DDD中一些概念术语的时候,尤其迷惑.如果只是简单的去介绍如何去使用ABP,我只需参照官方文档,实现到任务清单Demo中去就可以了,不劳神不费力.但是,这样就等于一知半解. 知之为知之,不知为不知,是知也.知其然知其所以然,方能举一反三嘛. 为了揭开迷惑,最近开始研读<实现领域驱动设计>去学习DDD中的思想,并开了一个

我在刚接触ABP的时候一直有一个疑问--有了应用服务,为什么还需要领域服务呢? 领域服务和应用服务对比 领域服务 应用服务 返回值 Entity DTO 被表现层调用 不可以(非强制) 可以 在ABP里面不是强制要使用领域服务的,但使用领域服务是个比较好的实践. 什么时候使用领域服务? 处理的是业务,而非场景(use-case) 要对Entity的状态修改加限制 举例 栗子 电商的商品扣除库存 假设我们写在应用层 定义以下应用服务: public interface IStockApplicat

DDD理论学习系列--案例及目录 1. 引言 单从字面理解,不管是领域服务还是应用服务,都是服务.而什么是服务?从SOA到微服务,它们所描述的服务都是一个宽泛的概念,我们可以理解为服务是行为的抽象.从前缀来看,根据DDD的经典分层架构,它们又隶属于不同的层,应用服务属于应用层,领域服务属于领域层. 应用层(Application):负责展现层与领域层之间的协调,协调业务对象来执行特定的应用程序任务.它不包含业务逻辑. 领域层(Domain):负责表达业务概念,业务状态信息以及业务规则,是业务软件

返回ABP系列 ABP是“ASP.NET Boilerplate Project (ASP.NET样板项目)”的简称. ASP.NET Boilerplate是一个用最佳实践和流行技术开发现代WEB应用程序的新起点,它旨在成为一个通用的WEB应用程序框架和项目模板. ABP的官方网站:http://www.aspnetboilerplate.com ABP官方文档:http://www.aspnetboilerplate.com/Pages/Documents Github上的开源项目:http

问答部分 问: 领域服务的职责是什么? 答: 夸聚合实例业务逻辑. 没办法合理放到实体中的其它业务逻辑. 问: 领域服务的设计原则是什么? 答: 用来组织业务逻辑. 面向业务逻辑. 细粒度. 内部视图看系统. 一个请求对应多个服务的多个方法. 服务之间会存在依赖. 问: 应用服务的职责是什么? 跨Bounded Context业务逻辑. DTO转换. 事务AOP.权限AOP.日志AOP.异常AOP. 外部系统访问:邮件.消息队列. 应用服务的设计原则是什么? 答: 用来封装业务逻辑. 面向用例.

应用服务&领域服务 DDD理论学习系列——案例及目录 1. 引言 单从字面理解,不管是领域服务还是应用服务,都是服务.而什么是服务?从SOA到微服务,它们所描述的服务都是一个宽泛的概念,我们可以理解为服务是行为的抽象.从前缀来看,根据DDD的经典分层架构,它们又隶属于不同的层,应用服务属于应用层,领域服务属于领域层. 应用层(Application):负责展现层与领域层之间的协调,协调业务对象来执行特定的应用程序任务.它不包含业务逻辑. 领域层(Domain):负责表达业务概念,业务状态信息以及

Tips:本篇已加入系列文章阅读目录,可点击查看更多相关文章. 目录 前言 开始 聚合根 仓储 领域服务 BLOB存储 应用服务 单元测试 模块引用 最后 前言 在前两节中介绍了ABP模块开发的基本步骤,试着实现了一个简单的文件管理模块:功能很简单,就是基于本地文件系统来完成文件的读写操作,数据也并没有保存到数据库,所以之前只简单使用了应用服务,并没有用到领域层.而在DDD中领域层是非常重要的一层,其中包含了实体,聚合根,领域服务,仓储等等,复杂的业务逻辑也应该在领域层来实现.本篇来完善一下文件

目录 系列文章 领域服务 应用服务 学习帮助 系列文章 基于ABP落地领域驱动设计-00.目录和前言 基于ABP落地领域驱动设计-01.全景图 基于ABP落地领域驱动设计-02.聚合和聚合根的最佳实践和原则 基于ABP落地领域驱动设计-03.仓储和规约最佳实践和原则 基于ABP落地领域驱动设计-04.领域服务和应用服务的最佳实践和原则 基于ABP落地领域驱动设计-05.实体创建和更新最佳实践 基于ABP落地领域驱动设计-06.正确区分领域逻辑和应用逻辑 围绕DDD和ABP Framework两个

1.DDD领域驱动设计实践篇之如何提取模型 2.DDD领域驱动设计之聚合.实体.值对象 3.DDD领域驱动设计之领域基础设施层 什么是领域服务,DDD书中是说,有些类或者方法,放实体A也不好,放实体B也不好,因为很可能会涉及多个实体或者聚合的交互(也可能是多个相同类型的实体),此时就应该吧这些代码放到领域服务中,领域服务其实就跟传统三层的BLL很相似,只有方法没有属性,也就没有状态,而且最好是用动词命名,service为后缀,但是真正到了实践的时候,很多时候是很难区分是领域实体本身实现还是用领域

前言:之前一直在搭建项目架构的代码,有点偏离我们的主题(DDD)了,这篇我们继续来聊聊DDD里面另一个比较重要的知识点:领域服务.关于领域服务的使用,书中也介绍得比较晦涩,在此就根据博主自己的理解谈谈这个知识点的使用. DDD领域驱动设计初探系列文章: C#进阶系列——DDD领域驱动设计初探(一):聚合 C#进阶系列——DDD领域驱动设计初探(二):仓储Repository(上) C#进阶系列——DDD领域驱动设计初探(三):仓储Repository(下) C#进阶系列——DDD领域驱动设计初探

CZ 能不能清晰具体区分service和实体的区别 网上有人用DCI来解决 不知道对不对 STST 我复习下DDD中的服务的概念了参与讨论啊CZ 这个我也看过 但是太过于笼统 STST STST 复习了一遍,我是这么理解的 STST 假设一个道路模拟系统,里面有两个重要概念,汽车,加油站 汽车有一个职责叫: void 加油(int capacity) 加油站有一个职责叫:int 供油(int maxCapacity) 那么汽车行驶过程中需要加油了,怎么办,这就需要协调加油站和汽车两个领域概念 需

前言:之前一直在搭建项目架构的代码,有点偏离我们的主题(DDD)了,这篇我们继续来聊聊DDD里面另一个比较重要的知识点:领域服务.关于领域服务的使用,书中也介绍得比较晦涩,在此就根据博主自己的理解谈谈这个知识点的使用. DDD领域驱动设计初探系列文章: C#进阶系列——DDD领域驱动设计初探(一):聚合 C#进阶系列——DDD领域驱动设计初探(二):仓储Repository(上) C#进阶系列——DDD领域驱动设计初探(三):仓储Repository(下) C#进阶系列——DDD领域驱动设计初探

前言 领域驱动模型设计在业界也喊了几年口号了,但是对于很多"务实"的程序员来说,纸上谈"术"远比敲代码难得太多太多.本人能力有限,在拜读相关作品时既要隐忍书中晦涩难懂的专业名词,又要去迎合西方大牛在撰写的过程中融入的西式故事.我想总会有一部分水平和我类似的码农们,需要一份对系统阐述DDD小白文化的文本.因此,本人便自不量力地结合一些简单的项目经验,将领域驱动模型设计思想从理解到落地的实施和总结分享给诸位.当然,如果是某些行业先锋不幸看到本人稚嫩的文字时,就当作是马戏

文档目录 本节内容: 简介 例子 创建一个接口 实现服务 使用应用服务 相关论述 为什么不只用应用服务? 如何强制你使用领域服务? 简介 领域服务(或服务)用来执行领域操作和业务规则.Eric Evans描述一个好的服务需要三个特点(在他的DDD书里): 操作与领域概念(不是一个实体或值对象天生的一部分)相关. 接口要按照领域模型的其它元素来定义. 操作是无状态的. 与应用服务获取/返回DTO(数据传输对象)不同,领域服务获取/返回领域对象(如实体或值类型). 领域服务可被应用服务或其它领域服务

领域服务 介绍 IDomainService接口和DomainService类 示例 创建接口 服务实现 使用应用服务 一些探讨 为什么只有应用服务? 如何强制使用领域服务? 介绍 领域服务(或者在DDD中单纯的服务)用来执行领域操作和业务规则.Eric Evans在他的DDD书中描述了一个好的服务有三个特征: 1. 与领域概念关联的操作,但不是实体或值对象的自然组成部分. 2. 接口的定义依照领域模型的其他元素. 3. 操作是无状态的. 不像应用服务那样获取或返回DTO,领域服务获取或返回领域

背景 名词解释 如果你的团队目前正是构建微服务架构风格的软件系统,问自己两个问题? 软件架构演进 软件架构大致经历了从单机架构,集中式架构,分布式微服架构,程序的层次图如下所示. 单机架构 特点如下: 1, 面向过程的设计方法: 2, 结构为CS: 3,程序的层次分两层,即UI层和数据库层: 4, 设计的核心在数据库和字段. 集中式架构 特点如下: 1, 面向对象的设计方法: 2,程序层次为经典的3层架构,即业务接入层, 业务逻辑层,数据库层: 3,部分企业也采用SOA架构风格: 4,集中式的架

图中是暗黑领域,非常牛逼的技能. 背景 DDD中出现的名词: 领域,子领域,核心域,通用域,支撑域,限界上下文,聚合,聚合根,实体,值对象 都是关键概念,但是又比较晦涩,在开始DDD之前,搞清楚这些关键概念名词非常的重要. 那它们作用体现在哪里呢? 领域-子领域 领域是: 从事专门活动或者事业的范围.  领域的作用是:确定范围和边界 DDD研究和解决业务问题过程如下: DDD中的领域是:边界中要解决的业务问题域 领域就是范围,范围有大小之分,所以,DDD中大范围的叫领域,小范围的叫子领域: DD