企业级私有云环境下的核心技术需求有哪些？
 
高I/O性能：支持大型企业级应用，以及降低CapEx（为满足特定需求，可以投入更少的计算资源）。
功能简单、界面直观：让企业IT团队能够在短时间内掌握基本维护技巧，降低OpEx。
自动化运维：部署、扩容、监控、告警、自动伸缩，都能通过基本的UI操作全部完成，降低OpEx。
 
  
 
 那么要满足这样的核心需求，OpenStack-Powered产品该如何设计？
 
  
 
 1. 界面交互
 
 从用户角度看，用户第一眼看到的是什么？界面！所以界面直观，让用户一眼看到就知道怎么用。
 
 用户怎么样才能知道如何使用？VMware和Microsoft已经培养好了用户习惯，我们在界面交互设计时只要模仿即可，
 
 模仿主流产品的界面交互，让用户能够不用培训就能入手，创建VM，登录VM，安装应用，参看和配置监控和告警。
 
  
 
 2. 功能简单
 
 如果功能特别复杂，就会导致界面复杂，一层层菜单向下走，而不是一个平面操作，界面交互就不可能简洁。
 
 所以，界面直观的一个引申，就是用户界面的功能要简单，特别是针对OpenStack，
 
 如果实在无法化简，有一个实践可以参考，就是按照用户常用功能、高级功能，
 
 在用户登录后，菜单栏分开成两个Panel，Simple Operations和Advanced Functions。
 
 Simple Operations：指代正常使用的虚拟化、必须要用到的功能。
 
 Advanced Functions：指代所有可选的云的高级功能，包括SDN、Backup、Alarming、Auto-Scaling。
 
  
 
 3. 自动化运维
 
 既然是自动化，则用户只要简单配置，甚至不需要配置，就可以达到一个默认大多数用户都能接受的效果。
 
  
 
 4. 虚拟化管理模块如何满足呢？
 
 大多数功能都是VM管理，所以不需要化简。
 
 但如果优化的话，尽量在界面上提供能够一步走到底的Batch Operation，而不是要让用户一个个点开操作。
 
  
 
 5. SDN模块如何满足需求？
 
 只要能实现一个稳定的二层控制面，SDN的任务其实就完成了。由于每个客户的物理网络环境和对网络需求
 
 确实千差万别，需要定制，但实际上选择面也不是多到难以抉择。
 
 （1）Provider Network
 
 如果客户只是最为简单的虚拟化管理需求，那么将Neutron虚拟网络直接挂接到物理网络上，实现一个Flat网络即可。
 
 如果客户需要网络隔离，但是也有Admin统一纳管，那么还是使用该技术，指定多个ProviderNet，实现一个带物理隔离的Flat网络。
 
 （2）Multi-tenancy Network Isolation
 
 如果客户方需要对多个部门实现网络隔离，并且需要能够自定义网络，那么就需要用到VLAN。
 
 如果客户方规模大到VLAN无法承载，才要使用VxLAN。
 
 如果客户方有多个DC，并且二层打通，那么为了资源最大化利用，也要使用VxLAN。
 
 （3）DHCP-Agent
 
 如果允许VM直接配置静态IP，则无需使用DHCP-Agent。
 
 如果使用Provider Network，那么可以直接在该物理网络上，启动外部DHCP Server。
 
 如果需要自定义网络，则需要DHCP-Agent，目前都能支持Failover和A/A。
 
 （4）L3-Agent
 
 没事，别找抽，企业私有云一般都不会有NAT的需求，这个是公有云的需求。
 
 没见过哪个用VMware虚机的企业在内部运维还去配置两层IP。
 
 实在客户需要NAT，那么优先在物理网络的三层设备上做。
 
 实在要通过SDN运行NAT，则在技术支持条件好的环境下，优先选择第三方企业级SDN解决方案，比如Midonet、Centec等。
 
 然后再是DVR（前提是启动L3-Agent HA），最后是DragonFlow（如果其L3 Controller Agent支持HA，则DragonFlow优先于DVR）。
 
 （5）LBaaS-Agent
 
 这个是SPOF，看客户需求部署。
 
 （6）VPNaaS-Agent
 
 这个是SPOF，看客户需求部署。
 
 （7）FWaaS
 
 这个是L3-Agent的Extension。
 
 （8）性能
 
 网络高IO也是核心需求，所以在数据包的转发面上，、
 
 尽量减少虚拟化，尽量减少Kernel协议栈的干预。
 
 （9）运维复杂度
 
 基于Flow的转发面的使用，需要引入额外运维的开销和调试复杂度，比如DVR，Dragonflow等。
 
  
 
 6. 存储模块如何满足需求？
 
 数据冗余，然后就是高I/O，高I/O，高I/O。否则很多企业级应用（IO密集型）根本没办法跑。
 
 所谓IO密集型应用，主要指代应用过程中产生大量用户端的实时交易，交易越密集，IO要求越高。
 
  
 
 7. 计算（虚拟化技术）模块如何满足需求？
 
 计算模块实际上贯穿是一个最为核心的模块，无论网络I/O、存储I/O，在虚拟化层面上，都要做足优化。
 
 包括CPU多核架构、内存、设备驱动层面。但是这些优化都应该由自动化部署系统去完成，不需要体现在用户界面上。
 
  
 
 至于是否在产品中直接使用容器虚拟化，则是另一个话题。因为容器虚拟化技术本身简单，但背后需要重构一个App-Centric的
 
 体系，并且企业IT部门也要有一个完全不同的DevOps面貌来支撑这个体系，这个不是短时间内可以落地的。

  一、SWOT分析的一般方法
 
　　SWOT分析是一种对企业的优势、劣势、机会和威胁的分析，在分析时，应把所有的内部因素(包括公司的优势和劣势)都集中在一起，然后用外部的力量来对这些因素进行评估。这些外部力量包括机会和威胁，它们是由于竞争力量或企业环境中的趋势所造成的。这些因素的平衡决定了公司应做什么以及什么时候去做。可按以下步骤完成这个SWOT分析表：
 
(1)把识别出的所有优势分成两组，分的时候应以下面的原则为基础：看看它们是与行业中潜在的机会有关，还是与潜在的威胁有关。
 
　　(2)用同样的方法把所有劣势分成两组。一组与机会有关，另一组与威胁有关。
 
　　(3)建构一个表格，每个占1/4。
 
　　(4)把公司的优势和劣势与机会或威胁配对，分别放在每个格子中。SWOT表格表明公司内部的优势和劣势与外部机会和威胁的平衡。
 
在你的企业计划中，一定要把以下步骤都写出来：
 
　　　①在某些领域内，你可能面临来自竞争者的威胁；或者在变化的环境中，有一种不利的趋势，在这些领域或趋势中，公司会有些劣势，那么要把这些劣势消除掉。
 
　　　②利用那些机会，这是公司真正的优势。
 
　　　③某些领域中可能有潜在的机会，把这些领域中的劣势加以改进。
 
　　　④对目前有优势的领域进行监控，以便在潜在的威胁可能出现的时候不感到吃惊。 
 

 
　　二、公司的优势和劣势
　　公司的优势是指在执行策略、完成计划以及达到确立的目标时可以利用的能力、资源以及技能。公司的劣势是指能力和资源方面的缺少或者缺陷。
　　在为将来做计划时，确定企业的能力和资源代表的是可利用的优势还是劣势，这一点是很重要的。成功的决定因素指的是那些公司成功所必须具备的能力和资源。把这些与成功的决定因素放在一起，就可以形成一个表格，它反过来可以让你做一下比较：你的能力和资源与行业中重要的能力和资源的比较，这将有助于让你识别出公司目前的优势与劣势。
 
 
 
 
 来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/178883/viewspace-16352/，如需转载，请注明出处，否则将追究法律责任。 
 
 
转载于:http://blog.itpub.net/178883/viewspace-16352/

SWOT是英文Strengths、Weaknesses、Opportunities和Threats的缩写。
 
SWOT分析实际上是将对企业内部和外部条件各方面内容进行综合和概括，进而分析组织的优劣势、面临的机会和威胁的一种方法。
其中，优劣势分析主要是着眼于企业自身的实力及其与竞争对手的比较，而机会和威胁分析将注意力放在外部环境的变化及对企业的可能影响上，但是，外部环境的变化可能会给具有不同资源和能力的企业带来的机会与威胁却可能完全不同，因此，两者之间又有紧密的联系。
 
当公司要拓展在某一新的业务或进行新的投资前，以及在制定销售计划时，所用的战略分析方法之一便是SWOT分析。
 
采用这种决策方法的根本目的是把自己公司和竞争对手公司的优势、劣势、机会和挑战进行比较，然后决定某项新业务或新投资是否可行。做SWOT分析有利于自己的公司在做新业务前是否会充分发挥自己和长处而避免自己的短处，以趋利避害，化劣势为优势，化挑战为机遇。同时，也使自己的公司知道该从学习什么来面对市场商机。即所谓的知己知彼、百战不殆，从而降低公司的经营和投资风险。
 
进行SWOT分析时，主要有以下几个方面的内容：
 
　　一、分析环境因素 
　　运用各种调查研究方法，分析出公司所处的各种环境因素，即外部环境因素和内部能力因素。外部环境因素包括机会因素和威胁因素，它们是外部环境对公司的发展直接有影响的有利和不利因素，属于客观因素，一般归属为经济的、政治的、社会的、人口的、产品和服务的、技术的、市场的、竞争的等不同范畴；内部环境因素包括优势因素和弱点因素，它们是公司在其发展中自身存在的积极和消极因素，属主动因素，一般归类为管理的、组织的经营的、财务的、销售的、人力资源的等不同范畴。在调查分析这些因素时，不仅要考虑到公司的历史与现状，而且更要考虑公司的未来发展。
 
　　二、构造SWOT矩阵 
　　将调查得出的各种因素根据轻重缓急或影响程度等排序方式，构造SWOT矩阵。在此过程中，将那些对公司发展有直接的、重要的、大量的、迫切的、久远的影响因素优先排列出来，而将那些间接的、次要的、少许的、不急的、短暂的影响因素排列在后面。
 
　　SWOT矩阵：
              　　　优势　　　　　　　　　　　　劣势
    
机会　　　　so战略（增长性战略）　　　　wo战略（扭转型战略）
威胁　　　　st战略（多种经营战略）　　　wt战略（防御型战略）
 
　　三、制定行动计划
　　在完成环境因素分析和SWOT矩阵的构造后，便可以制定出相应的行动计划。制定计划的基本思路是：发挥优势因素，克服弱点因素，利用机会因素，化解威胁因素；考虑过去，立足当前，着眼未来。运用系统分析的综合分析方法，将排列与考虑的各种环境因素相互匹配起来加以组合，得出一系列公司未来发展的可选择对策。这些对策包括：
　　最小与最小对策（WT对策），即考虑弱点因素和威胁因素，目的是努力使这些因素都趋于最小。 
　　最小与最大对策（WO对策），着重考虑弱点因素机会因素，目的是努力使弱点趋于最小，使机会趋于最大。 
　　最小与最大对策（ST对策），即着重考虑优势因素和威胁因素，目的是努力使优势因素趋于最大，是威胁因素趋于最小。 
　　最大与最大对策（SO对策），即着重考虑优势因素和机会因素，目的在于努力使这两种因素都趋于最大。 
 
SWOT分析也可以用与个人在职场拼搏态势的分析。
  和企业SWOT分析类似，个人SWOT分析可以分为以下几步：
  1、评估自己的长处和短处
  2、找出您的职业机会和威胁
  3、提纲式地列出今后五年内您的职业目标
  4、提纲式地列出一份今后5年的职业行动计划
 
具体的步骤不再多说，嗯，社会是复杂的，那么认清现实，多做做形势分析，合理的扬长避短，以趋利避害，化劣势为优势，化挑战为机遇的重要性怎么说都是不为过的。
 

信息时代的求职利器——个人SWOT分析 
 

 作者：文摘　　　　　　　　　　录入新月于 May 29, 2003 at 18:16:11:

 
SWOT分析是市场营销管理中经常使用的功能强大的分析工具：S代表strength（优势），W代表weakness（弱势），O代表opportunity（机会），T代表threat（威胁）。市场分析人员经常使用这一工具来扫描、分析整个行业和市场，获取相关的市场资讯，为高层提供决策依据，其中，S、W是内部因素，O、T是外部因素。 
您在求职时，可以不妨采用这一工具对自己进行一番从里到外的体检。 
SWOT分析是检查您的技能、能力、职业、喜好和职业机会的有用工具。如您对自己做个细致的SWOT分析，那么，您会很明了地知道自己的个人优点和弱点在哪里，并且您会仔细地评估出自己所感兴趣的不同职业道路的机会和威胁所在。 
一般来说，求职者在进行SWOT分析时，应遵循以下四个步骤： 
1、评估自己的长处和短处 
我们每个人都有自己独特的技能、天赋和能力。在当今分工非常细的市场经济里，每个人擅长于某一领域，而不是样样精通（当然，除非天才）。举个例子，有些人不喜欢整天坐在办公桌旁，而有些人则一想到不得不与陌生人打交道时，心里就发麻，惴惴不安。请做个表，列出您自己喜欢做的事情和您的长处所在（如果您觉得界定自己的长处比较困难，您可以找一些测试习题做一做，做完之后，可以发现您的长处所在）。同样，通过列表，您可以找出自己不是很喜欢做的事情和您的弱势。找出您的短处与发现您的长处同等重要，因为您可以基于自己的长处和短处做两种选择：一是努力去改正您常犯的错误，提高您的技能，二是放弃那些对您不擅长的技能要求很高的职业。列出您认为自己所具备的很重要的强项和对您的职业选择产生影响的弱势，然后再标出那些您认为对您很重要的强、弱势。 
2、找出您的职业机会和威胁 
我们知道，不同的行业（包括这些行业里不同的公司）都面临不同的外部机会和威胁，所以，找出这些外界因素将助您成功地找到一份适合自己的工作，对您求职是非常重要的，因为这些机会和威胁会影响您的第一份工作和今后的职业发展。如果公司处于一个常受到外界不利因素影响的行业里，很自然，这个公司能提供的职业机会将是很少的，而且没有职业升迁的机会。相反，充满了许多积极的外界因素的行业将为求职者提供广阔的职业前景。请列出您感兴趣的一两个行业，然后认真地评估这些行业所面临的机会和威胁。 
3、提纲式地列出今后五年内您的职业目标 
仔细地对自己做一个SWOT分析评估，列出您从学校毕业后5年内最想实现的四至五个职业目标。这些目标可以包括：您想从事哪一种职业，您将管理多少人，或者您希望自己拿到的薪水属哪一级别。请时刻记住：您必须竭尽所能地发挥出自己的优势，使之与行业提供的工作机会完满匹配。 
4、提纲式地列出一份今后5年的职业行动计划 
这一步主要涉及到一些具体的东西。请您拟出一份实现上述第三步列出的每一目标的行动计划，并且详细地说明为了实现每一目标，您要做的每一件事，何时完成这些事。如果您觉得您需要一些外界帮助，请说明您需要何种帮助和您如何获取这种帮助。举个例子，您的个人SWOT分析可能表明，为了实现您理想中的职业目标，您需要进修更多的管理课程，那么，您的职业行动计划应说明您何时进修这些课程。您拟订的详尽的行动计划将帮助您做决策，就像公司事先制定的计划为职业经理们行动指南一样。 
诚然，做此类个人SWOT分析会占用您的时间，而且还需认真地对待，但是，详尽的个人SWOT分析却是值得的，因为当您做完详尽的个人SWOT分析后，您将有一个连贯的、实际可行的个人职业策略供您参考。在当今竞争白热化的市场经济社会里，拥有一份挑战和乐趣并存、薪酬丰厚的职业是每一个人的梦想，但并不是每一个人都能实现这一梦想。因此，为了使您的求职和个人职业发展更具有竞争性，请花一些时间界定您的个人优势和弱势，然后制定一份策略性的行动计划，务必保证有效地完成它，那么，您的前景将灿烂而辉煌！

目录
 
领域驱动实践总结一:基本理论总结与分析
 
一、领域驱动设计两大设计:战略设计和战术设计
 
（一）战略设计
 
1.出发角度与目标
 
2.实现方式：事件风暴与模型确立（用例分析、场景分析和用户旅程分析）
 
3.用三步来划定领域模型和微服务的边界
 
（二）战术设计
 
1.出发角度与目标
 
2.实现方式：DDD 分层架构、整洁架构、CQRS 和六边形架构等  （我们采用DDD 分层架构）
 
3.代码模型强调两点：聚合之间的代码边界一定要清晰+一定要有代码分层的概念
 
二、理解和分析领域+子域+核心域+通用域+支撑域
 
（一）整体理解领域与子域的概念（以桃树生物学知识体系的建立为例来加深理解）
 
（二）理解核心域、通用域和支撑域的划分及具体目的
 
1.核心域
 
2.通用域
 
3.支撑域
 
4.划分核心域、支撑域和通用域的主要目标
 
三、理解和分析界限上下文,定义领域边界
 
（一）通用语言
 
（二）限界上下文
 
四、理解和分析实体和值对象
 
（一）对于实体的具体理解
 
1.实体的业务形态
 
2.实体的代码形态
 
3.实体的运行形态
 
4.实体的数据库形态
 
（二）对于值对象的具体理解
 
1.实体的业务形态
 
2.实体的代码形态
 
3.实体的运行形态
 
4.实体的数据库形态
 
5. 值对象的优势和局限
 
（三）对于实体与值对象关系的理解
 
1.基本的关系理解
 
2.不同场景下关系的不同
 
五、理解和分析聚合思想:聚合和聚合根
 
（一）对聚合的理解和分析
 
（二）对聚合根的理解和分析
 
（三）聚合、聚合根、实体、值对象的对比
 
（四）基本理解综合
 
六、理解很分析领域事件来解耦微服务
 
（一）领域事件的识别
 
（二）微服务内外的领域事件分析
 
1. 微服务内的领域事件
 
2. 微服务之间的领域事件
 
（三）领域事件总体架构
 
1. 事件构建和发布
 
2. 事件数据持久化
 
3. 事件总线 (EventBus)
 
4. 消息中间件
 
5. 事件接收和处理
 
（四）具体案例分析
 
参考书籍、文献和资料
 

领域驱动实践总结一:基本理论总结与分析
 
领域驱动设计DDD是一种设计思想，它可以同时指导中台业务建模和微服务设计(中台本质是业务模型，微服务是业务模型的系统落地)，领域驱动设计强调领域模型和微服务设计的一体性，先有领域模型然后才有微服务，而不是脱离领域模型来谈微服务设计。
 
微服务拆分困境产生的根本原因:不知道业务或者微服务的边界到底在什么地方。
 
DDD 核心思想:通过领域驱动设计方法定义领域模型，从而确定业务和应用边界，保证业务模型与代码模型的一致性。
 
对于领域驱动设计的学习做的总结主要写三篇博客，主要包括三部分:基本理论总结与分析、架构分析与代码设计、具体应用设计分析，主要参考的资料为极客时间的欧创新架构师的《DDD》实战，其他参考书籍在文章下方的参考书籍中。
 
本次主要总结DDD基本理论总结与分析
 
一、领域驱动设计两大设计:战略设计和战术设计
 
领域驱动设计认为:开发团队应该从业务需求中提炼出统一语言，再基于统一语言建立领域模型，这个领域模型会指导程序设计及编码实现，最后，又通过重构来发现隐式概念，并运用设计模式改进设计与开发质量。
 
领域驱动设计的整个设计过程主要分为两个阶段：战略设计阶段与战术设计阶段。
 
（一）战略设计
 
1.出发角度与目标
 
从业务视角出发，建立业务领域模型，划分领域边界，建立通用语言的限界上下文，限界上下文可以作为微服务设计的参考边界。
 
2.实现方式：事件风暴与模型确立（用例分析、场景分析和用户旅程分析）
 
DDD 战略设计会建立领域模型，领域模型可以用于指导微服务的设计和拆分。
 
事件风暴是建立领域模型的主要方法，它是一个从发散到收敛的过程。它通常采用用例分析、场景分析和用户旅程分析，尽可能全面不遗漏地分解业务领域，并梳理领域对象之间的关系，这是一个发散的过程。事件风暴过程会产生很多的实体、命令、事件等领域对象，我们将这些领域对象从不同的维度进行聚类，形成如聚合、限界上下文等边界，建立领域模型，这就是一个收敛的过程。
 
3.用三步来划定领域模型和微服务的边界
 
 
第一步：在事件风暴中梳理业务过程中的用户操作、事件以及外部依赖关系等，根据这些要素梳理出领域实体等领域对象。
 
第二步：根据领域实体之间的业务关联性，将业务紧密相关的实体进行组合形成聚合，同时确定聚合中的聚合根、值对象和实体。在这个图里，聚合之间的边界是第一层边界，它们在同一个微服务实例中运行，这个边界是逻辑边界，所以用虚线表示。
 
第三步：根据业务及语义边界等因素，将一个或者多个聚合划定在一个限界上下文内，形成领域模型。在这个图里，限界上下文之间的边界是第二层边界，这一层边界可能就是未来微服务的边界，不同限界上下文内的领域逻辑被隔离在不同的微服务实例中运行，物理上相互隔离，所以是物理边界，边界之间用实线来表示。
 
（二）战术设计
 
1.出发角度与目标
 
从技术视角出发，侧重于领域模型的技术实现，完成软件开发和落地，包括：聚合根、实体、值对象、领域服务、应用服务和资源库等代码逻辑的设计和实现。
 
2.实现方式：DDD 分层架构、整洁架构、CQRS 和六边形架构等  （我们采用DDD 分层架构）
 
从战略设计向战术设计的实施过程中，我们会将领域模型中的领域对象与代码模型中的代码对象建立映射关系，将业务架构和系统架构进行绑定。当我们去响应业务变化调整业务架构和领域模型时，系统架构也会同时发生调整，并同步建立新的映射关系。
 
微服务架构模型有好多种，例如DDD 分层架构、整洁架构、CQRS 和六边形架构等，其核心理念都是为了设计出“高内聚低耦合”的架构，轻松实现架构演进。而 DDD 分层架构的出现，使架构边界变得越来越清晰，它在微服务架构模型中，占有非常重要的位置。
 
DDD 分层架构包含用户接口层、应用层、领域层和基础层。通过这些层次划分，我们可以明确微服务各层的职能，划定各领域对象的边界，确定各领域对象的协作方式。
 
3.代码模型强调两点：聚合之间的代码边界一定要清晰+一定要有代码分层的概念
 
根据 DDD 分层架构模型建立了标准的微服务代码模型，在代码模型里面，各代码对象各据其位、各司其职，共同协作完成微服务的业务逻辑。
 
第一点：聚合之间的代码边界一定要清晰。
 
聚合之间的服务调用和数据关联应该是尽可能的松耦合和低关联，聚合之间的服务调用应该通过上层的应用层组合实现调用，原则上不允许聚合之间直接调用领域服务。这种松耦合的代码关联，在以后业务发展和需求变更时，可以很方便地实现业务功能和聚合代码的重组，在微服务架构演进中将会起到非常重要的作用。
 
第二点：一定要有代码分层的概念。
 
写代码时一定要搞清楚代码的职责，将它放在职责对应的代码目录内。应用层代码主要完成服务组合和编排，以及聚合之间的协作，它是很薄的一层，不应该有核心领域逻辑代码。领域层是业务的核心，领域模型的核心逻辑代码一定要在领域层实现。如果将核心领域逻辑代码放到应用层，你的基于 DDD 分层架构模型的微服务慢慢就会演变成传统的三层架构模型了。
 
二、理解和分析领域+子域+核心域+通用域+支撑域
 
（一）整体理解领域与子域的概念（以桃树生物学知识体系的建立为例来加深理解）
 
领域就是用来确定范围的，范围即边界，这也是 DDD 在设计中不断强调边界的原因。
 
DDD 的领域就是这个边界内要解决的业务问题域。
 
领域可以进一步划分为子领域。我们把划分出来的多个子领域称为子域，每个子域对应一个更小的问题域或更小的业务范围。
 
领域建模和微服务建设的过程和方法基本类似，其核心思想就是将问题域逐步分解，降低业务理解和系统实现的复杂度。
 
如何给桃树建立一个完整的生物学知识体系，它的研究过程如下：
 
 
--->确定研究对象，即研究领域，这里是一棵桃树           
 
      zyf@@@zyf  对应 DDD 的领域，研究的具体问题域
 
--->对研究对象进行细分，将桃树细分为器官，器官又分为营养器官和生殖器官两种。其中营养器官包括根、茎和叶，生殖器官包括花、果实和种子。
 
     zyf@@@zyf  具体问题域划分为两大问题域，根、茎、叶、花、果实和种子等器官则是细分后的问题子域。
 
                           DDD 将领域细分为多个子域的过程。      
 
--->对器官进行细分，将器官细分为组织。比如，叶子器官可细分为保护组织、营养组织和输导组织等。
 
      zyf@@@zyf  DDD 将子域进一步细分为多个子域。     
 
--->对组织进行细分，将组织细分为细胞，细胞成为我们研究的最小单元。细胞之间的细胞壁确定了单元的边界。
 
      zyf@@@zyf  DDD 将子域进一步细分确定研究的最小边界。
 
                            可以把细胞（细胞核、线粒体、细胞膜等物质）理解为 DDD 的聚合，细胞内的这些物质就可以理解为聚合里面的聚合根、实体以及值对象等。    
 
（二）理解核心域、通用域和支撑域的划分及具体目的
 
子域可以根据自身重要性和功能属性划分为三类子域，它们分别是：核心域、通用域和支撑域。
 
公司在 IT 系统建设过程中，由于预算和资源有限，对不同类型的子域应有不同的关注度和资源投入策略，记住好钢要用在刀刃上。很多公司的业务，表面看上去相似，但商业模式和战略方向是存在很大差异的，因此公司的关注点会不一样，在划分核心域、通用域和支撑域时，其结果也会出现非常大的差异。
 
比方都是电商平台的淘宝、天猫、京东和苏宁易购，他们的商业模式是不同，在面对各个子域的划分上侧重点都不一样！
 
1.核心域
 
最重要的，决定产品和公司核心竞争力的子域，它是业务成功的主要因素和公司的核心竞争力。
 
在公司领域细分、建立领域模型和系统建设时，我们就要结合公司战略重点和商业模式，找到核心域了，且重点关注核心域。
 
建议技术团队要将核心域的建设排在首位，最好是有绝对的掌控能力和自主研发能力！
 
2.通用域
 
没有太多个性化的诉求，同时被多个子域使用的通用功能子域是通用域。
 
通用域则是你需要用到的通用系统，比如认证、权限等等，这类应用很容易买到，没有企业特点限制，不需要做太多的定制化。
 
3.支撑域
 
既不包含决定产品和公司核心竞争力的功能，也不包含通用功能的子域，它就是支撑域。
 
支撑域则具有企业特性，但不具有通用性，例如数据代码类的数据字典等系统。
 
4.划分核心域、支撑域和通用域的主要目标
 
通过领域划分，区分不同子域在公司内的不同功能属性和重要性，从而公司可对不同子域采取不同的资源投入和建设策略，其关注度也会不一样。
 
三、理解和分析界限上下文,定义领域边界
 
在 DDD 领域建模和系统建设过程中，领域专家、产品经理、项目经理、架构师、开发经理和测试经理等对同样的领域知识，不同的参与角色可能会有不同的理解，避免交流障碍，DDD 中就出现了“通用语言”和“限界上下文”这两个重要的概念。
 
通用语言定义上下文含义，限界上下文则定义领域边界，以确保每个上下文含义在它特定的边界内都具有唯一的含义，领域模型则存在于这个边界之内。
 
（一）通用语言
 
在事件风暴过程中，通过团队交流达成共识的，能够简单、清晰、准确描述业务涵义和规则的语言就是通用语言。
 
通用语言包含术语和用例场景，并且能够直接反映在代码中。
 
通用语言中的名词可以给领域对象命名，如商品、订单等，对应实体对象；
而动词则表示一个动作或事件，如商品已下单、订单已付款等，对应领域事件或者命令。
下面是一个微服务设计实例的部分数据（也是后面实践的应用案例分析），表格中的这些名词术语就是项目团队在事件风暴过程中达成一致、可用于团队内部交流的通用语言。
 
 
在这个表格里面我们可以看到，DDD 分析过程中所有的领域对象以及它们的属性都被记录下来了，除了 DDD 的领域对象，
 
DDD 分析和设计过程中的每一个环节都需要保证限界上下文内术语的统一，在代码模型设计的时侯就要建立领域对象和代码对象的一一映射，从而保证业务模型和代码模型的一致，实现业务语言与代码语言的统一。还记录了在微服务设计过程中领域对象所对应的代码对象，并将它们一一映射。
 
（二）限界上下文
 
领域专家、架构师和开发人员的主要工作就是通过事件风暴来划分限界上下文。
 
可以将限界上下文拆解为两个词：限界和上下文。限界就是领域的边界，而上下文则是语义环境。
 
限界上下文的定义就是：用来封装通用语言和领域对象，提供上下文环境，保证在领域之内的一些术语、业务相关对象等（通用语言）有一个确切的含义，没有二义性。
 
业务的通用语言就有它的业务边界，我们不大可能用一个简单的术语没有歧义地去描述一个复杂的业务领域。限界上下文就是用来细分领域，从而定义通用语言所在的边界。
 
正如电商领域的商品一样，商品在不同的阶段有不同的术语，在销售阶段是商品，而在运输阶段则变成了货物。同样的一个东西，由于业务领域的不同，赋予了这些术语不同的涵义和职责边界，这个边界就可能会成为未来微服务设计的边界。看到这，我想你应该非常清楚了，领域边界就是通过限界上下文来定义的。
 
理论上限界上下文就是微服务的边界。我们将限界上下文内的领域模型映射到微服务，就完成了从问题域到软件的解决方案。
 
可以说，限界上下文是微服务设计和拆分的主要依据。在领域模型中，如果不考虑技术异构、团队沟通等其它外部因素，一个限界上下文理论上就可以设计为一个微服务。
 
四、理解和分析实体和值对象
 
（一）对于实体的具体理解
 
是一个具体类对象，它们拥有唯一标识符，且标识符在历经各种状态变更后仍能保持一致。
 
对这些对象而言，重要的不是其属性，而是其延续性和标识，对象的延续性和标识会跨越甚至超出软件的生命周期。我们把这样的对象称为实体。
 
具体从实体的业务形态、代码形态、运行形态和数据库形态去进一步理解：
 
1.实体的业务形态
 
领域模型中的实体是多个属性、操作或行为的载体。
 
在事件风暴中，我们可以根据命令、操作或者事件，找出产生这些行为的业务实体对象，进而按照一定的业务规则将依存度高和业务关联紧密的多个实体对象和值对象进行聚类，形成聚合。
 
实体和值对象是组成领域模型的基础单元。
 
2.实体的代码形态
 
代码模型中，实体的表现形式是实体类，这个类包含了实体的属性和方法，通过这些方法实现实体自身的业务逻辑。
 
在 DDD 里，这些实体类通常采用充血模型，与这个实体相关的所有业务逻辑都在实体类的方法中实现，跨多个实体的领域逻辑则在领域服务中实现。
 
3.实体的运行形态
 
实体以 DO（领域对象）的形式存在，每个实体对象都有唯一的 ID。
 
可以对一个实体对象进行多次修改，修改后的数据和原来的数据可能会大不相同。但是，由于它们拥有相同的 ID，它们依然是同一个实体。
 
4.实体的数据库形态
 
与传统数据模型设计优先不同，DDD 是先构建领域模型，针对实际业务场景构建实体对象和行为，再将实体对象映射到数据持久化对象。
 
在领域模型映射到数据模型时，一个实体可能对应 0 个、1 个或者多个数据库持久化对象。大多数情况下实体与持久化对象是一对一。
 
在某些场景中，有些实体只是暂驻静态内存的一个运行态实体，它不需要持久化。比如，基于多个价格配置数据计算后生成的折扣实体。
在有些复杂场景下，实体与持久化对象则可能是一对多或者多对一的关系。比如，用户 user 与角色 role 两个持久化对象可生成权限实体，一个实体对应两个持久化对象，这是一对多的场景。
有些场景为了避免数据库的联表查询，提升系统性能，会将客户信息 customer 和账户信息 account 两类数据保存到同一张数据库表中，客户和账户两个实体可根据需要从一个持久化对象中生成，这就是多对一的场景。
（二）对于值对象的具体理解
 
《实现领域驱动设计》一书中对值对象的定义：通过对象属性值来识别的对象，它将多个相关属性组合为一个概念整体。在 DDD 中用来描述领域的特定方面，并且是一个没有标识符的对象，叫作值对象。
 
值对象描述了领域中的一件东西，这个东西是不可变的，它将不同的相关属性组合成了一个概念整体。简单来说，值对象本质上就是一个集。在领域建模的过程中，值对象可以保证属性归类的清晰和概念的完整性，避免属性零碎。
 
 
举例：人员实体原本包括姓名、年龄、性别以及人员所在的省、市、县和街道等属性。这样显示地址相关的属性就很零碎了对不对？现在，我们可以将“省、市、县和街道等属性”拿出来构成一个“地址属性集合”，这个集合就是值对象了。
 
具体从实体的业务形态、代码形态、运行形态、数据库形态和值对象的优势和局限去进一步理解：
 
1.实体的业务形态
 
本质上，实体是看得到、摸得着的实实在在的业务对象，实体具有业务属性、业务行为和业务逻辑。
 
而值对象只是若干个属性的集合，只有数据初始化操作和有限的不涉及修改数据的行为，基本不包含业务逻辑。在逻辑上它仍然是实体属性的一部分，用于描述实体的特征。
 
值对象中也有部分共享的标准类型的值对象，它们有自己的限界上下文，有自己的持久化对象，可以建立共享的数据类微服务，比如数据字典。
 
2.实体的代码形态
 
代码模型中，有这样两种形态：
 
如果值对象是单一属性，则直接定义为实体类的属性；
如果值对象是属性集合，则把它设计为 Class 类，Class 将具有整体概念的多个属性归集到属性集合，这样的值对象没有 ID，会被实体整体引用。
 
3.实体的运行形态
 
实体实例化后的 DO 对象的业务属性和业务行为非常丰富，但值对象实例化的对象则相对简单和乏味。除了值对象数据初始化和整体替换的行为外，其它业务行为就很少了。
 
值对象嵌入到实体的话，有这样两种不同的数据格式，也可以说是两种方式，分别是属性嵌入的方式和序列化大对象的方式。
 
引用单一属性的值对象或只有一条记录的多属性值对象的实体，可以采用属性嵌入的方式嵌入。以上面的代码为例：
 
 
引用一条或多条记录的多属性值对象的实体，可以采用序列化大对象的方式嵌入。以上面的代码为例：
 
 
4.实体的数据库形态
 
DDD 引入值对象是希望实现从“数据建模为中心”向“领域建模为中心”转变，减少数据库表的数量和表与表之间复杂的依赖关系，尽可能地简化数据库设计，提升数据库性能。
 
值对象在数据库持久化方面简化了设计，它的数据库设计大多采用非数据库范式，值对象的属性值和实体对象的属性值保存在同一个数据库实体表中。
 
在这块建议的具体做法是：
 
在领域建模时，我们可以将部分对象设计为值对象，保留对象的业务涵义，同时又减少了实体的数量；
在数据建模时，我们可以将值对象嵌入实体，减少实体表的数量，简化数据库设计。
以上面的代码为例，在领域建模时，我们可以把地址作为值对象，人员作为实体，这样就可以保留地址的业务涵义和概念完整性。而在数据建模时，我们可以将地址的属性值嵌入人员实体数据库表中，只创建人员数据库表。
 
5. 值对象的优势和局限
 
值对象采用序列化大对象的方法简化了数据库设计，减少了实体表的数量，可以简单、清晰地表达业务概念。
 
这种设计方式虽然降低了数据库设计的复杂度，但却无法满足基于值对象的快速查询，会导致搜索值对象属性值变得异常困难。
 
值对象采用属性嵌入的方法提升了数据库的性能，但如果实体引用的值对象过多，则会导致实体堆积一堆缺乏概念完整性的属性，这样值对象就会失去业务涵义，操作起来也不方便。
 
在使用时要充分的考虑值对象的优缺点。
 
（三）对于实体与值对象关系的理解
 
1.基本的关系理解
 
实体和值对象是微服务底层的最基础的对象，一起实现实体最基本的核心领域逻辑。
 
DDD 提倡从领域模型设计出发，而不是先设计数据模型。传统的数据模型设计通常是一个表对应一个实体，一个主表关联多个从表，当实体表太多的时候就很容易陷入无穷无尽的复杂的数据库设计，领域模型就很容易被数据模型绑架。可以说，值对象的诞生，在一定程度上，和实体是互补的。
 
2.不同场景下关系的不同
 
 
同样的对象在不同的场景下，可能会设计出不同的结果。
 
有些场景中，地址会被某一实体引用，它只承担描述实体的作用，并且它的值只能整体替换，这时候你就可以将地址设计为值对象，比如收货地址。
 
而在某些业务场景中，地址会被经常修改，地址是作为一个独立对象存在的，这时候它应该设计为实体，比如行政区划中的地址信息维护。
 
五、理解和分析聚合思想:聚合和聚合根
 
在事件风暴中，我们会根据一些业务操作和行为找出实体（Entity）或值对象（ValueObject），进而将业务关联紧密的实体和值对象进行组合，构成聚合，再根据业务语义将多个聚合划定到同一个限界上下文（Bounded Context）中，并在限界上下文内完成领域建模。
 
（一）对聚合的理解和分析
 
聚合就是由业务和逻辑紧密关联的实体和值对象组合而成的，聚合是数据修改和持久化的基本单元，每一个聚合对应一个仓储，实现数据的持久化。
 
聚合有一个聚合根和上下文边界，这个边界根据业务单一职责和高内聚原则，定义了聚合内部应该包含哪些实体和值对象，而聚合之间的边界是松耦合的。
 
聚合在 DDD 分层架构里属于领域层，领域层包含了多个聚合，共同实现核心业务逻辑。
 
聚合内实体以充血模型实现个体业务能力，以及业务逻辑的高内聚。跨多个实体的业务逻辑通过领域服务来实现，跨多个聚合的业务逻辑通过应用服务来实现。
 
（二）对聚合根的理解和分析
 
聚合根的主要目的是为了避免由于复杂数据模型缺少统一的业务规则控制，而导致聚合、实体之间数据不一致性的问题。
 
如果把聚合比作组织，那聚合根就是这个组织的负责人。聚合根也称为根实体，它不仅是实体，还是聚合的管理者。
 
首先它作为实体本身，拥有实体的属性和业务行为，实现自身的业务逻辑。
其次它作为聚合的管理者，在聚合内部负责协调实体和值对象按照固定的业务规则协同完成共同的业务逻辑。
最后在聚合之间，它还是聚合对外的接口人，以聚合根 ID 关联的方式接受外部任务和请求，在上下文内实现聚合之间的业务协同。
（三）聚合、聚合根、实体、值对象的对比
 
 
 
聚合
 
*高内聚、低耦合，它是领域模型中最底层的边界，可以作为拆分微服务的最小单位，但不建议你对微服务过度拆分。
 
*在对性能有极致要求的场景中，聚合可以独立作为一个微服务，以满足版本的高频发布和极致的弹性伸缩能力。
 
*一个微服务可以包含多个聚合，聚合之间的边界是微服务内天然的逻辑边界。
 
聚合根
 
*聚合根是实体，有实体的特点，具有全局唯一标识，有独立的生命周期。
 
*一个聚合只有一个聚合根，聚合根在聚合内对实体和值对象采用直接对象引用的方式进行组织和协调，聚合根与聚合根之间通过 ID 关联的方式实现聚合之间的协同。
 
实体
 
*有 ID 标识，通过 ID 判断相等性，ID 在聚合内唯一即可。
 
*状态可变，它依附于聚合根，其生命周期由聚合根管理。
 
*实体一般会持久化，但与数据库持久化对象不一定是一对一的关系。
 
*实体可以引用聚合内的聚合根、实体和值对象。
 
值对象
 
*无 ID，不可变，无生命周期，用完即扔。
 
*值对象之间通过属性值判断相等性。
 
*核心本质是值，是一组概念完整的属性组成的集合，用于描述实体的状态和特征。
 
*值对象尽量只引用值对象。
 
（四）基本理解综合
 
实体和值对象都只是个体化的对象，它们的行为表现出来的是个体的能力。实体一般对应业务对象，它具有业务属性和业务行为；而值对象主要是属性集合，对实体的状态和特征进行描述。
 
领域模型内的实体和值对象就好比个体，而能让实体和值对象协同工作的组织就是聚合，它用来确保这些领域对象在实现共同的业务逻辑时，能保证数据的一致性。一个聚合只有一个聚合根，聚合根在聚合内对实体和值对象采用直接对象引用的方式进行组织和协调，聚合根与聚合根之间通过 ID 关联的方式实现聚合之间的协同。聚合根是实体，有实体的特点，具有全局唯一标识，有独立的生命周期。
 
六、理解很分析领域事件来解耦微服务
 
领域事件是领域模型中非常重要的一部分，用来表示领域中发生的事件。一个领域事件将导致进一步的业务操作，在实现业务解耦的同时，还有助于形成完整的业务闭环。
 
（一）领域事件的识别
 
我们在做事件风暴的时候，进行用户旅程或者场景分析时，我们要捕捉业务、需求人员或领域专家口中的关键词：“如果发生……，则……”“当做完……的时候，请通知……”“发生……时，则……”等。在这些场景中，如果发生某种事件后，会触发进一步的操作，那么这个事件很可能就是领域事件。
 
领域事件驱动设计可以切断领域模型之间的强依赖关系，事件发布完成后，发布方不必关心后续订阅方事件处理是否成功，这样可以实现领域模型的解耦，维护领域模型的独立性和数据的一致性。
 
在领域模型映射到微服务系统架构时，领域事件可以解耦微服务，微服务之间的数据不必要求强一致性，而是基于事件的最终一致性。
 
（二）微服务内外的领域事件分析
 
1. 微服务内的领域事件
 
当领域事件发生在微服务内的聚合之间，领域事件发生后完成事件实体构建和事件数据持久化，发布方聚合将事件发布到事件总线，订阅方接收事件数据完成后续业务操作。
 
微服务内大部分事件的集成，都发生在同一个进程内，进程自身可以很好地控制事务，因此不一定需要引入消息中间件。
 
但一个事件如果同时更新多个聚合，按照 DDD“一次事务只更新一个聚合”的原则，你就要考虑是否引入事件总线。
 
但微服务内的事件总线，可能会增加开发的复杂度，因此你需要结合应用复杂度和收益进行综合考虑。
 
微服务内应用服务，可以通过跨聚合的服务编排和组合，以服务调用的方式完成跨聚合的访问，这种方式通常应用于实时性和数据一致性要求高的场景。这个过程会用到分布式事务，以保证发布方和订阅方的数据同时更新成功。
 
2. 微服务之间的领域事件
 
跨微服务的领域事件会在不同的限界上下文或领域模型之间实现业务协作，其主要目的是实现微服务解耦，减轻微服务之间实时服务访问的压力。
 
跨微服务的事件可以推动业务流程或者数据在不同的子域或微服务间直接流转。
 
跨微服务的事件机制要总体考虑事件构建、发布和订阅、事件数据持久化、消息中间件，甚至事件数据持久化时还可能需要考虑引入分布式事务机制等。
 
微服务之间的访问也可以采用应用服务直接调用的方式，实现数据和服务的实时访问，弊端就是跨微服务的数据同时变更需要引入分布式事务，以确保数据的一致性。
 
分布式事务机制会影响系统性能，增加微服务之间的耦合，所以我们还是要尽量避免使用分布式事务。
 
（三）领域事件总体架构
 
领域事件总体技术架构图，领域事件处理包括：事件构建和发布、事件数据持久化、事件总线、消息中间件、事件接收和处理等。
 
 
1. 事件构建和发布
 
事件基本属性至少包括：事件唯一标识、发生时间、事件类型和事件源，其中事件唯一标识应该是全局唯一的，以便事件能够无歧义地在多个限界上下文中传递。
 
事件基本属性主要记录事件自身以及事件发生背景的数据。
 
事件基本属性和业务属性一起构成事件实体，事件实体依赖聚合根。领域事件发生后，事件中的业务数据不再修改，因此业务数据可以以序列化值对象的形式保存，这种存储格式在消息中间件中也比较容易解析和获取。
 
事件发布之前需要先构建事件实体并持久化。
 
事件发布的方式有很多种，你可以通过应用服务或者领域服务发布到事件总线或者消息中间件，也可以从事件表中利用定时程序或数据库日志捕获技术获取增量事件数据，发布到消息中间件。
 
2. 事件数据持久化
 
事件数据持久化可用于系统之间的数据对账，或者实现发布方和订阅方事件数据的审计。
 
事件数据持久化有两种方案，在实施过程中你可以根据自己的业务场景进行选择：
 
持久化到本地业务数据库的事件表中，利用本地事务保证业务和事件数据的一致性。
持久化到共享的事件数据库中。这里需要注意的是：业务数据库和事件数据库不在一个数据库中，它们的数据持久化操作会跨数据库，因此需要分布式事务机制来保证业务和事件数据的强一致性，结果就是会对系统性能造成一定的影响。
3. 事件总线 (EventBus)
 
事件总线是实现微服务内聚合之间领域事件的重要组件，它提供事件分发和接收等服务。
 
事件总线是进程内模型，它会在微服务内聚合之间遍历订阅者列表，采取同步或异步的模式传递数据。
 
事件分发流程大致如下：
 
如果是微服务内的订阅者（其它聚合），则直接分发到指定订阅者；
 
如果是微服务外的订阅者，将事件数据保存到事件库（表）并异步发送到消息中间件；
 
如果同时存在微服务内和外订阅者，则先分发到内部订阅者，将事件消息保存到事件库（表），再异步发送到消息中间件。
 
4. 消息中间件
 
跨微服务的领域事件大多会用到消息中间件，实现跨微服务的事件发布和订阅。
 
5. 事件接收和处理
 
微服务订阅方在应用层采用监听机制，接收消息队列中的事件数据，完成事件数据的持久化后，就可以开始进一步的业务处理。
 
领域事件处理可在领域服务中实现。
 
（四）具体案例分析
 
领域事件是 DDD 的一个重要概念，在设计时我们要重点关注领域事件，用领域事件来驱动业务的流转，尽量采用基于事件的最终一致，降低微服务之间直接访问的压力，实现微服务之间的解耦，维护领域模型的独立性和数据一致性。
 
这里的具体用例结合后面的案例一起讲解，此处先预留。
 
 
 
参考书籍、文献和资料
 
1.极客时间课程《DDD实战》，欧创新，2019.
 
2.郑天民. 微服务设计原理与架构. 北京：人民邮电出版社，2018.
 
3.陈超、秦金卫、张逸等. 高可用可伸缩微服务架构. 电子工业出版社. 2019.
 
4.Eric Evans. 领域驱动设计-软件核心复杂性应对之道。 人民邮电出版社. 2018.