本文主要解释“基于领域分析和设计的spring架构规范”。感兴趣的朋友不妨看看。本文介绍的方法简单、快速、实用。让边肖带你学习“基于领域分析与设计的春季架构规范”！
领域聚合
让我们以一个相对简单的小型电子商务系统为例来说明几个概念。该电子商务系统的大致要求如下
我们的主打产品是甜品，计划用户可以通过微信小程序完成从点餐到付款的全过程。
用户可以在我们小程序的首页选择甜品主食，然后选择一些详细的配件进行搭配，最后下单。(为了简单起见，我们暂时不考虑购物车，即一个订单只有一个甜品。)
目前只允许在大厅就餐，不考虑配送。
对了，我们偶尔需要发放一些优惠券，用户在付款时可以输入优惠券进行抵扣(一次最多一张优惠券)。
我们希望能够记录每个用户从下单、付款到制作的全过程记录。
然后，我们就可以快速的画出这样的模型图。
简单来说，就是：
当然，用户可以创建多个订单，而无需下订单。
订单将至少生成一条订单变更记录(从创建开始)。
一个订单只对应一个产品，假设产品的“配件匹配”只作为产品的“备注”属性存储。
一张订单最多只能使用一张优惠券，而且优惠券在那个时候永远不能使用。
如果此时问你，你觉得那两个模型类的相互关系是最紧密的呢？相信几乎每个人都不反对这个答案。
也许你不能说为什么在这个时候，但至少从直觉,的角度来看每个人都会选择这种方式，而且是真的。
因为这是聚合——订单聚合。
他们的关系非常密切。有多近？如果非要挑一个最重要的因素，那就是：订单变更记录不能离开订单而单独存在.是的，它们必须在一起，订单是中心，变更记录是它的附属。如果订单不存在，或者没有指定订单，那么这个变更记录就没有意义。
其中，顺序被称为聚合根，或根实体。的所有操作都来自订单,而订单更改记录等非根实体不直接与外部世界打交道。
优惠券呢？优惠券不能只用于订单吗？不应该属于“订单优惠券”吗？
不，因为优惠券可以不用，那时候没有订单也是存在的，我们可以在不需要外界任何其他领域的情况下，直接对优惠券进行一些设置修改,这也说明它是一个独立的领域，或者说是一个独立的集合体。
至于分析的目的，我们将在拥挤模型一章中详细解释。
分层模型
下图显示了《领域驱动设计》中提到的分层架构。
关于原著中四层的介绍，这里就不在原文中重复了。根据我的理解(或疑问)，我选择重点分别介绍一下：
用户界面层
实际上，这里有些混乱。不知道作者有没有包括前端应用。如果没有，那么可能有类似网关或路由配置层的东西。然而，这不是领域分析的重点。
00-1010这是一个与领域层的边界相对模糊的层。在原著中，这一层的描述如下：
定义软件能做什么.它不包括处理业务规则或知识，只是协调任务并将工作委托给下一层的协作域对象。
“定义软件可以完成的工作”,我们可以理解这是一个应用服务门户，一个功能单元和一个API。然后，以SpringMVC为例，我们开发的时候门户是什么？自然是@Controller。如果您需要事务支持，可以在这里添加@Transactional。不要以为交易不加@Service，也没什么奇怪的。摆脱这种思维惯性。
“它不包含处理业务规则或知识”
，并非完全“和业务无关”。广义上来说，连一个商业项目的整个架构都是为业务来服务，就算是遵循了“开闭原则”，保证了“扩展性”，依旧是以业务方向做主导。所以，应用层也会涉及业务，但是却非“核心逻辑”。那如何界定？我目前也没有想到一个可以简单描述出来的说法，只是做了一些相对简单粗暴的规定：如果这个功能要求用到一些公共的组件，诸如文件上传下载，EXCEL/WORD等文件解析等明显是工具型做法，一般来说都能放在这一层。
领域层
核心业务逻辑，之后我们讨论的主要内容都在这一层。
基础设施层
持久化读写，公共组件如上面提到的文件下载工具等，还有比如RPC的框架组件等等，都属于此层。这一层可以被上面的任何一层直接调用
到此，相信大家对“spring基于领域分析设计的架构规范”有了更深的了解，不妨来实际操作一番吧！这里是网站，更多相关内容可以进入相关频道进行查询，关注我们，继续学习！
内容来源网络，如有侵权，联系删除，本文地址：https://www.230890.com/zhan/96659.html