开发复杂业务系统，有什么设计思路你最近参与了电商业务中台等一些复杂业务系统的设计开发，结合??DDD还有mid-stage等等，还有一些架构方面的，在这里记录下你的想法和经历。做一个技术方案，核心是以下几个问题：做什么？-如何在产品需求上做生意？-如何从技术上做好商务文件？-如何实现技术方案代码？-落地的实现理清了这些问题，可以处理大部分的日常需求开发。如果是更复杂的业务系统，就需要拆得更细。例如电子商务产品管理、订单交易、促销营销中心等系统的开发与改造。业务比较复杂，开发人力多几个月。直接发育可能吃不饱。这时候可以用一个流程模板来指导。如果抽象一个通用流程，可以参考以下套路：业务拆解>复杂性来源>核心挑战领域驱动设计>业务流程分析>领域模型抽象>模型分解层次组织>工程架构>模块化>考虑功能复用的组件化>AlternativePaths—(BusinessIdentity,Capabilities,ExtensionPoints,Workflows,Orchestration)SchemeOutput>Overall-Module-Process-Details>SchemeReview>最终方案中的功能复用环节是大部分业务平台的解决思路包括阿里，仅供参考。1.业务拆解1.1复杂性的来源为什么要关注复杂性？我同意系统设计中“软件复杂性”的观点。架构设计的目的是解决软件系统的复杂性所带来的问题。因此，在设计架构时，首先要分析系统的复杂度。只有正确分析了系统的复杂度，后续的架构设计方案才不会偏离方向；否则，如果对系统复杂度的判断有误，无论后续的架构设计方案多么完善和先进，都会适得其反，越做越好。嗯，错误越多，越离谱。例如，医院管理应用的医疗管理系统（HIS）的复杂性在于业务逻辑复杂，系统间调用不清晰。如果你设计一个QPS上万的高性能架构，并不能解决系统的核心问题。正确的做法是列出主要的复杂性问题，然后根据业务、技术、团队等综合情况进行排序，优先解决当前面临的最重要的复杂性问题。1.2核心挑战是先射人先射马，捉贼先擒王。复杂度确定了，系统设计的难点也就确定了。设计系统时，可将难点列举出来，一一克服。以优惠券为例，促销活动最大的复杂性来自于营销形式的变化。营销最大的不变就是变化。随机花越来越吸引人，各种促销方式也千变万化。每个促销活动都有不同的玩法和定义。促销系统的设计必须抽象促销模型。任何活动或优惠手段都是建立在最基本的促销模式之上的。构建电商促销活动和优惠券的难点包括：底层模型的抽象：底层模型的抽象可以通过DDD对领域模型进行抽象。提升引擎性能：如何解决性能问题？已经是老生常谈了，工程领域有很多经典方案，比如缓存、异步、最终一致性。相关系统交互：明确与相关系统的交互2、领域驱动设计软件系统的目的体现在业务上，就是解决一系列的问题，比如考试系统完成考试，电子商务是卖货，同一个领域的系统都有相同的核心业务，因为他们要解决的问题的性质是相似的，一个领域本质上可以理解为一个问题领域。只要确定了系统所属的领域，系统的核心业务，即要解决的关键问题就基本确定了。任何系统都会属于一个特定的领域，比如论坛系统，其核心功能是一定的，比如用户发帖、回复等基本功能。广义的电子商务系统也是一个领域。做电商业务，必须支持商品、订单、交易、物流等功能。还有一点，领域驱动设计本身就有很多操作。我认为没有必要把简单的问题复杂化。领域驱动设计不是灵丹妙药，没有必要妖魔化它。作为指导思想，在实际操作中，需要具体问题具体分析，综合采用其他各种设计方法。2.1领域模型设计DDD有领域专家的概念。领域专家需要在该领域进行深入研究。只有这样，他们才能在这个领域遇到很多问题，积累更丰富的经验。一般来说，一个领域只有一个核心问题，即核心子领域。在梳理核心子域、通用子域、支撑子域的同时，定义子域中的限界上下文及其关系，用于说明子域之间的关系。以电商营销为例，优惠券、抽奖、礼包等都是围绕此次促销的业务范围进行的。推广领域之外，还有相关的用户、产品、订单、风控、商户等。3.架构分层3.1架构分层下图是领域驱动设计中经典的分层架构：用户界面/展示层：请求应用层获取用户需要的展示数据；向应用层发送命令以执行用户的命令应用层：定义软件应该完成什么的薄层。对外为表现层提供各种应用功能，对内调用领域层（领域对象或领域服务）完成各种业务逻辑。应用层不包括业务逻辑领域层：表达业务概念、业务状态信息和业务规则，是业务软件的核心基础设施层：为其他层和层间通信提供通用技术能力；为域层机制提供持久化。这是一个比较简单的分层架构，其实是老生常谈，那么问题来了，我们上面拆解的领域模型如何映射到更复杂的工程架构上呢？3.2工程架构DDD的核心需求是将业务架构映射到系统架构。当因业务变化而调整业务架构时，系统架构也会随之发生变化。微服务在业务层面追求复用，设计的系统架构与业务一致，但领域模型并不直接反映数据结构，这一点需要明确。领域驱动设计最终落地到数据存储上，无需直接引用领域模型，可以自由选择适合最终技术架构的技术架构。3.3模块组织Java项目一般都是典型的Maven多模块项目，可以使用不同的Module来区分各个层级，进而通过Package来控制DDD中的限界上下文。3.4当领域对象封装特定的领域对象时，通常存在拥塞和贫血模型。由于大部分程序员习惯于在Service中封装业务逻辑贫血模型，完整的拥塞模型开发效率比较低。我自己的经验是，技术服务业务是第一位的，开发时可以灵活选择实施策略。模型对象封装了一些简单的静态方法，大部分业务逻辑仍然在领域服务中实现。3.5代码模型DDD是一种指导思想，没有标准的代码模型。而且我觉得团队成员水平不同，编码习惯也不同。如果打着DDD的旗号在编码过程中加入很多约束，那就有点浪费时间了。一般来说，可以通过一些脚手架工具自定义一个比较通用的代码模板，比如阿里巴巴的https://start.aliyun.com/boot...脚手架生成。下面是一个简单的代码模型，可以作为参考：4.考虑函数复用4.1编程DRY原则大家都知道写干净代码的时候，一个很重要的原则就是DRY，Don'tRepeatYourself，避免代码重复，有经验的程序员都知道这个约束。如果你使用Idea开发，Idea也会识别并提示你重复的代码，建议你进行抽象。DRYLesscode的好处是好的，它可以节省时间和精力，更容易维护，减少出现bug的机会。除了软件开发领域，在业务系统层面，也存在如何避免重复能力建设和考虑业务复用的问题。4.2业务层面的DRY业务系统层面的DRY原则其实可以概括为一个问题，即如何在复杂的业务系统中实现通用业务能力的复用，这也是很多业务平台关注的问题。一般情况下，大部分业务平台（具体业务平台，不包括数据平台等形式）都可以通过定义业务标识-->梳理扩展点-->枚举业务能力——>根据不同的业务标识安排工作流-->实现服务复用实现业务能力的复用，实现了这样一个流程。可以类比编程中的Pipeline模式或者责任链模式，但是每条链负责处理输入和输出，这是不同的业务功能。业务平台是另一个话题。这部分是发散思维。详见阿里巴巴TMF（TradeMuduleFramework）框架介绍：如何实现每秒32.5万笔交易的交易峰值？阿里交易系统TMF2.0技术揭秘5、如何平衡可扩展性和过度设计一个好的架构设计一定是易于扩展的。设计时，需要尽可能封装可能发生的变化。当业务流程发生一些调整时，相对容易修改系统程序模块或组件之间的调用关系来实现新的需求，也就是我们常说的可扩展性。但可扩展性本身也是系统设计复杂性的来源之一，这涉及到一个如何平衡可扩展性和过度设计的问题。5.1确定性和变化的区分一个好的架构必须易于扩展和流畅运行。系统架构可以从一个通用的流程开始，case-by-case，然后把“变化少”的部分沉淀到架构中，“变化多”的部分沉淀到扩展或配置中，梳理清楚，把两者结合起来，最终完成系统架构设计。5.2使用容量规划来处理扩展性设计你可以使用容量规划的思想来处理扩展性设计。在制定技术方案时，产能规划是一个特别重要的环节。需要预估未来几年的增长，对数据库和缓存进行容量规划。我认为这种方法也可以应用于可扩展性设计，预测业务变化，并考虑技术方案可以支持的业务发展时间。6、方案评审好的技术方案很难一蹴而就。很多时候需要经过反复调整，即需要各方共同参与方案的评审和修改，最终确定最终的技术方案。我的建议是，团队最好输出一个技术方案的规范，可以作为每个成员的参考，从设计阶段统一团队成员的理解。7、总结最后，总结一些复杂业务系统开发的经验：熟悉业务，抽象产品需求，分析相关测试用例，了解各种用户角色及其使用场景，自上而下设计解决方案。对于比较复杂的业务系统，更好的做法是先关注顶层模型，避免一开始就纠缠于技术和业务细节，从整体设计到模块的局部规划，设计部署架构、分层和子模块、API设计、数据库可以参考成熟的方案进行设计，比如将开源软件转化为适合自己业务需求的架构验证和优化架构设计方案。一个完整的架构设计方案需要经过多次评审，充分收集各方面的反馈。反复修改后，一定要合理扩展，考虑架构预计能满足业务增长多长时间，比如明年的业务变化。如果这篇文章对你有帮助，别忘了给我三连，点赞、转发、评论，我们下期再见！获取方式：点赞、评论、关闭~
