标签：VBA 有时候，我们想将工作簿中的每个工作表都保存为一个单独的工作簿。 你可以使用下面的操作逐个保存工作表： 1.在工作表标签中单击右键。 2.选取“移动或复制…”命令。...图1 这样，有多少工作表，你就要操作上面的步骤多少次。 然而，如果存在很多个工作簿，这样的重复工作使用VBA是最合适的。...msoFileDialogFolderPicker) .InitialFileName =Application.DefaultFilePath & "\" .Title = "选择保存工作表的位置...Next wks Application.ScreenUpdating = True Application.DisplayAlerts = True End Sub 只需在要拆分的工作簿中运行上述代码...，就可将该工作簿中的所有工作表全部保存为单独的工作簿。
表模块模式：代表着以对象形式建模的数据，数据驱动 活动记录模式：类似表模块，数据驱动，关注表中的行而非表本身 贫血模式：类似领域模型，不包含任何行为，纯粹的一个对象状态模型，需要一个单独的服务类来实现行为...六、使用有界上下文维护领域模型的完整性 ? ...有界上下文就是划分和破除这种大模型的有效方式，一个有界上下文就是一个语言边界，它可以隔离模型以避免领域术语在不同上下文中的歧义。...而我们常常提到的微服务，个人感觉更像是有界上下文的一种技术实现途径之一，有界上下文中具有较高的自主性，拥有从展现层、领域逻辑层再到持久化层的完整代码堆栈，正应对了我们的每一个微服务的应用程序，也具有较高的独立性...书中还提到一个重要的观点，那就是“并非所有有界上下文都共享相同的架构模式”，换句话说就是可以将不同的架构模式应用到不同的有界上下文中。
DDD的一些概念 - 最明显的是“有界上下文”的概念 - 已经得到了普及，并启动了关于服务边界定义的行业对话。...自助银行和客户以及卡片管理子域名被突出显示，因为它们已被确定为解决方案的关键子域名。使用DDD的“语言边界”概念，显然会有一些有界的上下文出现在子域中。 在自助银行内部，有两种截然不同的有界上下文。...核心的客户信息 - 包括银行客户的权威列表，他们的联系信息以及他们的产品库 - 形成了一个独特的词汇表，我们将其称为客户信息有界上下文。另一种不同的语言被用来描述卡的功能，这主要与支付活动有关。...最后，由于向客户帐户发布交易可以晚于授权决定发布的时间，因此我们将创建与授权服务分离的交易过帐服务。 对于产品子域，我们只会在每个有界的上下文中引用单个同名服务。...事实上，人们可能想要模拟有界上下文之间的相互作用，以便梳理出单个服务，但为了叠加视觉效果，我们将在最后描述这一步骤。
以火车为例，每个车厢都要符合承重要求，行李车厢承重能力要高于其他车厢，车厢间的连接要牢固且易于拆解，有足够的灵活性方便转弯。...举个例子，从北京到上海出差，可以先理解为使用交通工具前往，但不需要一开始就想清楚到底是高铁还是飞机，以及乘坐他们需要注意什么 3、知识 通过知识手段抽象出限界上下文以及如何去分治 二、DDD概览 DDD...全称为“Domain Driven Design”,意思是领域驱动设计，基于业务知识设计系统，代码反映业务，它将真实业务概念和业务规则转换为软件系统中的概念和规则，在一个个有界上下文中发挥其作用，完成用户要求的功能...需要在有界上下文中验证 举个例子：假如有父亲和儿子这两个表，生成的 POJO 应该是 public class Father{…} public class Son{ //son 表里有 fatherId...，以数据库表作为系统导向，但是DDD建议应该先着眼于业务本身，减少对数据库表结构的依赖，避免业务发生变化，把我们打得措手不及，它把你的思考起点从技术的角度拉到了业务上。
DDD中有一个很重要的概念，有界上下文（Bounded Context），可以用有界上下文来划分微服务，每个有界上下文都可以是一个微服务。下面是有界上下文的示例。...有界上下文的一个关键是如何处理共享成员， 在图中是“Customer”和“Product”。...在不同的有界上下文中，共享成员的含义、用法以及他们的对象属性都会有些不同，DDD建议这些共享成员在各自的有界上下文中都分别建自己的类（包括数据库表），而不是共享。...DDD（Domain-Driven Design）建议不要共享这个类，而是在每一个有界上下文（模块）中都建一个新类，并拥有新的名字。...虽然它们的数据库中的数据应该大致相同，但DDD建议每一个有界上下文中都建一个新表，它们之间再进行数据同步。
这些模式包括有界的上下文、上下文映射、实体、聚合体、领域事件、领域服务、应用服务和基础设施。这些战术模式将帮助你设计既松散耦合又有凝聚力的微服务 。...定义解决方案空间中的有界上下文 在有界限的上下文中，应用战术性DDD模式来定义实体、聚合、领域服务、领域事件等。 使用上一步的结果来确定你的团队中的微服务。 以下是分析结果。...付款视图：一个聚合的付款细节视图，包含与一个付款有关的所有数据。 解决方案空间 有界上下文 有界上下文（BC）限定了一个领域模型的范围。从问题空间的分析结果来看，我们可以定义以下有界上下文。...从领域模型到微服务 现在，我们已经为支付系统定义了一组有边界的上下文，并在每个有边界的上下文中确定了一组实体、集合体和领域事件服务。 下一步就是要从领域模型到应用微服务的设计。...在这里，我们选择将一个有界上下文映射到一个微服务。 结论 在这篇博客中，当我们试图对支付系统进行建模时，我们触及了领域驱动设计（DDD）模式的各种概念和策略。
解决 对于“神类”问题，DDD（领域驱动设计）可以解决。它使用子域和有界上下文概念来解决此问题。DDD将为企业创建的整个域模型分解为子域。每个子域都有一个模型，该模型的范围称为有界上下文。...每个微服务将围绕有界的上下文进行开发。 注意：确定子域并非易事。它需要对业务的了解。像业务功能一样，通过分析业务及其组织结构并确定不同的专业领域来标识子域。...每个微服务应具有一个单独的数据库ID，以便可以给予单独的访问权限以设置障碍并防止其使用其他服务表。...每个服务共享数据库 问题 我们已经讨论了每个服务一个数据库是微服务的理想选择，当应用程序是未开发的并且要使用DDD开发时，这是可能的。...解决 Saga代表由几个子请求组成的高级业务流程，每个子请求在单个服务中更新数据。每个请求都有一个补偿请求，该请求在请求失败时执行。
在深入探讨有关DDD（领域驱动设计）方面的有界上下文之前，我们先来了解一下它在现实世界中的意义。我们知道人类是最聪明的物种，并创造了不同的国家来统治。...在同一个国家，每个公民都遵循一些预定义的规则、语言和风格。他们懂得共同的语言、法律、货币和风格，所以我可以说，在一个国家里，公民之间是同步的，那个国家有一个统一的文化，每个公民都遵循和理解。...通知系统：它会通知老师和学生关于时间和时间间隔的信息。 所以，有四个有界上下文：注册，付款，调度和通知。 现在，让我们深入了解每个模块如何表示教师，学生和课程模型。...无处不在的语言的概念在这里交织在一起，使用无处不在的语言DDD来创建一个统一的系统，在这个系统中，每个参与者都能根据上下文理解语言。 现在，常见问题是为什么有界上下文术语在微服务中如此流行？...业务域将业务逻辑分解为多个有界上下文，每个有界上下文都是一个单独的代码库，并通过上下文映射进行通信。
类似地，开发人员不会讨论数据库表中的数据列以及新字段类型。 DDD严格要求我们开发出一种无处不在的语言。...DDD称之为有界上下文（BC）。每个域模型都只存在于一个BC中，BC只包含一个域模型。 我必须承认，当我第一次读到关于BC时，我看不出重点：如果BC与领域模型一样，为什么要引入一个新术语？...图2：有界上下文关系的谱 然而，当我们走向跟从模式时，我们只是一起调用和被调用; 一个BC明显屈服于另一个。如果我们必须与购买megabucks的总分类帐系统集成，那可能就是我们所处的情况。...图3显示了我过去5年左右一直在研究的系统的上下文映射。 图3：上下文映射示例 所有这些关于有界上下文图和BC的讨论有时被称为战略性DDD，并且是有充分的理由的。...如果表现层有单独的存储空间中（比如手机终端），应用层也充当表现层和领域层之间的中介。表现层通常处理领域对象或其他对象（数据传输对象或DTO）的可序列化表示，通常每个“视图”一个。
例如，自动化测试，持续集成和持续交付 简而言之，我们可以将这种体系结构样式总结如下： 松耦合的面向服务的体系结构，其中每个服务都包含在定义明确的有界上下文中，从而可以快速，频繁且可靠地交付应用程序。...领域驱动设计（DDD）是关键，在我们看来，这是设计微服务时必不可少的工具，无论是打破整体还是实施未开发项目。...子域属于问题空间，即您的企业如何看待问题，而受限上下文属于解决方案空间，即我们将如何实施问题的解决方案。从理论上讲，每个子域可能具有多个有界上下文，尽管我们努力为每个子域提供一个有界上下文。...微服务与有限上下文如何相关 现在，微服务在哪里适合？可以说每个有界上下文都映射到微服务吗？是的，我们将明白为什么。在某些情况下，有界上下文的边界或轮廓可能很大。 考虑上面的例子。...购物车上下文负责订单的在线授权；订单上下文流程过帐付款后的付款流程；联络中心会处理所有例外情况，例如重试付款和更改用于订单的付款方式 为了简单起见，让我们假设所有这些上下文都是作为单独的服务实现的 所有这些上下文封装了相同的模型
Sperber 给出了一个将系统代码划分为不同构建块的例子。这是一种特别重要的架构决策，可以单独处理不同的构建块，也可以与不同团队一起协作。...实现这一点的一种方法是对粗粒度的构建块（有界上下文）使用领域驱动设计（DDD）： DDD 是指，我们应该在开始时就通过上下文映射来识别有界上下文。...在探索和开发这些领域模型时，函数式程序员经常利用数学提供的丰富词汇表。由此产生的抽象从根本上说是由函数语言所提供的高级抽象设施实现的。...因此，这些决策很有可能是错误的。 InfoQ：在上下文之间移动边界变得如此困难的原因是什么？...Sperber：在架构界，我们似乎忘了如何在有界上下文或单体中实现模块化，这就是为什么会有“模块化”这个新术语的原因，这意味着常规单体在默认情况下是非模块化的，其内部是紧密耦合的。
这是一套技术工具，可以在最重要的地方具体应用DDD方法。这些模式以与良好实践相同的速度快速发展。一个众所周知的例子是存储库模式。战术模式有助于了解如何构建业务的每个部分。 ?...它们允许将域（业务）分类为子域，以便了解如何围绕它构建应用程序的上下文。每个上下文都有一个特定的通用业务语言（无处不在的语言），并使用精确的通信方式。上下文是否将一些事情强加给另一个上下文？...根本原因分析 在我的DDD教学领域，我认为有两个子领域：一个是战术，另一个是战略。 教授DDD的有效实施将为战略模式绘制一个有界的上下文，为战术模式绘制一个上下文。...这是我的核心领域，是我在教授DDD时想要分享的核心价值观。我的上下文之间存在明显的依赖关系。战术模式很重要，但如果我单独教他们带来价值不大。...但是在为新手教授DDD的领域，我会强调战略模式，主要是有界的上下文，因为这是可以导致所有其他模式的模式。
这有利于设计向前推进，取得足够的进展，而不是掉进“我的模型被强制转化成石头”这一陷阱。 在DDD中，这些小的模型存在于上下文的边界，这些有界上下文相互关联的方式称为上下文映射。...上下文边界 对于每一个模型，应该有意和明确地去定义其所处的上下文。创建上下文并没有特定的规则，但重要的是让每个人都能理解上下文的边界条件。...上下文映射 上下文映射是针对连接点的设计过程，同时有界上下文之间的转义关系应该被明确的反应出来。我们应该着重于处理现有界限之间的映射关系，之后再去处理实际的转换。 ?...HOT TIP:在单个有限的上下文中使用持续集成，以缓解由于不同理解产生过多碎片的矛盾。频繁的代码合并，自动化测试，使用通用语言都会加剧促使有界上下文中碎片的产生。...消费者/生产者开发团队 当一个有界上下文服务于或者消费另一个有界上下文，那么下游的上下文将会依赖于上游上下文。明确上下文处于上游或者下游能使其提供者或者消费者的身份变得更加清晰。 ?
在确定每个微服务的模型边界和大小时，目标并不是尽可能实现最细粒度的分离，尽管如果可能的话，您应该倾向于使用较小的微服务。相反，您的目标应该是在您的领域知识的指导下实现最有意义的分离。...Sam Newman是公认的microservices的发起人，也是《构建microservices》一书的作者，他强调应该根据前面介绍的有界上下文（BC）模式（领域驱动设计的一部分）来设计microservices...你可能需要推翻康威的法律，按照你希望公司组织的方式建立边界，倾向于业务流程咨询。 要识别有界上下文，可以使用称为上下文映射模式的DDD模式。使用上下文映射，可以标识应用程序中的各种上下文及其边界。...例如，每个小的子系统都有不同的上下文和边界。上下文映射是定义和明确域之间边界的一种方法。BC是自治的，包含单个域的详细信息（如域实体），并定义与其他BC的集成合同。...这类似于微服务的定义：它是自治的，实现了一定的域功能，并且必须提供接口。这就是为什么上下文映射和有界上下文模式是识别微服务的域模型边界的好方法。
战略模式 vs 战术模式 战略模式 vs 战术模式 领域驱动设计（DDD）分为战略模式和战术模式。 战略模式由限界上下文、通用语言和上下文映射等模式组成； 战术模式由值类型、实体和聚合等模式组成。...它们主要涵盖更高级别的软件设计，例如有界上下文、上下文映射、反腐败层、有界上下文集成模式。 这些模式不依赖于所使用的编程语言或框架。 然而，战术模式依赖于编程语言结构和范式。...关于代码库中实体位置的任何假设可能不再有效； 在单个事务中更新多个实体的任何尝试都将进入分布式事务的不稳定领域。 因此，要避免这些陷阱，请遵循以下三个准则。 聚合作为事务边界：每个聚合用作事务边界。...消息用于聚合：无论您是构建微服务还是单体应用程序，你都不应该对其他聚合的位置做出任何假设。每个聚合通过向其地址发送消息与另一个聚合进行通信 — 通过聚合的唯一ID。...Lens 允许您更新深度嵌套的值，并获取整个更新后的聚合。 使用 Monoid 来表示值对象：本文档很好地解释了 DDD 上下文中的 Monoid。 使用基于属性的测试来测试领域不变量。
解决方案 对于“God Classes”问题，DDD（领域驱动设计）来拯救。它使用子域和有界上下文概念来解决这个问题。DDD 将为企业创建的整个域模型分解为子域。...每个子域都有一个模型，该模型的范围称为有界上下文。每个微服务都将围绕有界上下文开发。 注意：识别子域并非易事。这需要对业务的了解。...每个微服务都应该有一个单独的数据库 ID，以便可以提供单独的访问权限来设置障碍并防止它使用其他服务表。...每个服务共享数据库 问题 我们已经讨论过每个服务一个数据库是微服务的理想选择，但是当应用程序是未开发并使用 DDD 开发时，这是可能的。...解决方案 一个 Saga 代表一个由多个子请求组成的高级业务流程，每个子请求都更新单个服务中的数据。每个请求都有一个在请求失败时执行的补偿请求。
在微服务（Microservices）架构实践中，人们大量地借用了DDD中的概念和技术，比如一个微服务应该对应DDD中的一个限界上下文（Bounded Context）；在微服务设计中应该首先识别出DDD...显然，我们需要在订单和积分之间维护数据一致性，通常的做法是在同一个事务中同时更新两者，但是这会存在以下问题： 违背DDD中"单个事务修改单个聚合根"的设计原则； 需要在不同的系统之间采用重量级的分布式事务...如果JTA不是你的选项，那么可以考虑采用事件表的方式。这种方式首先将事件保存到聚合根所在的数据库中，由于事件表和聚合根表同属一个数据库，整个过程只需要一个本地事务就能完成。...然后，在一个单独的后台任务中读取事件表中未发布的事件，再将事件发布到消息中间件中。 ?...另外，我们需要考虑到聚合更新和事件发布之间的原子性，可以考虑使用XA事务或者采用单独的事件表。为了避免事件重复带来的问题，最好的方式是将事件的消费方创建为幂等的。 ----
但我生气的是，最近，似乎任何时候，当有人谈论如何设计系统或服务边界，或者只是提到非技术设计时，每个人都感觉不得不引进 DDD 专家——好像他们是唯一可以设计这些东西的超级英雄。...在 DDD 的战略维度中，最常用的工具是“有界上下文”的概念——一个给定的模型通常可以，而且应该被细分为更小的单元，每个单元为特定的概念赋予符合它们自己上下文的特定含义。好主意！...这（当然）也不是 DDD 的发明：它只是简单的模块化设计，已经被设计大型系统的人们应用了几十年。 这是否意味着有界上下文的概念有问题呢？不，事实上，该模式的目的是为已经存在并证明了其价值的东西命名。...我并不是说有界上下文有什么问题，我只是想指出，有些人可能在没有使用或甚至不知道这个特定称谓的情况下做了出色的系统设计。 在战术层面，人们忽略了一个更重要的方面，特别是当他们将 DDD 作为设计入门时。...DDD 强调命名的重要性，并建议你在设计中尽量使用一种通用的、普遍存在的语言。但对于系统设计领域，它也使用自己的语言——诸如有界上下文、聚合、实体、值对象等概念。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
实时音视频
即时通信 IM
