大数据|成熟的项目架构设计是什么样的? 人工智能|数据库|编程语言|j

文章图片

有网友花了两个月时间做了一个 b2c 商城，技术栈是 sass、jquery、thinkphp，一套摸索下来后，遇到非常多的问题。例如：对项目开发流程等没概念、不知道去哪里查找相关资料。因此他提出来几个问题：

项目开发流程的基本组成部分有哪些？
如何在初期确定项目整体的运作模型？
如何设计数据模型？

以下是这位网友在项目初期的一些脑图，由于设计问题，其中退货、优惠券、折扣部分最终并未完成：

文章图片

文章图片

针对这些问题，淘系技术架构师勇剑同学写出本文一一解答。

项目开发流程的基本组成部分有哪些？对于项目开发流程，我的理解，与这位网友实际上大致上是差不多的，不过一般团队里面，都会有业务、产品、服务端、前端、客户端、测试等角色，所以相对整体的沟通成本会高很多，整体的流程大致上是：需求评审、技术方案评审/项目排期、测试用例评审、开发、测试、功能预演、发布上线、线上灰度/放量。
实际上这位网友所提到的 “设计整体业务流程” 这一步应该是在技术介入之前就要由产品与业务提前沟通确认好的。“设计数据模型” 应该归属到技术方案这一步里面，是其中的一部分。

整个流程对于技术开发同学来说，重点需要关注需求评审、技术方案设计这两大部分，简单谈一下我的一些看法。

关于需求，之前看过一段马斯克的工作理念介绍，觉得非常不错，讲的是需求迭代的过程，建议按照下面五步：

制定需求的时候，让你的需求别那么蠢（哈哈，也就是希望需求尽量合理，不要做出来了发现没什么用）
尝试删除部件或过程，这一步可以让你知道最核心的部件与过程是什么。
优化，只有到了第三步，才是优化，不要第一步就优化，让你的优化集中在必要的部件与过程上，这是很多工程师容易搞错的地方。
加速前三部循环的时间，你的动作太慢了，更快一点～，在这前，不要加速
最后一步是自动化

前三步对于我们在一些业务需求的制定上，可以提供一些比较好的参考，在实际项目过程中，也让我们思考什么是我们的核心需求，把有限的人力集中到我们必须要做的事情上面去，拿到更好的成果。

另外一点是关于技术方案设计，我觉的是没有一个固定的模版的，重点是要讲清楚在整个技术设计过程中更需要关注的核心技术问题，包括但不限于技术选型、业务交互时序图、实体状态机、数据建模、应用/物理/业务架构，以及高可用保障、稳定性风险等等。
如何在初期确定项目整体的运作模型？即对项目整体的前期设计？这个问题的本质实际上是一个领域建模的问题，回到题主的第一张图，在领域建模的时候，我的理解是，先要理清我们业务的核心实体，也就是领域实体，在这张图里面，我们可以清晰看出三部分：用户、商品、订单（当然也可以更细化到一些实体：购物车、物流单、评价等等，这里只是简单举例），体现在设计上，整个业务的应用架构必然需要三大中心：用户中心、商品中心、订单中心。当模型确认之后，模型自身的行为以及模型之间的关系也就随之确定。

文章图片

题主的这个图，看主要是用来介绍整体一些业务流程，包括：实体、用户行为、逻辑判断等等，对于这些建议是通过“时序图”来描述相对会更好一点，可以相对更加清晰的来描述系统、对象、对象与系统的交互行为。

简单画了一下用户与几个系统的关系与交互，可以看出需要哪些系统、这些系统需要哪些能力、用户如何与这些系统之间完成交互。

文章图片

PS：这里画的不太全，忽略了所有异常逻辑的处理以及数据一致性问题，包括在用户建单之后，后续的支付流程、以及后续订单的状态机流程这里都没在详细画了，只是简单给个 Demo。

关于“用户中心”这块，注册/登录/登出/修改个人信息这几大部分维护在用户中心是 OK 的，但是优惠券、订单记录查询、订单评论这几部分放在这里感觉不太合适，优惠券属于营销域，应该是归属于一个营销域的“卡券”（coupon）子系统，由该系统提供根据用户 ID 查询优惠券的能力即可。订单记录及查询维护在“订单中心”会更合适一些，至于“评论”，也可以放到一个单独的子系统里面去。

文章图片

简而言之就是根据业务诉求确定系统的领域模型，再对各个领域进行职责划分、功能拆解，之后就是逐渐完善各个子域了。整个项目的架子搭好之后，后续的功能扩展也会相对比较简单。
如何设计数据模型？或者说怎么设计数据表？
数据库的设计第一步首先要搞清业务诉求，有时候不同的业务需求会导致数据建模存在较大的差异，这一点是我们需要在做设计之前明确的。

之后就是根据业务形态，确定领域实体，比如电商涉及到的商品、订单、用户等等，商品域内又包含SPU、SKU、类目信息等等。

题主提到的根据前端功能需求来设计数据模型，对于简单的需求来说，是可以的，但对于复杂业务如果这样设计，后续如果前端功能需求发生变动，那么对整个系统的改造也是灾难性的，建议建立起一套稳健的领域模型，将前端需求与底层存储做好防腐和解耦。在DB层的建模做好适当的抽象、冗余等处理，数据在系统里面通过领域实体流转，对于页面只是一个实体的VO渲染即可。

另外数据表的设计，需要考虑各方面因素，比如数据量的预估（是否需要分库分表）、存储方式（存储技术选型）、有没有热点数据、预留未来扩展的可能性等等

关于 DB 建模，建议采用 ER 图来设计，数据表的关联关系展现的会相对清晰一些。下面是一个简单的 Demo