ddd

首先，描述一下我的业务场景及项目分层结构，非标准DDD(其实我不觉得有标准)，只是思考的时候有带入DDD思想。 业务场景： 这是一个ERP系统对中台提供的接口项目，仓储操作大多都是存储过程去完成的。 项目结构，如图： WebAPI层： 这个不用多说了，入口。 DTO层： 增加数据传入传出对象，和领域model、实体model区分。（要不要围绕领域model或从现有系统中提取领域model看实际业务情况，拿我目前这个项目来说，得不偿失。） Services层： 业务服务层（可以命名成BizServices区分），主要写一些业务逻辑，然后调用领域服务层DomainServices（如果有的话），如果没有，则直接调用仓储服务，进行持久化操作。 Repository层 ： 打算用dapper进行持久化操作，对外提供RepositoryService。我这里比较特殊，下面讲。 融合了一部分DDD思想后，项目结构和流程本来应该是这样 ： Request→WebAPI→DTO→BizServices→DomainServices→RepositoryService→DTO→Response。 一个Request对应一个BizServices可能对应多个DomainServices可能对应多个RepositoryService 实际是这样的 ： Request→WebAPI→DTO

后台传参时，应该传递如下的文件路径 方式一： D:\GeneralFoldersSoftInstall----------->D:\\GeneralFoldersSoftInstall 方式二： D:\GeneralFoldersSoftInstall----------->D:/GeneralFoldersSoftInstall 因为在接口中拼接这样的参数时，单个‘\’会被当作转义字符，而不会当作反斜杠。 后台传递的接口存在中文时，会被编码加密，而不是错误。 如en/ddd/fileName=中国.zip---------->en/ddd/fileName=xxxx.zip xxxx 来源： https://www.cnblogs.com/LYD312/p/12031589.html

目录 如何运用DDD - 领域服务 概述 什么是领域服务 从实际场景下手 更贴近现实 领域服务VS应用服务 扩展上面的需求 最常见的认证授权是领域服务吗 使用领域服务 不要过多的使用领域服务 不要将过多的行为都给了领域服务 总结 小彩蛋 如何运用DDD - 领域服务 概述 本文将介绍领域驱动设计（DDD）战术模式中另一个非常重要的概念 - 领域服务。在前面两篇博文中，我们已经学习到了什么是值对象和实体，并且能够比较清晰的定位它们自身的行为。但是在某些时候，你会发现某一些业务行为好像不容易落到单个实体或者值对象身上，并且会为放置这一部分业务逻辑而困惑。此时，你可能需要一个领域服务来完成操作。 那么，到底什么是领域服务呢？怎么发现领域中的领域服务呢？领域服务和传统的应用服务又有什么区别呢？本文将从不同的角度来带大家重新认识一下“领域服务”这个概念，并且给出相应的代码片段（本教程的代码片段都使用的是 C# ,后期的实战项目也是基于 DotNet Core 平台）。 什么是领域服务 在开始之前，还是说一点题外话吧：如果大家读过这个系列的前几篇文章，可能都会发现该系列的风格都是从原著的解析开始，然后结合了自身的一些案例和实际场景来为大家解读领域驱动中的一些概念。我也不知道这样的写作方式能不能让大家更清楚的理解，所以如果大家有什么建议的话可以在评论区留言，我一定会认真的听取大家的意见和建议。

什么是DDD？ ddd不是一种架构风格，而是一种方法论，什么是方法论，每个人按照自己的想法来设计就是一套方法论；ddd是一种业务比较认可，对于微服务拆分的一种方法论。 为什么在微服务的大环境下DDD才流行？ 微服务区别于系统，服务是一组想对较小且独立功能单元，是用户感知最小功能集。DDD计的模型中具有边界的最小原子是聚合，聚合和聚合之间由于只通过聚合根进行关联，所以当需要把一个聚合根从一个限界上下文移动到另外一个限界上下文的时候，非常低的移动成本可以很容易地对微服务进行重构。微服务和ddd的理念不谋而合，在微服务的大环境下ddd的流行是趋势。 为什么很多行业在微服务的架构上还是MVC架构？ 固化思维，从学校到工作，从学习到开源架构都是采取这种MVC架构； 很多行业是基于传统行业进行项目改造，只是中间件用了微服务相关，但是业务没有明显的拆分依据，换汤不换药； 资源成本，基于ddd的拆分成本比较高，主要体现在事件风暴、领域划分、实体聚合，上下文边界确定；对于企业来说，一个人能搞定的，不需要花大量的人力，时间去做规划； 三层架构属于贫血模型，虽然不符合面向对象编程思想，架构结构比较简单，上手容易。 从技术上来讲DDD和MVC有什么区别？ MVC和DDD主要的区别在Service层，主要区别： MVC：Service 实现全量业务逻辑，BO（Business Object）保存业务对象

<h2>创建视图交互</h2> <p>图形用户界面只是创建自定义视图的一部分。您还需要使视图以模仿现实世界行动相似的方式响应用户输入。对象始终应像真正对象做的一样。例如，图像应不立即弹出并重现在某个地方别的地方，因为在现实世界中的对象不会这样做。相反，图像应从一个位置移动到另一个位置。</p> <p>用户也感觉到细微的行为或界面上响应最佳模仿现实世界中的细微之处。例如，当用户甩动一个 UI 对象，他们应该感觉动作继续，摩擦然后在最终停止，最后的位置超出甩动发生时的位置。</p> <p>这节课演示如何使用 Android 框架的功能，将这些真实世界的行为添加到您的自定义视图。</p> <h3>处理输入的手势</h3> <p>像许多其他 UI 框架，android 系统支持输入的事件模型。用户操作都变成触发回调的事件，您可以重写自定义您的应用程序如何响应用户的回调。在 Android 系统中最常见的输入的事件是触摸，而触发 <a href="http://developer.android.com/reference/android/view/View.html#onTouchEvent(android.view.MotionEvent)" target="_blank">onTouchEvent(android.view.MotionEvent)</a>。重写此方法以处理事件：</p

from: https://blog.csdn.net/ityouknow/article/details/81572072 领域驱动设计的概念 大家都知道软件开发不是一蹴而就的事情，我们不可能在不了解产品(或行业领域)的前提下进行软件开发，在开发前通常需要进行大量的业务知识梳理，然后才能到软件设计的层面，最后才是开发。而在业务知识梳理的过程中，必然会形成某个领域知识，根据领域知识来一步步驱动软件设计，就是领域驱动设计(DDD,Domain-Driven Design)的基本概念 。 为什么需要 DDD 在业务初期，功能大都非常简单，普通的 CRUD 就基本能满足要求，此时系统是清晰的。但随着产品的不断迭代和演化，业务逻辑变得越来越复杂，我们的系统也越来越冗杂。各个模块之间彼此关联，甚至到后期连相应的开发者都很难说清模块的具体功能和意图到底是啥。这就会导致在想要修改一个功能时，要追溯到这个功能需要修改的点就要很长时间，更别提修改带来的不可预知的影响面。 比如下图所示: 订单服务中提供了查询、创建订单相关的接口，也提供了订单评价、支付的接口。同时订单表是个大表，包含了非常多字段。我们在维护代码时，将会导致牵一发而动全身，很可能原本我们只是想改下评价相关的功能，却影响到了创建订单的核心流程。虽然我们可以通过测试来保证功能的完备性

目录 如何运用DDD - 实体 概述 何为实体 似曾相识 你确定它真的需要ID吗 运用实体 结合值对象 为实体赋予它的行为 尝试转移一部分行为给值对象 愿景是美好的 现实是残酷的 总结 如何运用DDD - 实体 概述 本文将介绍领域驱动设计（DDD）战术模式中另一个常见且非常重要的概念 - 实体。相对战术模式中其他的一些概念（例如 值对象、领域服务等）来说，实体应该比较容易让人理解和运用。但是我们如何去发现所在领域中的实体呢？如何保证建立的实体是富含行为的？实体运用时又有那些注意的细节呢？本文将从不同的角度来带大家重新认识一下“实体”这个概念，并且给出相应的代码片段（本教程的代码片段都使用的是 C# ,后期的实战项目也是基于 DotNet Core 平台）。 何为实体 按照国际惯例呢，我们先吹牛。直接来看看原著 《领域驱动设计:软件核心复杂性应对之道》 中对实体的解释： 实体(Entity，又称为Reference Object) 很多对象不是通过他们的属性定义的，而是通过一连串的连续事件和标识定义的。 主要由标识定义的对象被称为ENTITY。 上面的两句话多读了几遍，好像这个定义还是能够理解嘛。不像上一篇文章 如何运用DDD - 值对象 中的概念那么深奥。说白了，上面就是说明了一个问题，只要你所发现的事物/对象有一个唯一的标识，那么它可能就是实体了

1、引言 Module，即模块，是指提供特定功能的相对独立的单元。提到模块，你肯定就会想到模块化设计思想，也就是功能的分解和组合。对于简单问题，可以直接构建单一模块的程序。而对于复杂问题，则可以先创建若干个较小的模块，然后将它们组装、链接在一起，从而构成复杂的软件系统。 在DDD中，模块的用途也是如此，通过分解领域模型为不同的模块，以降低领域模型的复杂性，提高领域模型的可读性。 二、DDD中的模块 模块是一个笼统的概念，比较宽泛，为了正确发挥模块的威力，理解模块的概念就十分重要。下面我们从具体的问题着手，来尝试说明模块的概念。 就拿电商系统来说，维护一个订单，需要收货地址、购买商品、订单信息。这些信息是紧密相关的，不可独立存在。我们可以抽象出三个简单的聚合。那这些类该如何存放呢？是为每一个聚合创建一个文件夹存放还是放在同一个文件夹？我想答案不言而喻。 这三个聚合就是一个模块，一个客户模块。通过定义一个order文件夹，来将相关联的领域对象组合起来。 通过以上的举例说明，我们可以看到每个模块都是相对独立的功能单元。通过模块来组织和封装相关概念，来分解领域模型，以简化领域模型的复杂性。 但不要将模块与子域和限界上下文混淆。在复杂的领域模型中，为了对领域模型中进行准确建模，需要将领域模型拆分成多个子域，每个子域对应一个或多个限界上下文。在限界上下文中

http://www.fanyilun.me/2018/04/08/%E8%B0%88%E8%B0%88%E9%A2%86%E5%9F%9F%E5%BB%BA%E6%A8%A1/ http://www.uml.org.cn/mxdx/201409034.asp https://www.jianshu.com/p/b6ec06d6b594 来源： https://www.cnblogs.com/shengulong/p/11954996.html

目录 DDD实战与进阶 - 值对象 概述 何为值对象 怎么运用值对象 来看一个例子 值对象的持久化 总结 DDD实战与进阶 - 值对象 概述 作为领域驱动设计战术模式中最为核心的一个部分-值对象。一直是被大多数愿意尝试或者正在使用DDD的开发者提及最多的概念之一。但是在学习过程中，大家会因为受到传统开发模式的影响，往往很难去运用值对象这一概念，以及在对值对象进行持久化时感到非常的迷惑。本篇文章会从值对象的概念出发，解释什么是值对象以及怎么运用值对象，并且给出相应的代码片段（本教程的代码片段都使用的是 C# ,后期的实战项目也是基于 DotNet Core 平台）。 何为值对象 首先让我们来看一看原著 《领域驱动设计:软件核心复杂性应对之道》 对值对象的解释： 很多对象没有概念上的表示，他们描述了一个事务的某种特征。 用于描述领域的某个方面而本身没有概念表示的对象称为Value Object（值对象）。 此时作者是这样的： 而我们是这样的： 然后作者用“地址”这一概念给大家扩充了一下什么是值对象，我们应该怎么去发现值对象。所以你会发现现在很多的DDD文章中都是用这个例子给大家来解释。当然读懂了的人就会有一种醍醐灌顶的感觉，而像我这种菜鸡，以后运用的时候感觉除了地址这个东西会给他抽象出来之外，其他的还是该咋乱写咋写。 For Example ： public class