DDD

DDD 领域驱动设计 (Domain-Driven Design，简称 DDD） Domain Layer 领域层 - 业务实体, 值对象, 领域服务 Infrastructure Layer 基础设施层 - 数据访问, 外部服务调用等技术实现 Application Layer 应用层 - 协调领域对象来执行应用用例 Interface Layer 接口层 - API 控制器, 视图 值对象 (Value Objects) 实体对象 (Entity) Repository 模式 - 抽象的数据访问层 聚合根 Factory 模式 Domain Service 值对象 (Value Objects) 代表领域中没有身份标识但有重要意义的概念 不可变性 (Immutability), 一旦创建，不能修改, 只读属性 基于值的相等性 (Value-based Equality), 比较的是值，不是对象引用 无身份标识 (No Identity), 两个值相同的对象被认为是相等的 可哈希性 (Hashable) 生命周期 短暂，可替换 封装业务逻辑: 比如某些固定规则的字符串组合 值对象的使用场景: 复合标识符 实体对象 (Entity) 有唯一身份ID ...

无状态服务, stateless service https://blog.csdn.net/xiangxizhishi/article/details/79434749 一、定义 无状态服务（stateless service）对单次请求的处理，不依赖其他请求，也就是说，处理一次请求所需的全部信息，要么都包含在这个请求里，要么可以从外部获取到（比如说数据库），服务器本身不存储任何信息 有状态服务（stateful service）则相反，它会在自身保存一些数据，先后的请求是有关联的 二、优劣 有状态服务常常用于实现事务（并不是唯一办法，下文有另外的方案）。举一个常见的例子，在商城里购买一件商品。需要经过放入购物车、确认订单、付款等多个步骤。由于HTTP协议本身是无状态的，所以为了实现有状态服务，就需要通过一些额外的方案。比如最常见的session，将用户挑选的商品（购物车），保存到session中，当付款的时候，再从购物车里取出商品信息 有状态服务可以很容易地实现事务，所以也是有价值的。但是经常听到一种说法，即server要设计为无状态的，这主要是从可伸缩性来考虑的。如果server是无状态的，那么对于客户端来说，就可以将请求发送到任意一台server上，然后就可以通过负载均衡等手段，实现水平扩展。如果server是有状态的，那么就无法很容易地实现了，因为客户端需要始终把请求发到同一台server才行，所谓“session迁移”等方案，也就是为了解决这个问题 三、session和cookie 基于session和cookie都可以实现事务，可以认为，session是有状态的，而cookie是无状态的 四、无状态实现事务的方法 并不是一定要用有状态服务才能实现事务，本文提供另外的几种方案作为参考 举一个多次提交的场景作为例子：用户需要提交很多数据，分为2个页面提交 这里就涉及到2次http请求，第一次提交字段1、2、3，第二次提交字段4、5、6 用session很容易实现这个需求，server只需要将第一次提交的数据，保存在session里，然后返回第2个表单作为相应；然后取出第一次提交的数据，和第二次提交的数据汇聚以后，一起存入数据库即可 不用session同样也可以实现，server接收到第一次请求以后，将数据作为隐藏元素，放在第2个表单里返回；这样用户第2次提交的时候，就隐含地再次提交了第一次的数据；server将所有数据存入数据库 用HTML5，则还可以进一步优化，client可以将第一次提交的数据，保存在sessionStorage里 用cookie也是类似的道理，同样可以实现，但是不太好 总的来说，3种替代方案（隐藏表单元素、sessionStorage、cookie）都避免了在server端暂存数据，从而实现了stateless service。本质上，这3种方案的请求里，都包含了所有必须的数据，符合本文一开始的定义 五、将有状态服务转换成无状态服务 根据本文一开始的定义，除了将所有信息都放在请求里之外，还有另外一种方法可以实现无状态服务，即将信息放在一个单独可共享的地方，独立于server存在 比如，同样还是采取session的方式，在服务端保存数据，减少每次client请求传输的数据量（节省流量）；但是将session集中存放，比如放在单独的session层里。这种情况下，server同样是无状态的，可以做水平扩展 六、无状态类 引申一下，JAVA里有一种类的设计，可以称为无状态类。这种类的特征是只有方法没有字段，在三层架构（展现层、逻辑层、持久层）里，逻辑层经常可以看到这种类 我觉得无状态类和stateless server在思想上是一样的，这个类本身是没有状态的，所以当外部要调用它的方法时，需要在方法参数中传来所需的所有信息，不依赖该类自身的状态（字段值），在并发环境下，可以避免多线程带来的副作用 七、总结 有状态服务可以比较容易地实现事务，在不需要考虑水平扩展时，是比较好的选择 无状态服务的优势在于可以很方便地水平伸缩，但是在实现事务时，需要做一些额外的动作 可以通过剥离session等方法，将一个有状态服务，转换成无状态服务 关于这个话题，下面这个链接也不错： http://stackoverflow.com/questions/4495950/how-do-stateless-servers-work

实体和值对象, entity, value object 实体和值对象 实体和值对象放在一起讲容易区分，概括而言，实体不仅需要知道它是什么？而且还需要知道它是哪个？而值对象只需要知道它是什么？先看定义： 实体 许多对象不是由它们的属性来定义，而是通过一系列的连续性（continuity）和标识（identity）来从根本上定义的。只要一个对象在生命周期中能够保持连续性，并且独立于它的属性（即使这些属性对系统用户非常重要），那它就是一个实体。 值对象：当你只关心某个对象的属性时，该对象便可作为一个值对象。为其添加有意义的属性，并赋予它相应的行为。我们需要将值对象看成不变对象，不要给它任何身份标识，还应该尽量避免像实体对象一样的复杂性。 对于实体Entity，实体核心是用唯一的标识符来定义，而不是通过属性来定义。即即使属性完全相同也可能是两个不同的对象。同时实体本身有状态的，实体又演进的生命周期，实体本身会体现出相关的业务行为，业务行为会实体属性或状态造成影响和改变。 如果从值对象本身无状态，不可变，并且不分配具体的标识层面来看。那么值对象可以仅仅理解为实际的Entity对象的一个属性结合而已。该值对象附属在一个实际的实体对象上面。值对象本身不存在一个独立的生命周期，也一般不会产生独立的行为。 初看还是很难理解，举几个例子： 案例分析 营业厅会卖手机以及很多手机配件，在客户业务规则中，往往每一部手机都要单独管理，通过手机的SN号来识别。而手机配件是一种数量类型的实物，只关心其数量的变化，并不关心到每一个具体的手机配件。这种场景就是典型的实体和对象的案例。 地址是实体还是值对象。在电力公司服务软件中，一个地址对应于公司线路和服务的目的地。如果多个住所都申请了电力服务，那么这个公司需要知道这一点，因此地址是实体。我们也可以用另一种方法，在模型中将“住所”关联到运营服务，其中“住所”是一个包含地址属性的实体。此时，地址就是一个值对象。 体育场座位例子。当我们发放的门票上有座位号的时候，座位需要作为独立的实体，座位号是唯一的标识。而当先到先座模式下，我们只关心剩余座位数，那么座位号并不是唯一标识，这时候座位就可以作为一个值对象。这跟我们的业务需求有关。 消息场景中，发件人、收件人是实体？还是值对象？这个在 三个问题思考实体和值对象一文中有讨论。 值对象的常见例子包括数字，比如100和293.51;或者文本字符串，比如"hello world";或者日期时间；还有更加详细的对象，此如某人的全名，其中包含姓改、名字和头衔；再比如货币、颜色、电话号码和邮寄地址等。当然还有更加复杂的值对象。这种对象无状态，本身不产生行为，不存在生命周期演进。 值对象的目的和使用 实体对象相对容易理解，我们常见的类的都可以看成是实体对象。值对象在DDD中相对而言是难以理解并且容易误用的。 为什么需要使用值对象，书中给了一个解释： 使用不变的值对象使得我们做更少的职责假设 个人理解这个还是基于BC的封闭性而言的，使用值对象在不同的BC中进行数据交换，可以避免不同BC对实体对象的状态变更而引发的数据依赖关系，实现最小化的集成。另外可以从目前流行的Stateless Service角度考虑值对象的价值。 开发者因为习惯趋向于将关注点放在数据而不是领域上。在软件开发中，数据库依然占据着主导地位。我们首先考虑的是数据的属性（对应数据库的列）和关联关系（外键关联），而不是富有行为的领域概念。这样做的结果是将数据模型直接反映在对象模型上，导致产生贫血型的领域模型的实体。虽然在实体模型中加入getter和setter并不是什么大错，但这却不是DDD的做法。 值类型用于度量和描述事物，DDD 中建议应尽量使用值对象来建模而不是实体对象，因为值对象非常容易地对值对象进行创建、测试、使用、优化和维护。 关于值对象，它拥有以下一些特征： 它度量或者描述了领城中的一件东西。 它可以作为不变量。 它将不同的相关的属性组合成一个概念整体(Conceptual Whole) 当度量和描述改变时，可以用另一个值对象予以替换。 它可以和其他值对象进行相等性比较。 它不会对协作对象造成副作用 一个对象的方法可以设计成一个无副作用函数(Side-Effect-Free Function) 。这里的函数表示对某个对象的操作，它只用于产生输出， 而不会修改对象的状态。由于在函数执行的过程中没有状态改变，这样的函数操作也称为无副作用函数。对于不变的值对象而言，所有的方法都必须是无副作用函数，因为它们不能破坏值对象的不变性。 最小化集成 在所有的DDD项目中，通常存在多个限界上下文，这意味着我们需要找到合适的方法对这些上下文进行集成。当模型概念从上游上下文流入下游上下文中时， 尽量使用值对象来表示这些概念。这样的好处是可以达到最小化集成，即可以最小化下游模型中用于管理职责的属性数目。使用不变的值对象使得我们做更少的职责假设。 https://www.cnblogs.com/ttaylor/p/15927009.html DDD 领域驱动设计－三个问题思考实体和值对象 消息场景：用户 A 发送一个消息给用户 B，用户 B 回复一个消息给用户 A。。。 现有设计：消息设计为实体并为聚合根，发件人、收件人设计为值对象。 三个问题： 实体最重要的特性是什么？ Message 实体是怎么得来的？ 发件人、收件人为什么不是实体？ 实体最重要的特性是什么？ 《领域驱动设计》5.2 实体： 摘录一段：许多对象不是由它们的属性来定义，而是通过一系列的连续性（continuity）和标识（identity）来从根本上定义的。 归纳： 标识（identity） 连续性（continuity） 标识在实体中的另一种体现就是唯一和不可变，其概念在很多资料中有说明，这也是实体最重要的特性。 我有一个双胞胎哥哥，我们俩出生的时候，长得一模一样，以至于我们的爸妈都分不清，不得已他们在我们脖子上系个项链来标记：谁是老大？谁是老二？其实这个“标记”就可以看作是实体的标识，只不过是用项链来标识的，就像我们在项目中使用 GUID 方式一样，目的就是用来体现标识，但不管用什么方式表示，这个标识必须在这个特定环境下唯一，也就是说，我和我双胞胎哥哥的项链不能完全一样，要不然我爸妈就不能区分我们俩了。 ...