共计 3864 个字符，预计需要花费 10 分钟才能阅读完成。
开发简单业务零碎，有哪些设计思路
最近参加了一些电商业务中台等简单业务零碎的设计和开发，联合 DDD 和中台等，
有一些架构方面的思考和领会，在这里记录一下。
做技术计划，外围是上面几个问题：
做什么？- 产品需要
业务上怎么做？- 业务文档
技术上怎么做？- 技术计划
代码怎么实现？- 落地实现
明确了这几个问题，能够解决大部分日常需要开发，如果是比较复杂的业务零碎，就须要拆解的更精密。
比方电商的商品治理、订单交易、促销流动营销中心等零碎的开发和重构，业务绝对简单，开发人天在几个月以上，间接开发可能会老虎啃天，无从下手。
这时候能够通过一个流程化的模板来领导，如果形象一个通用的流程，能够参考上面的套路：
业务拆解 > 复杂度起源 > 外围挑战点
畛域驱动设计 > 业务过程剖析 > 畛域模型形象 > 模型合成
分层组织 > 工程架构 > 模块化 > 组件化
思考性能复用 > 可选门路 —（业务身份，能力，扩大点，工作流程，编排）
计划产出 > 整体 - 模块 - 流程 - 细节 > 计划评审 > 最终计划
其中的性能复用环节，是包含阿里在内的大部分业务中台的解决思路，仅供参考。
一、业务拆解
1.1 复杂度起源
为什么要关注复杂度？
我比拟认同零碎设计中「软件复杂度」的观点，架构设计的目标是为了解决软件系统的复杂度带来的问题，所以在设计架构时，首先就要剖析零碎的复杂度。
只有正确剖析出了零碎的复杂性，后续的架构设计计划才不会偏离方向；
否则，如果对系统的复杂性判断谬误，即便后续的架构设计计划再完满再先进，都是背道而驰，做的越好，错的越多、越离谱。
举个例子，医院治理利用的医疗管理系统（HIS），复杂度在于业务逻辑简单，零碎之间调用不清晰，
如果你设计一个 QPS 几万的高性能架构，就是没有解决零碎的外围问题。
正确的做法是将次要的复杂度问题列出来，而后依据业务、技术、团队等综合状况进行排序，优先解决以后面临的最次要的复杂度问题。
1.2 外围挑战点
射人先射马，擒贼先擒王。
确定了复杂度，也就确定了零碎设计的难点，在进行零碎设计时，能够把难点列出来，各个击破。
以优惠券为例，促销流动最大的复杂度来自营销状态的变动，营销最大的不变就是变，乱花渐欲迷人眼，各类促销形式变幻无穷。
每次促销流动都有不同的玩法和定义，促销零碎的设计必须对促销模式有所形象，任何流动或优惠伎俩都是基于最根本的促销模式而建设的。
电商促销流动和优惠券建设难点包含：
底层模型形象：底层模型形象能够通过 DDD 的形式，对畛域模型和进行形象。
促销引擎性能：性能问题如何解决？曾经是陈词滥调，工程畛域有很多经典的解决方案，比方缓存，异步，最终一致性。
关联系统交互：理清和关联系统的交互
二、畛域驱动设计
软件系统的目标反映在业务上，都是来解决一系列问题，例如考试零碎实现考试，电商就是卖货，
同一个畛域的零碎都具备雷同的外围业务，因为他们要解决的问题的实质是相似的，一个畛域实质上能够了解为一个问题域。
只有确定了零碎所属的畛域，那么这个零碎的外围业务，即要解决的关键问题就根本确定了。
任何一个零碎都会属于某个特定的畛域，例如论坛零碎，外围性能是确定的，比方用户发帖，回帖等基本功能。
狭义的电商零碎也是一个畛域，做电商业务，必须要反对的商品，订单，交易，物流等性能。
多说一句，畛域驱动设计自身有一堆操作，我感觉不要把简略的问题复杂化了，畛域驱动设计不是银弹，也没必要妖魔化。
作为指导思想，在实际操作中，要具体问题具体分析，综合采纳其它各种设计办法。
2.1 畛域模型设计
DDD 里有领域专家的概念，领域专家要在这个畛域深入研究，只有这样才会遇到十分多的该畛域的问题，积攒比拟更加丰盛的教训。
通常来说，一个畛域有且只有一个外围问题，也就是外围子域。在外围子域、通用子域、撑持子域梳理的同时，会定义出子域中的限界上下文及其关系，用它来论述子域之间的关系。
以电商营销为例，优惠券、抽奖、套餐等，都是围绕这个促销这个业务范围来进行的，在促销域之外，还有相干的用户、商品、订单、风控、商家等。
三、架构分层
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.1 编程 DRY 准则
大家都晓得，编写整洁代码，有一个十分重要的准则就是 DRY，
Don’t Repeat Yourself，防止产生反复代码，有教训的程序员都可能意识到这一条束缚。
如果你应用 Idea 开发，Idea 也会辨认并且提醒你反复的代码，倡议你进行形象。
DRY 的益处更少的代码是好的，它节俭了工夫和精力，易于保护，并且缩小了 bug 的几率。
除了在软件开发畛域，在业务零碎层面，也存在如何防止反复能力建设，思考业务复用的问题。
4.2 业务层面的 DRY
业务零碎层面的 DRY 准则，其实能够总结为一个问题，就是简单业务零碎，如何实现具备共性的业务能力的复用，这个也是很多业务中台关注的问题。
个别的，大部分业务中台（特指业务中台，不包含数据中台等其余状态）对业务复用的形式，
都能够通过定义业务身份 ——> 梳理扩大点 ——> 枚举业务能力 ——> 依据不同业务身份编排工作流 ——> 实现业务能力复用，这样的流程来实现。
能够比照编程中的 Pipeline 模式，或者责任链模式，只不过每个链条上负责解决输出和输入的，是不同的业务性能。
业务中台是另一个话题，这部分是发散思考，具体能够参考阿里巴巴 TMF（Trade Mudule Framework）框架的介绍：
如何实现 32.5 万笔 / 秒的交易峰值？阿里交易系统 TMF2.0 技术揭秘
五、可扩展性和适度设计如何均衡
好的架构设计肯定是扩大简略的。
在设计时，要尽量封装可能的变动，在业务流程产生一些调整时，可能比拟不便地批改零碎程序模块或组件间的调用关系而实现新的需要，也就是咱们常说的可扩展性。
然而可扩展性自身也是零碎设计的复杂度起源之一，这就波及到一个问题，如何均衡可扩大和适度设计。
5.1 辨别确定性和变动
好的架构肯定是扩大简略，运行安稳的。
零碎架构最开始能够从一个通用的流程开始，case-by-case，
而后将「变动少」的局部积淀下来为架构，将「变动多」的积淀为扩大或者配置，梳理分明，将这两者联合起来，最初实现零碎架构设计。
5.2 用容量布局的形式来解决扩大水平
能够应用容量布局的思维，来解决可扩展性设计。
在做技术计划时，容量布局是一个特地重要的环节，要预估将来几年的增长量，进行数据库和缓存的容量布局。
我感觉这个形式也能够利用在扩展性设计上，对业务变动进行预期，思考技术计划可能反对的业务倒退工夫。
六、计划评审
好的技术计划很难欲速不达，大部分时候要通过重复的调整，就是须要关联的各方参加计划的评审和批改，最终确定最终技术计划。
我的倡议是，团队最好输入一份技术计划的标准，能够供每个成员参考，从设计阶段，就对立团队成员的意识。
七、总结
最初再总结一下，对于简单业务零碎开发的一些领会：
熟悉业务，形象产品需要，剖析相干测试用例，理解各种用户角色和其应用的场景
自顶向下进行方案设计，对于比较复杂的业务零碎，比拟好的形式是先关注顶层模型，防止在一开始就陷入技术和业务细节中去
从整体设计，到模块部分布局，设计好部署架构、分层和分模块、API 设计、数据库设计等
能够参考成熟的解决方案，比方将开源软件，革新，变成适宜本人业务需要的架构
验证和优化架构设计计划，残缺的架构设计计划，须要有屡次的评审，充沛收集各方面的反馈，重复批改后确定
正当进行扩大，思考架构预期能满足多长时间的业务增长，比方将来一年的业务变动
如果本文对你有帮忙，别忘记给我个 3 连，点赞，转发，评论，
咱们下期见！答案获取形式：已赞 已评 已关~
