千妙科技客服咨询
实验室
[实验室] 从商业角度考虑低代码
在当今的软件开发领域中，低代码无代码平台（LCAP）正逐渐成为一种流行的开发方式。然而，尽管低代码无代码平台具有许多优势，我们仍然看到许多组织和个人选择采用传统的代码式开发方法。本文将探讨这一现象的原因，并阐述相关的软件著作权、知识产权、市场竞争、企业数字化和商业方面的考虑。首先，让我们了解一下低代码无代码平台。低代码无代码平台是一种使开发者可以通过拖拽组件和模型构建应用的开发环境，而不需要进行复杂的代码编写。使用低代码无代码平台，开发者可以快速构建应用程序，减少开发成本，加快上市时间。无代码平台甚至可以让业务人员直接进行应用开发，无需依赖专业的程序员。然而，尽管低代码无代码平台具有这些明显的优势，为什么还有许多组织和个人选择采用传统的代码式开发方法呢？知识产权首先，软件著作权和知识产权的问题可能影响到采用低代码无代码平台的效果。当使用低代码无代码平台时，用户可能需要将一部分的软件著作权和知识产权交给平台提供商。因为低代码无代码平台是一个集成的开发环境，包括了许多由平台提供商开发和管理的组件和模型，这些组件和模型可能受到知识产权保护。相比之下，传统的代码式开发方法可以让开发团队更好地掌控软件的著作权和知识产权。开发者可以完全控制代码的各个方面，包括源代码、设计、架构等，从而更好地保护自己的知识产权。市场竞争其次，市场竞争也是影响采用低代码无代码平台的一个重要因素。低代码无代码市场的竞争非常激烈，许多平台提供商都在争夺市场份额。然而，由于各平台的开发环境、组件和模型等都有所不同，组织和个人可能担心如果选择了某一个低代码无代码平台，可能会在未来的市场竞争中处于不利地位。而传统的代码式开发方法则没有这个问题。开发者可以使用各种编程语言和工具进行开发，不会受到某一特定平台的限制。企业数字化在企业数字化方面，采用低代码无代码平台也可能会有一些挑战。当企业采用低代码无代码平台时，可能需要将所有的应用和数据都迁移到该平台上。然而，如果企业的应用和数据分布在多个不同的平台上，这可能会增加企业数字化的复杂性。相反，传统的代码式开发方法则可以更好地支持跨平台开发和部署。开发者可以在不同的平台上使用不同的工具和技术进行开发，使得企业的应用和数据可以更好地集成在一起。商业考虑最后，商业考虑也是影响采用低代码无代码平台的因素之一。采用低代码无代码平台可能需要支付一定的平台使用费用。尽管这些费用可能随着应用的规模和复杂度的增加而增加，但对于一些小型企业和初创公司来说，这可能是一个重要的考虑因素。相比之下，传统的代码式开发方法则可以降低开发和维护的成本。开发者可以自由地选择不同的开发工具和技术，而且不需要支付额外的平台使用费用。综上所述，虽然低代码无代码平台具有许多优势，但是传统的代码式开发方法仍然具有一些独特的优点，包括更好的软件著作权和知识产权保护、更大的市场选择自由度、更好的企业数字化支持以及更低的商业成本等。因此，在选择开发方法时，组织和个人应该根据自身的实际情况和需求进行权衡和选择。图1：低代码无代码平台与传统代码式开发的比较在这个图中，我们可以看到低代码无代码平台和传统代码式开发的各种优点和缺点。例如，低代码无代码平台可以降低开发和维护的成本，但是可能会增加对平台提供商的依赖性。传统的代码式开发方法可以更好地控制软件的著作权和知识产权，但是可能需要更高的开发和维护成本。因此，在选择开发方法时，我们需要综合考虑各种因素，以找到最适合自己的解决方案。对于开发服务端角度上看，正是由于低代码、无代码平台在源码及原创生成物的缺乏，这些反而是影响采用低代码无代码平台的关键因素，包括软件著作权、知识产权、市场竞争、企业数字化和商业考虑等。这些因素在不同的情境下可能有不同的重要性，因此我们需要根据实际情况进行权衡和选择。总之，低代码无代码平台和传统的代码式开发方法都有各自的优点和缺点。在选择开发方法时，我们需要综合考虑各种因素，以找到最适合自己的解决方案。无论采用何种开发方法，我们都需要注重软件的质量、可靠性和可维护性，以满足用户的需求和提高用户的满意度。
低代码,开发平台
2023-09-03
[实验室] 我们为什么不采用低代码无代码平台，而使用代码式开发
当我们面临软件开发的选择时，低代码无代码平台（LCNC平台）和代码式开发是两种常用的方法。尽管LCNC平台在近年来越来越受欢迎，但我们仍然决定采用代码式开发。本文将进一步阐述我们选择代码式开发的原因，并对比LCNC平台的优缺点。首先，代码式开发具有更高的控制性和灵活性。对于处理复杂任务和构建大型系统，开发人员需要能够深入了解并直接管理代码。通过编写代码，开发人员可以精确地控制软件的行为，并针对具体需求进行优化。此外，代码式开发还允许开发人员利用各种工具和技术来增强软件的功能和性能。其次，代码式开发生成的代码结构清晰、可读性强，这使得维护和管理应用程序变得更加容易。对于长期项目，这一点尤为重要。通过编写清晰的代码，开发人员可以减少错误和故障，并提高代码的可维护性。此外，代码式开发还有助于开发人员创建可重用的代码库，从而提高开发效率。然而，LCNC平台也有其优势。对于简单的应用程序或快速原型开发，LCNC平台可以非常有效。通过使用拖放等简单操作，非开发人员或业务分析师可以创建应用程序，而无需编写大量代码。这大大降低了开发门槛，使得更多的人可以参与软件开发过程。此外，LCNC平台还可以提供丰富的预构建组件和模块，从而加快应用程序的开发速度。但是，LCNC平台在处理复杂任务时可能会限制用户的灵活性。由于用户被限制在预定义的组件和模块中，他们可能无法根据具体需求进行定制或扩展。此外，LCNC平台生成的代码可能更加复杂和难以理解，这可能导致更高的错误率和维护难度。总的来说，我们的决策是基于我们的具体需求和项目的复杂性。尽管LCNC平台在简单应用程序和原型开发方面具有优势，但我们相信代码式开发更适合我们的项目和团队。通过编写代码，我们可以更好地控制软件的行为，提高可维护性和可扩展性。此外，我们还可以创建可重用的代码库，从而提高开发效率。当然，这并不意味着LCNC平台没有价值。对于那些没有大量技术资源的组织或需要快速创建简单应用程序的情况，LCNC平台可以是一个很好的选择。它们可以大大降低开发门槛，并让更多人参与软件开发过程。在未来的软件开发中，我们可能会继续看到LCNC平台和代码式开发的结合。例如，LCNC平台可以用于快速创建应用程序的原型，然后使用代码式开发进行进一步的定制和优化。这种结合的方法可以充分发挥两者的优势，提高开发效率和软件质量。总之，选择使用LCNC平台还是代码式开发取决于具体的需求和情况。对于我们的项目来说，我们相信代码式开发是更好的选择。无论选择哪种方法，我们都需要继续关注技术的发展和创新，并灵活地调整我们的开发策略。
低代码,开发平台
2023-09-03
[实验室] 机械设计中防错如何做？
什么是防错？防错，日文称POKA-YOKE，英文又称Error Proof 或 Fool Proof（防呆）。这里为什么谈到了日文？我想看到汽车行业的朋友一定听说过丰田公司的“精益生产（LEAN）”，POKA-YOKE的概念就是日本的质量管理专家、着名的丰田生产体系创建人新乡重夫的首创。从字面上看，防错，就是防止错误的发生。要想真正了解防错，我们先来看看“错误”，及“错误”为什么会发生？“错误”造成与预期的偏离，最终可能产生缺陷，很大一部分原因是人们由于疏忽、无意识等造成的。对于制造业来说，我们最担心的就是产品缺陷的产生，而“人机料法环”都有可能导致缺陷。人为的错误不仅存在，无法完全避免，另外，人为错误还会影响机、料、法、环、测等因素（毕竟事情都是人做的，没法完全独立），比如加错料了。所以“防错”这个概念就应运而生了，其诞生的很大一部分意义就是与人（为错误）做斗争（我们一般不去谈设备、物料犯错误）。02人为错误的原因有哪些？有人总结了错误发生的十大原因，这里分享给大家。它们分别是：遗忘、理解错误、识别错误、新手错误、意愿错误、疏忽错误、迟钝错误、缺乏标准导致的错误、意外错误、故意的错误。a. 遗忘：当我们注意力不集中在某处时，会遗忘某些事情。b. 理解错误：我们常根据以前的经验来理解新遇到的事物。c. 识别错误：看得太快、看不清楚或者没仔细看会发生错误。. 新手错误：缺乏经验产生的错误，比如老员工一般比新员工少犯错误。e. 意愿错误：特定时候决定不采纳某些规则发生的错误，比如闯红灯。f.  疏忽错误：心不在焉发生的错误，比如无意识的穿过街道，没有留意到红灯是亮着的。g. 迟钝错误：判断或者行动迟缓发生的错误，比如刹车踩慢了。h. 缺乏标准导致的错误：没有规矩，不成方圆。. 意外错误：没有考虑到的情况发生了，导致的错误，比如某个检验设备突然故障了。j. 故意错误：人为的故意制造错误，这个性质就恶劣啦~以上这些分类有些分散，之间也有很多重叠交叉的地方。但无非是技能、规则和知识导致的错误。如果再要总结一下，可以考虑发生这些原因的原因，那就是人的惰性。人类其实骨子里都是爱偷懒的，所以越简单、越轻松、越不需要动脑筋的活，犯错的可能性越小。所以这也是“防错”所要要达到的目标。03这些错误会给生产带来哪些后果？刚才很多错误的例子都是生活中的例子。咱们还是看看这些错误在具体生产制造过程会导致哪些后果。不管生产什么零件，这些错误可能给生产带来以下后果：a. 漏掉某个工序b. 作业失误c. 工件设置失误. 缺件e. 用错零件f. 工件加工错误g. 误操作h. 调整失误. 设备参数不当j. 工装夹具不当如果将错误的原因和后果对行关联，我们得到如下图。分析了原因和后果，接下来我们该着手如何去解决了。04防错思路在很长一段时间，被各大公司所采用的防止人为错误的主要措施是“培训与惩罚” 。对操作人员进行大量的培训，管理者也一直劝诫操作人员要认真、努力、有“质量意识”，当错误发生的时候常常采取“扣工资”，“扣奖金”的形式。但是由于人为疏忽、忘记等所造成的失误却很难完全避免。所“培训与惩罚” 相结合的防错方式并不成功。而新的防错方式（POKA-YOKE），用一套設备或方法使操作员在操作时直接可以明显发现缺陷或使操作失误后不产生缺陷。操作员在自我检查，失误也会变得明白易见。下面，我们分别来介绍一下防错的一些常规思路，供各位朋友参考。在开始之前，笔者还是要强调一下防错的几个原则：1. 尽量不要增加操作人员的负担，否则很难持续下去。 2. 成本一定要考虑，不要追求那些高大上的东西，你追求的应该是实际效果（有效性）。 3. 实时反馈。防错可以从以下三个维度来考虑：在以上三上维度的指导下，我们得出以下五种思路：05十大防错原理及应用再到执行层面，我们有10大防错原理及其应用：a. 断根原理将会造成错误的原因从根本上排除掉，使绝不发生错误。上图是一个排挡机构的塑料面板。在面板和基座上故意设计了一个凸起和凹槽，从设计层面避免塑料面板装反的情况。b. 保险原理借用二个以上的动作必需共同或依序执行才能完成工作。以前听现场的老师傅说过，10个冲压工9个残，很多在冲压过程中手或者手指没有及时拿出来，造成伤残，上图显示了只有当两只手同时按按钮，冲压设备才能工作（压下来）。如果再在模具下面加一个光栅保护，可以实现双保险。c. 自动原理以各种光学、电学、力学、机构学、化学等原理来限制或提醒某些动作的执行，避免错误发生。如安装不到位，传感器将信号传递给终端，以鸣笛、闪灯、震动的形式发出提醒。. 相符原理借用检验是否相符合的动作，来防止错误的发生。这个例子和断根原理很类似，螺钉盖板设计成一侧卡扣，另一侧延伸；相应的本体也设计成一高一低，安装时只能有一个方向才能装上。医生手术器械的放置盒也一样（如下图），手术完确定有没有器械落到病人体内。e. 顺序原理避免工作之顺序或流程前后倒置，可依编号顺序排列。以上是一种检验合格后才会打印的条形码，通过先检验后出条码的顺序，避免漏掉检验这道工序。f. 隔离原理借分隔不同区域的方式来达到保获某些地区，使其不能造成错误。上图是仪表板激光弱化设备，设备会自动探测工艺实际输出状态，如果发现不合格，产品将不能取出，放置在独立的不合格品区域。g. 复制原理同一件工作，如需做二次以上，采用“复制”方式来完成。上图是挡风板的左右件，设计一样（非镜像），减少，减少零件种类，便于管理，减低错误的可能性。h. 层别原理为避免将不同的工作做错，而设法将其区分出来。高低配零件在细节上有区别，便于操作人员区分及后续装配。. 警示原理如有不正常的现象发生，能以明显标识或声光等方式给出警示。 这个在汽车上用得很多，当车速过高，或都安全带没系，会有报警（亮灯或者语音提醒）。j. 缓和原理用各种方法来减少错误发生后所造成的损害。
软件设计
2023-07-16
[实验室] WMS售前常用套路总结
最近在看一些公司的WMS售前解决方案，发现有如下套路，结合自己之前的相关工作经验，特写该文进行分享。 特别声明 1. 本文仅说明售前方案的常规方法，如有描述不准确的地方，欢迎同行指正。 2. 相关资料均做了特殊处理，隐去了固定的隐私后提供下载，不涉及透露公司机密，仅供同行学习交流。 3. 相关资料均来自网上同行分享。 一、PPT提纲梳理 一般写PPT前，都会理一个提纲，先问自己这个售前方案是写给哪个公司的，该公司处于哪个行业，哪个阶段。            每个行业的特性不一样，例如食品行业就需要快进快出的批次管理，整车行业就要基于VIN来进行管理，酒类管理就需要有严格的箱条码和瓶条码（唯一码）管理。  每个阶段也有很大的不同，可按照之前我们聊的，供应链成熟度模型去进行评价，去大概分析目标公司的痛点。  例如有的公司没有上系统，全靠人工EXCEL台账维持。还有的公司上了系统，但不能很好的用PDA指导进行作业（用的不爽）；还有上了系统，并且能用PDA指导作业，但是无法和其他系统做对接，造成数据孤岛等。  至于ppt编写，常规的套路如下，一般分为，公司和产品能力介绍、业务理解和整体解决方案、项目典型场景的解决方案，项目管理和运维保障计划。 1、公司背景介绍、荣誉和资质、成长历程、公司所有产品系统架构图、产品核心优势、关键特点、整体系统解决方案、案例logo墙、典型案例（最好和目标公司有一定的相关性）。  2、行业发展分析、该行业商品作业挑战、典型作业场景需求、用到的产品系统架构图、实现价值点、对业务的深入理解、对业务范围的理解、业务蓝图理解、系统功能架构图、系统技术架构图、系统部署架构图、服务器性能保障介绍。  3、典型场景解决方案，可针对该客户做详细示例来介绍，包括不限于 基础主数据、入库流程、入库打印、上架策略、收货上架截图、出库流程、库存周转分配规则、拣货规则策略、复核操作、打印装车清单、库存管理介绍、盘点介绍、盘点打印、补货、预警提醒、月台管理、越库管理、在库加工。  4、项目管理和运维保障计划，主要突出技术优势、实施方案、培训服务、联系方式。包括项目实施步骤、实施计划过程管理方式、售后服务体系介绍。  二、见招拆招 一般WMS仓储作业常见痛点如下。 1、缺乏统一订单的接入方式  造成原因：没有系统支持。 造成结果：需人工制单，无法监控订单的全流程，相关问题也无法直观的追溯，信息沟通不及时。 应对方案：上一套能完成上下游对接的系统（例如OMS）。 预期效果：能完成全订单的全流程的监控，相关问题溯源更简单。 2、凭经验进行作业，或使用Excel手工台账作业。  造成原因：没有系统，或系统建设不够完善。 造成结果：凭经验作业时，员工请假或更换会造成数据不准；台账记录太多查找费时费力，打开缓慢。 应对方案：上一套能满足并指导现场作业的系统，并提供标准的SOP解决方案。  预期效果：标准化作业，高效解决生产过程中的问题，从容应对突发或高峰期的情况。 3、未使用条码化技术或RF进行作业  造成原因：没有系统，或系统不支持。 造成结果：数据传递延迟，作业流程衔接延迟，缺乏任务动态调度，缺乏绩效考核数据依据，缺乏作业过程溯源。 应对方案：使用带有移动端作业的WMS系统。 预期效果：数据实时传递，作业流程衔接，任务动态调度，作业数据可支持绩效考核。 4、上架作业无推荐或推荐较为薄弱 应对方案：上架作业策略应可配置，以应对业务运作不断变化的需求。可以为每一种商品分别定义不同的上架作业策略。  常见的上架规则包括不限于，按照不同的库区寻找库位，按照不同的包装(托盘、箱、件)分配不同的库位，根据商品的属性(正常品、残损品)分配上架库位，体积限定、重量限定、数量限定、长宽高限定，混批号、混商品限定，同批号商品合并，同类商品相邻选择，不同的订单类型可以上架到不同的库位，如正常的采购订单和退货订单，根据商品的ABC动性分配上架库位。 5、 缺乏预警机制，或系统无法预警 应对方案：允许物流中心对不同事件的预警，并提供大屏预警展示，包括不限于商品过即将过保质期、商品低于库存下限或者高于库存上限、库龄超过半年、订单超过24小时未处理、补货任务1小时内未执行、收货12小时内未上架。  方式：emal、SMS、IM（钉钉或企业微信）、系统监控界面。 6、缺少库位库区规划 造成结果：无法快速知道每个商品在每个区域的准确库存，造成找货难，管理难。  无法对上架、拣货、补货操作做路径优化，造成重复工作量。 无法准确控制库位库存变化，不能即时补货。 应对方案：增加现场合理的库区库位规划，现场成功管控并不是只靠系统，更多的是靠运营规划。售前顾问应能针对现场情况分析，结合标准的SOP合理规划上架、拣货线路。  对于稍微大型点儿的仓库，应该同时兼顾仓储区、拣货区、收货区、发货区、打包区、异常区等，每个区的职责各不相同，便于不同的员工分工协作。 7、品质检验过程系统无管理 造成原因：缺乏系统追溯，多为人为控制。 造成结果：管理混乱，查看品检结果需多个地方找寻，久而久之易丢失结果。 应对方案：系统可按照不同商品的特点要求，将品检纳入收货SOP的一部分，根据品检动作去决定是否收货，并记录品检的结果和照片。  8、无批次管理，手工保质期管理方式 造成结果：无法控制商品的先进先出。 应对方案：收货前收货时就记录好商品批次信息，完善商品批属性信息，包括不限于生产日期、入库时间（一般是收货时自动生成）、保质期等。便于后续按批次分开存放，即多批次不混放相同库位，在出库时控制商品先进先出，找货也相对容易。  9、单一的订单拣货模式，人海战术、效率低 造成原因：缺少事先规划，应对措施。 应对方案：考虑可按波次进行作业，每次拣货任务下来，分不同人在库区拣货，拣货完成后按单播种分货，按单复核，零散件装箱捆包待发，独立件整箱整托拣货完成存在的待发区，贴好面单和发运清单后，待配送人员取货后发运。  10、手工盘点效率底，准确率底 造成原因：没有系统支持原有系统不支持嫌系统盘点麻烦。 应对方案：可根据系统打印出盘点计划单，手工盘点后将差异计划重新导入录入到系统中；优化现有系统支持在线盘点，包括不限于可按指定条件按计划生成盘点单和盘点任务，自行分区领取任务或指派任务，进行多人盘点作业。  例如可按库位、货主、商品特性、批次等生成盘点单。支持循环盘点、动碰盘点、随机盘点、差异盘点、盲盘等 11、无法应对非标品入标品出的业务场景 造成原因：标准系统不支持加工或加工较为薄弱 应对方案：系统记录和维护商品重量与数量的关系。非标品按重量进行收货。加工后的成品折算为数量进行上架，损耗体现在库存调整单中。销售单按数量分配出库。支持商品等级转换，可将货品按不同等级进行转换。可配置先进先出策略，保证先生产的商品优先出库。  12、不支持非标品作业场景 造成原因：标准系统不支持非标品作业，仅支持按数量收发货。 应对方案：提供多种收货方式，非标品使用称重收货，标品支持快速收货、点数收货。 提供抽检功能，针对有坏掉的商品可以拍照取证记录，异常抽检标签不再收货。 提供PDA撤销收货功能，现场无需额外准备电脑。 提供多维度PDA收货查询、作业路由查询、入库单查询、灶点查询。 允许在发运前修改收货重量，即使在已复核、已拣货之后（可灵活配置权限）    13、无法统计包装过程中的耗材使用情况 应对方案：WMS提供耗材管理，包装耗材推荐方案、以及特殊包装规则的维护。 系统应支持耗材的进销存管理，包含耗材的基础资料维护（长宽高、重量、条码），耗材的入库及耗材的出库，其中耗材的出库消耗包含通过复核。打包包装消耗和通过出库消耗功能进行库存扣减。  可考虑的推荐方案。 系统根据仓库所使用的包装所使用的耗材组合维护包装方案，一般一个完整的包装方案包含纸箱、面单值、填充物等。作业过程中发现系统推荐包装方案不满足时，可手动调整最优包装方案。  订单下发到WMS，系统自动推荐包装方案。推荐逻辑：订单货品组合是否已有历史包装，如有则直接推荐已使用的包装；如无，则根据货品的长宽高、重量自动计算包装方案。当有特殊货品时则配置包装规则，推荐特殊包装。  14、送货无预约机制 现场情况：没有预约，供应商想啥时候送就啥时候送，无提前规划。 造成结果：现场月台拥挤不堪，严重影响收货效率，仓库管理混乱，造成爆仓的错觉。 应对方案：合理控制供应商送货时间，可精确到小时。  合理库存控制，控制供应商必须在指定时间段送货，降低库存。  合理库位安排，供应商提前预约提前安排储位。 通过预约机制可对供应实施绩效管理。如:供应商送货准时统计,可按供应商进行排名排序，残品统计,供应商效率统计…可统计出最佳供应商。 仓库可实时把握供应商变化，可合理安排各种资源。 通过系统进行预约策略控制，如：不同订单是否允许合并、预约时间是否严格控制、是否可拆散订单预约、预约是否严格审核机制等配置与控制。 三、 其他                     
WMS
2023-07-16
[实验室] 软件系统处处要体现“防错”设计
软件系统在设计时一定要考虑防错设计，按我的实施经验，有很多软件项目之所以使用效果不好，在于软件大多都是人机交互，人工操作为主，而人工往往由于现场环境的原因，在操作录入，特别容易引起误操作，使数据越来越偏离真实，又较难及时发现，因此系统和设备应该做好人工错误的预防和兜底。以下做个科普：防错日文称POKA-YOKE,又称愚巧法、防呆法。意即在过程失误发生之前即加以防止。是一种在作业过程中采用自动作用、报警、标识、分类等手段，使作业人员不特别注意也不会失误的方法。防错是一门技术,有一系列技术和工具用于各类过程的错误防止，下表列明了不同的防錯思路及其策略：从上表可看出,防错的思路有减少失误、检测失误、简化作业,替代、削除等,从其目标及采用的方法来看:(1)消除失误削除失误是最好的防错方法。因为其从设计角度即考虑到可能出现的作业等失误并用防错方法进行预防。这是从源头防止失误和缺陷的方法，符合质量的经济性原则，是防错法的发展方向。妙笔：我们告知客户最好梳理一下仓库的布局，物品的摆放整齐，外观，包装，标识都要清晰，空间宽敞明亮，不要太狭小，人员易搬动，易识别，易清点，提前预防因环境不良而引起的误判。(2)替代法替代法是对硬件设施进行更新和改善，使过程不过多依赖于作业人员，从而降低由于人为原因造成的失误(占失误的部分)。这种防错方法可以大大防低失误率，为一种较好的防错方法，缺点在于投入过大，另外由于设备问题导致的失误无法防止。妙笔：原先依赖员工经验查看实物，人为判断与品名进行匹配，这很容易引起失误，特别是新手，料不对号。采用PDA等设备，扫描条码、二维码识别等避免人为错误。(3)简化简化是通过合并、削减等方法对作业流程进行简化，流程越简单、出现操作失误的概率越低。因此，简化流程为较好的防错方法之一，但流程简化并不能完全防止人为缺陷的产生。妙笔：改造流程，把一些容易引起误判误读的环节精减或者直接去除。(4)检测检测是在作业失误时自动提示的防错方法,大都通过计算器软件实现，为目前广泛使用的防错方法。妙笔：系统对于录入和采集的数据进行检查，对于不合格式的，偏差较大的异常数据进行告警或自动修正。(5)减少从减少由于失误所造成的损失的角度出发，即发生失误后，将损失降至最低或可接受范围，目前许多智能设备均或多或少具备该功能。妙笔：经过追溯，发现了复核后仍有错误的数据，将该数据标为质疑，不可用于生产环境，直到错误彻底得到纠正。【参考文献】知乎：盘点防错技术的五大思路
软件设计,生产力工具,开发平台
2023-07-01
[实验室] 【千妙小问】极速开发工具Turbo
妙笔：千妙科技为什么要做自己的开发工具？自修：这个问题，总体归纳为，主要是为了满足市场的需要，在结合自身的实际情况而做出的考虑。 1. 市场的要求沟通试错成本要低，企业随着时间和业务的变化，对信息系统的需求也存在变化，而软件项目中主要的隐性成本是沟通和试错成本，尤其是处于新上线的，定制的，或较为独特的项目更为明显，为了尽量降低试错成本，必然需要这样的基础开发环境做支撑，能快速实现并快速验证的。稳定性有保证，一个基础之上创建实际客户案例越多，说明经过市场的验证越充分，证明基础稳定性更好，企业引入风险低。快速服务响应的底层保证，快速定位到是设计时的缺陷，还是实现时的缺陷，还是运行时环境问题，快速修正，快速交付，不需要复杂的交付流程，提升客户接受服务的体验。服务可持续性的保证，服务的可持续性是软件企业生命力的体现，有稳定可维护性的基础环境，不会因为干系人员的变动而停摆。可扩展性，软件服务对企业的业务纵深有冗余空间，可以简易的增减新功能新特性，与第三方集成或者迁移，特别是一些历史遗留项目。2. 自身的要求价值观落实在实践上，创新创造是我们的价值观，我们在公司介绍中曾有描述，我们是一家既“资深”又“年轻”的公司，我们希望成为一家合格的软件企业，有研发能力，拥有独立的知识产权（著作权和专利），并将不断提高研发的比重。要有一个具体基础去积淀生产流程和质量管理体系规范、知识和经验，有科技之名，应有科技之实，因此开发工具是必须的；适合自己，没有完美的工具，只有合适的工具，古人云：工欲善其事，必先利其器。首先在自家“兵器”的选择上要有绝对的自主权，是长是短，是粗是细，是钝是利，趁手最宜。倘若选择了一些不适合自身发展需要的工具，隐性的内耗会增加。提高自身的生产力，不可能所有项目都是从零开始构建，性价比太低，只有高度可复制性，不断降低复杂性，才能使设计理念和构思快速落地，降低自身的试错成本，拓展市场。自身安全的需要，代码做为软件企业重要的资产，一定要完全自主可控，保密。只有自主研发，才能在产品和项目中融入自己的智慧和设计理念。自己的一切自己做主，这是公司的恪守原则。减少“黑箱”类应用，减少对第三方供应侧的强依赖关系，以免增加公司的服务供应链风险。差异化竞争的需要，我们要与纯商贸型的软件商家区别开来，避免陷入同质化竞争带来的损耗。积累知识资产，没有自己平台，公司无法积累技术成果，积累知识资产，这对软件企业的成长是不利的。小妙：现在大厂也有很多的低代码平台，为何不直接用他们的平台？自修：不论供应侧是低代码还是无代码，那都是别人的产品，我们只是做为第三方应用开发者的角色，而实现细节被隐藏，总体风险变得不可控，其局限性明显，不够灵活自由度，对此我们持保留态度，我们坚信一句话：专业的人才能做专业的事，请细品~我们的开发工具Turbo，是为我们自己而打造的一套生产力工具，是基于我们自身对产品的应用场景和未来经营方面的判断。结构松散，独立灵活，使之保持对信息技术趋势持开放态度，特别是移动化，物联网，人工智能方向积累经验。做为我司产品和项目的底层基础，保持一定前瞻性的同时，不断迭代，控制复杂性，在可维护性上做取舍，像打造一款产品一样打造开发工具，不断地延续其生命周期，包括其上的产品和项目。
低代码,开发平台
2023-06-16
[实验室] 小妙对话：产业发展的观察
妙笔：可否描述一下宁波市高增值产业？小妙：宁波市位于中国浙江省东部，是中国重要的沿海城市和港口城市之一。宁波市高度重视高增值产业的发展，特别是高新技术产业、现代服务业和文化创意产业等。其中，宁波市高新技术产业作为宁波市的支柱产业之一，涵盖了电子信息、新材料、生物医药、高端装备、新能源等领域。宁波市秉承“科技立市、创新兴市”的发展理念，不断推进创新创业，加强科技创新和人才引进，推进科技成果转化和产业化，助推高新技术产业持续快速发展。除了高新技术产业外，宁波市还积极发展现代服务业，包括物流、金融、商贸、旅游、文化等领域。宁波市拥有全球最大的港口之一，交通便利，物流体系完善，吸引了大量的物流企业和相关服务企业进驻，形成了以港口为中心的现代物流体系。此外，宁波市还注重发展文化创意产业，鼓励广大文化创意企业家积极创新、创造，推动文化与产业深度融合。宁波市政府出台了一系列激励政策，包括提供场地、资金、税收等方面的支持，鼓励文化创意企业发展和创新。综上所述，宁波市高度重视高增值产业的发展，积极推动高新技术产业、现代服务业和文化创意产业等领域的发展，为宁波市的经济发展注入了新的动力和活力。妙笔：2023年宁波市中小微企业发展现状？小妙：2023年宁波市中小微企业发展现状尽管无法预测未来，但可以根据当前的情况和政策规划来推测一下宁波市中小微企业发展的趋势。以下是一些关于2023年宁波市中小微企业发展的可能性：1. **政策支持将进一步加强**：宁波市一直致力于支持中小微企业的发展，未来几年也不会改变。政府将继续提供各种扶持政策、金融支持和技术支持，为中小微企业提供更好的发展环境和条件。2. **数字化转型将成为重点**：随着数字经济的快速发展，中小微企业必须加强数字化转型，以适应市场需求和竞争环境。政府将鼓励企业加强信息化建设，提高企业管理和运营效率。3. **产业升级将继续推进**：宁波市将继续推进产业升级，加强传统产业的转型升级，培育新兴产业，为中小微企业提供更多的发展机会。4. **国际化发展将得到加强**：宁波市将继续加强与国际市场的合作，鼓励企业拓展国际市场，提高企业的竞争力和影响力。综上所述，2023年宁波市中小微企业将面临着数字化转型、产业升级和国际化发展等多重挑战和机遇。政府将继续支持中小微企业的发展，为企业提供更好的发展环境和条件。
SaaS,人工智能,云计算
2023-04-13
[实验室] 70+款可以免费使用的AI工具
本文转摘自互联网公开信息，供参考。策划丨KK制图丨邬海雯 ChatGPT风靡全球，人人可用！ 小红书上有关ChatGPT的笔记已有10w+篇，相关话题浏览量也达到了1.12亿次。其中讨论最为热烈的，要数“ChatGPT使用教程”。（当然，类似的话题还包括，教你如何使用Mjourney等等）甚至还有人通过ChatGPT教学，月入十万。 在如今处处都追求降本增效的时代，把属于机器的工作交给机器或许是个不错的选择。 正如前不久微软发布的Coplot，其本意并非是取代人类工作，而是为每个人配备一个人工智能助手，就像是一名副驾驶，辅佐用户做出更聪明的决策，释放更大的生产力。 甚至未来有可能会出现更多“超级个体”创业者——不需要组建一只庞大的团队，也能做出伟大的产品。 为此，我们分别在创意写作、图像生成、影音编辑、编程开发、管理效率五个方面，收集整理了不同领域的AI工具平台，希望大家也能从中找到适合自己的“副驾驶”。  创意写作助手 写作，应该是大部分工作者都不可避免的重要任务之一。 无论是写总结报告、营销文案，还是咨询邮件，哪怕是一个“自动回复”可能都需要在如何行文上花些心思，才能达到吸引受众的目的。更不用说，实现销售转化了。 下面介绍的几个写作助手，或将为日常工作提供更多的创意灵感。当然，也可以节省很多构思文章逻辑，润色文笔的时间。 图像生成助手 PPT、内容配图、推广海报、网站APP的插图等等很多日常工作任务中，图片都发挥了很大的作用。 令人头疼的是，免费无版权的图片大多不怎么好看，有时为了找到一张符合场景需求的图会占用大量时间。 哪怕是设计师本人，有时可能也会为了找到理想的素材而发愁，或者会为了设计全新的场景构思很久。 现在，这些问题都可以交给AI来完成了。不仅出图快，而且数量还多，总有一张能击中需求。 影音编辑助手 在AI加持下，音视频领域的创作者们也可以卸下后期剪辑的重担了。 现在的AI工具，不仅可以自动剪辑编辑，还可以根据文本指示（prompt）自动生成音频、视频。 创作者们终于可以摆脱在海量素材库中寻寻觅觅的案头工作了！ 编程开发助手 如今拥有了AI，即使不懂任何编程也可以快速搭建一个应用。 当然，这也不意味着码农们就要失业了。相反，程序员们可以借助AI更快速更准确的写代码（或许可以大幅减少以前用来修bug的时间……）。 管理效率助手 除了在业务层面的降本增效，在日常的工作处理流程上，也有很多可以优化提升的空间。 如今，各式各样AI助手出现，可使效率显著提升。 以上就是创业邦整理的AI工具合集。 如果其中有你正在用的，或者你还发现了其他更好用的工具，欢迎在评论区分享你的使用心得。 
人工智能
2023-04-09
[实验室] AI是工具，用的还是过去人的经验来验证
对于机械重复不重要的东西可以用AI帮助搜索验证，但创造性的工作还是靠脑子，人的身体、大脑需要训练，越用越强大。大部分普通人，论不到拼智力，那是天才高智商的人做的游戏。普通人成为专家，就是将术业提高到极致的熟练度罢了，小雪森都知道卖油翁的故事吧，无他，为熟熟尔。
SaaS,RPA,人工智能
2023-04-07
[实验室] 万字详解｜从软件复杂度的角度去理解DDD
声明：本文及素材系转摘自互联网公开文章，著作权归原作者所有，仅为学习参考。千妙导读从我们作为业务开发主要的职责深入到DDD的本质是什么？复杂度应处理？规范设计怎么做？本文将全方位为大家解答。一、作为业务开发，我们的主要的职责是什么的业务开发的职责在文章的开始我想和大家一起思考一个问题：作为一个工程开发，我们最主要的职责是什么？ 我极度认可 >文章的观点 - 切实解决业务问题才是每一个工程开发最主要的职责 - 所以每个业务开发都必须要结合业务的视角去思考自己系统的建设和发展，而不是只是做一个“编程的”码农。这里摘录一下文章中要点技术一号位是负责使用技术能力解决业务问题，提供稳定可靠的技术支撑；负责向业务各方提供各种必要的技术支撑，通过合理的数据分析为业务决策提供依据；通过对技术领域的积累和发展，通过业务领域的理解和落地影响业务决策；负责构建梯队完整、能力全面、制度完善的技术团队来支撑业务发展。文中也提到了虽然不是每个人都负责一块完成的业务，也不是每个人都带领团队，但是至少每个人都是自己所负责的那块系统的技术一号位。业务在实际开展中遇到的问题那实际业务开展中，业务到底会遇到有哪些问题呢？我们按业务的生命周期进行切分，然后具体查看每个业务生命周期的诉求：业务启动期：业务能力快速搭建 - 系统提供快速试错的能力业务发展期：业务能力扩展 - 系统需要支持原来越多的业务功能业务平台期：业务能力复制 - 系统需要支持原来越多的业务场景业务衰退期：业务能力创新 - 系统提高生产力延长业务的生命周期我们技术要做的事情是：在业务验证没有问题的情况下，如果尽可能的延长业务的发展和平台期，让业务获取的利益最大化。所以为了支持业务的发展，业务的本身的功能支持诉求以及业务对技术的要求也会越来多，在这种情况下考验软件开发人员的一个非常关键的能力就是： 软件复杂度的控制的能力。软件复杂度软件复杂度其实是一种多维度的概念，其可能来源于多个方面，前阿里资深技术专家李运华在他的《从0开始学架构的》课程中从6个方面阐述了软件复杂度【2】，列举如下：高性能单机性能集群性能高可用计算高可用存储高可用可扩展性低成本安全规模业务规模系统物理规模二、DDD的本质是什么DDD本质上我认为就是一种减低软件复杂度的手段， 其推荐的方法论可以适用于上面包括了业务规模，可扩展性两个维度的复杂度应对。其实业务规模的复杂度的处理包括了对可扩展性的支持。DDD实施给系统之后，我们依然需要关注系统其它的复杂度，这里列举一些示例措施：容量规划架构设计数据库设计缓存设计框架选型发布方案数据迁移、同步方案分库分表方案回滚方案高并发解决方案一致性选型性能压测方案监控报警方案那么我们进一步对业务规模的复杂度进行拆解，又分为下面两类：1、领域复杂度领域模型描述问题域的准确性2、技术实现的复杂性代码没有按照业务绑定的”分析模型”去编码，软件变成一个大泥潭软件的可扩展性较差软件变成面向过程分层不合理没有规范那DDD是如何处理上面提到的软件复杂度的？提供了一个领域划分的方法：让软件系统产生边界。提供一个一系列的战略模式：限界上下文的映射，分层架构等。提供一个一系列的战术模式：如何规划领域层 内部DDD不是什么？不光光只是一种编程方法不光光只是一种架构风格不具体指导如何具体建模三、复杂度处理-领域模型描述问题域的准确性DDD的原名是模型驱动的设计方法：通过领域模型（Doman Moel）捕捉领域知识，使用领域模型构造更易维护的软件。合理性证明DDD的核心思想，大家都清楚，就是分析模型要和代码模型保持一致。 那么如果不保持一致到底会产生什么样的负面影响如果技术实现和业务实现不在用一水平线上，那技术模型的行进路线只会考虑劈开技术障碍并且可能会撞在未来的业务障碍的墙上。这样就很容易出现，业务持续演进等技术想实现的时候，却发现当前的实现依赖于“业务不会这样发展”的假设上。这也是为什么会出现现在众多业务需求，技术无法实现或者是需要花大量时间去实现的原因。但是如果技术和业务通过统一语言打破知识的壁垒保持一致，那么如果后面技术遇到问题即是业务碰到的问题，业务人员需求的变更和迭代会自然而然的帮助技术同学越过一些门槛。也就是说业务方与技术方参与到对方的工作中，就在双方之间带来了更好的协同，形成1+1>2的功效。什么是问题域根据百度百科的解释【3】 在软件工程中，问题域是指待开发系统的应用领域，即在客观世界中由该系统处理的业务范围那么问题域内的组成是什么呢？就是我们的域模型。 这里直接摘抄一段前阿里P10"阿白"在阿里内部发表的域模型的观点：域模型（oman moel）英文又称为问题域模型（problem space moel）。维基百科(Wkpea)对它的定义是” A conceptual moel of all the topcs relate to a specfc problem” 可以翻译成：“域模型是针对某个特定问题的所有相关方面的抽象模型”。这个定义有几个要点：第一是“特定问题”， 也即是说域模型是针对性某个问题域而言的， 脱离的这个特定问题，域模型的构建其实不存在一个最优或者是最合理的构建。第二是抽象， 域模型是一个抽象模型， 不是对某个问题的各个相关方面的一个映射， 也不是解决方案的构建。 如何实现问题域的分析在 DDD 中，Erc Eans 提倡出一种叫做知识消化（Knowlege Crunchng）的方法帮助我们去提炼领域模型。简单来说就是五个步骤：关联模型与软件实现；基于模型提取统一语言；开发富含知识的模型；精炼模型；头脑风暴与试验。开发人员和业务专家在一起通过一个个业务用例仔细讨论应用程序的应用场景，从而使得业务人员深刻理解业务知识，开发人员和业务人员就重要的业务概念建立起统一的语言，开发人员将这些概念根据业务用例的上下文抽象出模型，并且这些模型将会最终成为最终软件实现中的领域模型。随后随着更多的业务用例的输入，开发人员和业务人员会逐渐对已经构建的模型进行精化，并且也会用新的用例去检验之前构建模型的合法性和适用性。DDD在这一步其实没有给出详实标准的如何建模的方法，毕竟建模还是来自于每个人的世界观，其过程还是倾向于经验的。但是还是有不少人总结一些标准的建模方法论例如：1 四色原型法  http:apframework.com20200322-color2 用例分析法 https:bake.bau.comtem%E7%94%A8%E4%BE%8B%E5%88%86%E6%9E%902859078?fr=alan问题域的拆分大家应该发现上面的知识消化的流程是一个非常耗时和复杂耗脑力的过程， 涉及到产品，业务，技术等多方团队， 所以为了让有限的资源投入到最最核心的子域，我们需要对问题域进行这份，把重点的精力放到最核心的领域上。核心领域一定是业务价值最高的，而非技术难度最高或者是基础设施框架部分。 要切分问题域，首先需要了解问题域的种类：1 通用域: 非应用独有的，多个应用都会有的功能。例如发送邮件，触达等2 核心域：和竞争对手区别开来的区域，或者是在市场上被赋予了竞争优势的区域。3 支撑子域：其余的区域如何确定核心域，这里有几个提示：系统哪部分最难用手动处理过程阻止了他们进行了根据创造性， 有附加值的工作哪些修改能提高收益哪些修改能提高运营效率取哪些提示，取决于业务系统的性质。那如何决定支撑子域通用子域，以及支撑子域通用子域的切分呢？目前在我查阅的资料中，还暂时没有人提及到具体的操作方法，感觉主要还是依靠经验主义在做划分。我个人总结了一个方法，主要就是就是关注业务的核心实体和核心流程。以核心实体和核心流程作为切分支撑子域的基础。核心实体：核心实体是存在于核心流程中，对核心流程的决策和扭转可能起到关键的作用。有的时候业务上为了能让核心实体在业务流程中起到更大或者更高效的作用，会添加一些让核心实体更好服务于业务流程一些业务功能，从而使业务实体从整体上看变得相对复杂，这个时候我们应该以核心实体为基础进行切割，把所有和核心实体CRUD相关的操作还有让其变得更高效的业务功能划分为单独的一个领域。核心流程： 当某个业务流程足够复杂也可以当成一个子域。在实现领域驱动设计【4】书中，提到了为在线拍卖网站系统划分问题域的一个例子，我们以此来验证上面等构想划分子域卖家 + 会员身份：这两者都是核心实体，网站可能为了让促进会员能够多参与拍卖可能提供了分层，或者积分等工功能。网站为了能让卖家能够更加提供更加有拍卖价值或者是转化率高的品类可能为卖家提供了数据分析等业务功能。 名册：这也就是核心实体，网站会对名册提供一系列拍卖相关的功能，例如倒计时，一口价等，所以也需要形成一个领域。 拍卖：网站最核心的业务流程，核心域无疑。争议解决：买卖家的售后冲突解决流程向来很复杂，所以会独立成为一个域无疑。四、复杂度处理-进一步降低问题域的复杂度-限界上下文限界上下文的诞生背景一般情况下，一个复杂系统由一系列的模型来表示解答域， 理想状态是一个子域一个模型。但是有些当业务需要且系统复杂的时候，一个模型可能被多个域共享，这个时候这个模型的概念可能变得不清楚。因此为了保护这些模型概念的完整性， 清晰的定义模型的责任边界很重要。实现领域驱动设计【4】书中举了下面这个例子：为了维护模型的概念的完整性，最直观的方法就是为这个模型化一个边界，e.g. 这个商品所表现的意思就是履约的时候用到的"商品"，而不是下单的时候的"商品"。只要有一个这样的边界定义，系统就会但是出现多个边界，毕竟"商品"在不同业务上下文中有不同的含义, 例如库存域的货品，物流域的运输品， 价格域的商品等等。这样的一个边界就是DDD的“限界上下文”。 限界上下文给人直观的感受其实和子域很像，我很早以前曾读过一些关于微服务的书籍，也提到过要把DDD中的限界上下文作为微服务划分的重要依据。这里其实就给我很大的疑惑：1 限界上下文到底是怎么划分的？我们划分限界上下文难道真的是用一个基础概念，然后找这个基础概念不同的“上下文”吗？2 限界上下文和子域到底区别是啥？限界上下文的本质DDD理论中提到了DDD的四个边界 所以在DDD中是把限界上下文作为某个子域的内部模块的划分，其实无论是子域的划分，限界上下文的识别，和聚合的划分他们的本质是一样的，他们都是对复杂问题的分解之后，然后归类分组。只不过“聚合”面向的是领域层内部，“领域”划分面向的是业务问题域，而“限界上下文”面向的是解答域，但是我跟倾向于把限界上下文理解为更加深一层次的业务问题域的划分，而不是面向的解答域。 如果这样看的话，那么其实就可以回答上面的疑问， 领域和限界上下文没有本质的区别，就像树的父节点和字节点一样都是树节点。而限界上下文的划分完全可以使用子域划分的理论。（可以回顾下上面问题域拆分的段落）上下文映射上下文的映射是什么， 简单来说就是描述不同上下文之间的关系的描述。举个例子DDD对于限界上下文直接提炼了几种方式，这里这边阿里内部文章《领域驱动设计：软件复杂性应对之道》解释的比较好，描述如下：share kernel共享内核 share kernel ：通常是共享核心领域或者是一组通用子领域。customersuppler客户供应商关系 customersuppler：上下游关系。不同客户需要协商来平衡，上游团队需要有自动测试套件。conformst跟随者模式 conformst：单方面跟随模式。上游的设计质量较好，容易兼容，可以采用严格遵循上游团队的模型。antcorrupton layer防腐层 antcorrupton layer：防腐层、隔离层，使用 facae or aapter 等模式。可以减少其它系统变动对本系统的影响。separate way各行其道 separate way：声明一个与其它上下文毫无关联的 boune context，使开发人员能够在这个小范围内找到简单、专用的解决方案。open host serce开放主机服务 open host serce：开放子系统供其他系统访问。其核心思想是开放出一个标准的各个领域都认可的协议，减轻各个领域实施ACL的负担和成本。publshe language共享语言 publshe language：把一个良好文档化、能够表达领域信息的共享语言作为公共的通信媒介，必要时在其它信息与该语言之间进行转换。在当前电商领域的范畴，目前我个人觉得只有ACL，Seperate Way， publsh language 有比较好可行性，其他的关系都不是很靠谱:share kernel：如果使用共享二方库，谁来维护这个二方库，如何防止在不同上下文使用不同kernal版本所带来的问题。 如果一定能保证share kernel的维护在一个团队内，且所有使用share kernel版本一定能保持一致， 那是可以使用的。 customersuppler：我曾经因为汇率包升级而去重构一个应用，因为汇率包变更太大，且应用没有防腐层，所以不论从开发还是测试都是非常痛苦的过程。conformst：和customersuppler类似, 但是在互联网领域没有靠谱的设计， 只有有人维护和没有人维护的设计。conformst从长期来看其实就是customersuppler。Open Host Serce 没有任何一个领域保证自己的接口一定不会变，就算不会，其他领域的同学会相信吗，他们会忍住不用ACL吗？如果他们用ACL，OHS的意义何在？publsh language 目前阿里内部MTOP，TOP等协议正是使用这样的协议。另外限界上下文之间真的能够随便无规则无条件的互相依赖，互相调用吗？在下面的章节将会解释论述。五、复杂度处理 - 分层不合理架构分层主要的作用就是关注点隔离，如果和今天的话题联系起来就是领域模型和技术的关注点隔离（领域和存储，领域和展示）。传统的三层架构这种传统架构的缺点1、业务逻辑层和数据访问层有明显的耦合。 2、没有领域的概念，所有的逻辑沉淀到serce中。所以传统架构只能针对小型的，没有过多的业务逻辑场景。由于这种架构能够保有领域能力的沉淀，所以在现在电商业务场景基本不会被使用。六边形架构Alstar Cockburn在 2005 年时演示了 六边形架构从六边形架构开始，其强调了领域模型。并且确立了领域模型的核心位置，以及其不应该依赖于其他的层次。六边形架构也强化了适配器的概念，其还把适配器分类为nput适配器，和output适配器。所有nput适配器用于对接不用的外部请求形式， 所有output适配器用于对外部的依赖 (e.g. 数据库， 外部服务，内存调用等）这种结构模式树立了以领域模型为核心的先河，但是其忽略了在领域层中跨模型业务逻辑的实现方式-领域服务的沉淀。这也间接导致了其需要强化应用层，并且通过应用层和output适配器的联合去完成一些可以应该在领域层应该完成的事情。 洋葱架构洋葱架构的提出更加进化了一步，推出了域服务层，并且支持域服务层是支持了那些需要多个领域实体联合中作用的领域逻辑. 其层次由外向内依次是领域模型，领域服务，应用服务和外层的基础设施和用户终端。其依赖的关系也只能是由外向内. 在洋葱结构中其把存储层，文件系统和网络服务放到了基础设施层。由于基础设施和用户终端一样在最外层，所以洋葱架构也提倡用依赖倒置来解决应用逻辑和基础设施的耦合问题。洋葱架构的架构图从其依赖顺序上来看，其依赖应用层必须先依赖域服务层，再依赖域模型层， 这样很容易造成领域模型的逻辑外泄到领域服务层，造成领域模型变成贫血模型。DDD 架构DDD的架构大家都非常熟悉了，领域服务和领域模型都归属域领域层。适配层依赖域应用层，应用层依赖域领域层，也可以直接直接调用基础设施层（大多数是查询场景）。领域层理论上不依赖于任何层次，其通过依赖倒置和基础设施层产生关联。在DDD架构中，应用层是可以通过直接访问聚合根（某个实体类），并进行方法的执行和操作的。应用层也可以直接访问基础设施层。可以看出DDD的架构其实更加的贴切实际一些。 上面这张图也很好的阐述了DDD各个架构层次依赖的关系。CQRS很多情况产品构建出来的数据展示，需要横跨几个领域的数据的支撑，也就是我们日常构建的大宽表，在这种情况使用CQRS模式可以完美解决这个问题。其主导视图模型和领域模型分开，让领域模型更加专注业务逻辑，流程和规则而非业务视图。 CQRS的思想很简单，就是把服务中对数据的更新操作(Comman)和读取操作(Query)分离, 一部分逻辑只处理和数据更新有关的业务，另外一部分只处理和数据读取有关的逻辑。这种处理方式，可以让我们辛苦构建的领域模型不被业务中所需要的这类视图需求所干扰。 CQRS 的两种实现方式基于eent- sourcng不基于eent - sourcng以上的图片摘自于文章《CQRS模式及其应用》我们团队里面的架构实践在我们自己的应用中我们构建了基于COLA【5】规范的层次架构，如下图： 我们也对自己的架构定义的一些额外的规范：1、依赖关系（除了依赖倒置）只能是从上当下；2、同层之间永远不能互相依赖；3、如果同层之间需要互相用到对方的服务，那么就需要下沉出一层。例如在上图中，我们的业务层就分为了两层 "Executor"层次和 “Hanler”层此， Hanler层次用来保存业务的一些通用逻辑。六、复杂度 - 软件变成一个大泥潭从这一章节开始介绍DDD的"战术模式"，也就是向大家介绍DDD是如何构建和组织自己领域层的。值得一提的是在DDD中，领域的划分, 领域层次的建立, 领域之间关系的建立我们一般叫做DDD的"战略模式"，而此章节提到的值对象，实体，域服务，工厂，repostory, 聚合聚合根， 领域事件等都是DDD的战术模式。战略模式的重要性是要远大于DDD的战术模式的，我们如果在领域划分，领域通信协议，分层方面没有大的问题， 那么即使再糟糕系统整体也还是可控的。 在领域层面， DDD通过聚合聚合根的概念来划分单个领域中的类似于类集合的边界，从而降低单个领域层的复杂度。DDD通过实体，值对象，领域服务，repostory, factory 来规划集合内部的类组织， 另外DDD也通过领域事件来处理领域之间的交互，来匹配异步和需要解耦的业务场景。实体当我们需要考虑一个对象的个性特征，获取需要区分对象的时候，就需要引入实体。一般我们发现实体概念，是在和业务产品人员或者领域专家讨论发现的那些需要有唯一标示性或者生命周期连续性很重要的时候。举个例子加入用户需要预定酒店，如果领域专家说了我们定了A酒店了，就不能定B酒店了，哪怕A,B其他的属性完全一样。从领域专家扣中我们可以识别出酒店是有唯一标示性的，且哪怕A，B属性一样，也不能认为A,B 是一样的，这也说明了酒店的唯一性不是从属性来的。这两点我们可以推断酒店是一个实体。唯一标示性可以是现实有意义的，例如工商注册号，也可以无现实意义，例如数据库主键。 实体建模的注意点1、为实体分配唯一标识符现实意义标识符人工生成的标识自增guuu数据库主键自定义sequence2、验证和不变行实体必须自己负责自己保持自己状态的合法性 (alaton) 和不变性(Inarants)。他们的区别是合法性是根据上下文的，而不变性是不用考虑上下文且必须正确的。例如酒店必须有房间这个就是不变性，而酒店的营业时间就是alaton. 一般使用规则和规约模式来实现alaton和narants。规模模式: https:bajahao.bau.coms?=1717403406288752234&wfr=sper&for=pc3、聚焦在行为,而不是属性状态不要暴露属性给外面，如果外面得到属性，很可能就自己实现了一些领域逻辑，那么领域逻辑就外漏了。 4、把一些行为逻辑下方到值对象中需要警惕实体逻辑膨胀，从而混绕了实体所要表达的概念。 例如预定是一个实体， 现在要加上逻辑预定的天数不能小于N天。这个时候我们可以为Bookng 抽象出 Stay 对象，让Stay对象去管理规则逻辑。而不是让预定这个实体去做。让预定只关注预定。 5、不要为世界建模不要过度设计，只要满足需求就好。不要让技术需求污染领域设计，除非真的万不得已。6、分布式的设计不需要让领域概念横跨多个boune context, 如果我们域模型所涉及的概念横跨了，我们就需要用两种设计方法.只是用引用alue objects值对象什么时候需要使用到值对象？概念需要凸显的时候。 e.g. 拍卖系统的能够一口价获取拍卖的价格, 就算是我们用一个nt 就能表示也需要用类来凸显概念publc class WnnngB{...publc nt Prce { get; prate set; }...}表述一个描述性的，但是没有实体编号的概念的时候。 值对象的特征无标识：他们只是标识对象的属性。基于属性的相等性: 所有的属性值相等即值对象相等富含行为：值对象实现业务概念的抽象，其也有自己的行为内聚：将不同的相关属性组成一个概念整体，例如Money, 是由一个long 和一个currency组成的不变性：值对象是不变的对象，如果需要改变属性，那最好是建立一个新的对象并且进行值对象替换。如果一定是需要改变，那就需要考虑设置为值对象是否合理。不变性是值对象非常重要的一个属性，是可以保障值对象不会被"坏味道"代码侵入的一个原则之一。 例如如果一个值对象引入了另外一个类实例， 另外一个值对象也引入了相同的类实例， 如果值对象允许改动，当一个值对象对这个类实例的内容进行修改，势必会影响另外一个值对象。 所以最安全的方式还是通过对象替换的方式。域服务 什么时候用域服务发现和多个实体相关联，但是放入任何一个单独的实体都不适合，这个适合用域服务.域服务应该包含什么内容域服务应该包含业务系统流程和业务规则，不应该包含技术的元素在内，技术的元素都应该在业务服务(Applcaton Serce)中实现。应用服务与领域服务的区别：一些可以在网上搜索到的老生常谈：应用服务里不要处理业务逻辑，只在领域服务里处理业务逻辑。（如何判断某段逻辑是否是业务逻辑？）领域服务掌握领域知识，而应用服务只是对领域服务的编排。应用服务是领域服务的客户方，也就是说应用服务会调用领域服务里的方法。当领域中的某个操作过程不属于实体或者值对象的职责时，需要将个操作放在领域服务中。而且确保领域服务是无状态的（这句话很有意思，也就是说领域服务中不应该有任何记录状态的行为，在任何情况下调用这个服务，它都不会有副作用，也就是说它是个纯内存操作）。领域服务中包含的是业务逻辑，而应用服务关注的应该是安全和事务等非业务逻辑。对事务的管理绝对不能放在领域服务层，事务管理需要放在应用服务层。因为和领域模型相关的操作的粒度都很细，无法用于事务管理。而且领域模型也不应该意识到事务的存在。通常的可以放在应用服务中的逻辑有：参数验证、错误处理、监控日志、事务处理、认证与授权。除了第一条之外，上面的条例只是举出了应用服务与领域服务两者非常易于告之的差别，但是会有一些“业务逻辑”比较难以取舍， 例如例如转账操作：A ->BA.accountDecrease(10);B.accountIncrease(10);我们在现在可以非常肯定的说上面的转账一定在领域服务，因为"转账"就是一个领域概念。但是如果假设世面上所有的银行以前只有存钱和取钱两种功能，"转账"是一个新概念和业务的时候，技术就没有那么容易判别转账是一个临时性的一次性的需求，还是会长久发展。这个时候技术有两个选择：1、构建转账域服务，让应用服务调用域服务2、让应用服务获取A，B的实体，然后在应用层直接调用方法，在应用层做事务保持一致性。如果域能力在其他团队手里，我相信大多数的团队会使用第二种。那遇到这种情况我们到底应该怎么办？我个人的意见和阿里前技术高级专家张建飞在他的文章《一文教会你如何写复杂业务代码》的观点保持一致：我们在新逻辑出现难以判断的时候优先讲能力放入到app层，如果我们发现会有第二个业务场景使用到了相同的能力，就需要考虑是否应该把此能力下发到领域层以增强内聚性和复用性。工厂只负责复杂逻辑对象的构建，让构建逻辑中心化减少外部对象对构建对象内部变量的理解工厂方式不是在任何构建对象的时候使用，一定用在对象构建逻辑复杂，有子依赖或者是有narant规则的场景。 Repostoryreponstory主要用来处理集合根的存储和获取的。提供一个facae接口且是面向oman层的，是oman moel和ata moel的桥梁。其最大的作用就是通过反向依赖的方式充分隔离数据层和领域层。Repostory最常见的用法是被applcaton serce层去使用获取聚合根。在repostory实现中，我们一般会有下面的一些逻辑：unqe ID 的生成数据库的操作数据模型到领域模型的相互横跨多个数据模型构建出一个实体模型。repostory的反模式定义出比较通用化的接口, e.g.Lst fnBy(CusomterQuery query)使用了延迟加载，延迟加载就是设计错误的标志， 有可能说明我们聚合的边界不催。 不要为了报表的诉求使用reponstory, 领域的case和业务报告很不一样，可能需要多个聚合的数据，这种情况可以考虑用一个离线的store去做，和其他的读服务去做，不见得一定需要用领域的Repostory模式。领域事件领域事件所想要解决的问题其实和metaQ消息机制想要解决的问题一致，都是跨领域驱动型业务逻辑实现的最佳方法，让领域和领域之前解耦。领域事件消费教科书的说法是可以在领域层， 也可以在应用服务层， 但是我觉得领域消息如果用metaQ是这样的消息中间件去实现的话，那用领域层和应用服务层去消费就不是很方便，有可能破坏一些分层原则。所以我个人倾向于在aapter层去承接消费，统一化掉。当前可以实现领域事件和消费比较方便的工具有：google guaa - EentBusCOLA框架 - 事件支持聚合聚合根聚合是什么？其实聚合的原理和领域划分，限界上下文划分的原理是一致的，都是为了通过归类分组的方式让整个系统宏观上 N * N 的关系复杂度减低为 T * T 的复杂度。 T远小于N。 聚合前： 聚合后如何划分聚合1、根据业务规则和不变量来决定。例如 customer 聚合是有一套业务规则来维持的，例如信用卡要存在，必须先有一个customer, 有customer 必须有aress, aress必须有coe.2、强关联的对象应该放在一块。什么是强关联，那就是必须生命周期是一样的。例如customer和cretcar在，电商网站中，如果customer被删除了，那么他的信用卡也应该被设置为失效的。而订单和客户不一样，客户下了个订单，然后客户注销，但是订单还是一直存在的。所以customer 和 cretcar 在一个聚合中， 而用户和订单则不在。订单里面可以有客户的ID或者是一个值对象。 3、灵活设置：有些可以根据业务情况，进行可以灵活的设置，下面列举一个论坛系统，帖子和回复聚合思考的例子：大家都知道一个帖子有多个回复，没有帖子，回复就没有意义；所以很多人就会认为帖子应该聚合回复；但实际上不需要这样，如果你这样做了，那对于一个论坛来说，同一个帖子被多个人同时回复的可能性是非常高的，那这样的话，多个人同时回复一个帖子，就会导致多个人同时修改同一个帖子对象，那就导致大家都回复不了，因为会有并发冲突或者数据库事务的等待超时，因为大家都在修改同一个帖子聚合根；实际上如果我们从业务规则的角度去思考一下，那可以发现，其实帖子和回复之间，只有一个简单的规则，那就是回复一旦被创建，那他所对应的帖子不能被修改即可；这样的话，要实现这个规则其实很简单，把回复作为聚合根，然后把帖子传入回复聚合根的构造函数，然后回复保存帖子ID，然后回复将帖子ID设置为不允许外部修改(prate set;即可)，这样我们就实现了这个业务规则，同时还做到了多人同时推一个帖子回复时，不会对同一个帖子对象就并发修改，而是每个回复都是并行的往数据库插入一条回复记录即可。-- 摘自阿里内部文档>聚合设计的原则聚合是用来封装真正的不变性，而不是简单的将对象组合在一起；聚合应尽量设计的小；聚合之间的关联通过ID，而不是对象引用；聚合内强一致性，聚合之间最终一致性；什么是聚合根聚合根就是聚合的入口，聚合外部只能通过聚合根和聚合内部通信。由于聚合外部只能通过聚合根和聚合内部通信， 这也就意味着外部不能操作除聚合根以外的任何类进行数据库操作，因为这样有可能会导致破坏业务的规则。举个例子，一个汽车四个轮子，如果我们用 Repo 直接操作轮子，对轮子采取elete，而这个时候汽车对象的状态却可能是 "runnng".如何选出聚合根1、聚合根一定至少有一个对应的atastore 2、聚合根一定更够完全描述一组后者多组业务规则(narant)。绝对不会存在一个业务规则需要多个聚合根联合作用才能做判断的。3、聚合根一定有自己的独立的生命周期。 七、规范设计项目应用的规范设计的长期价值一定是不可忽视的，规范就相当于一个架构内部组件的收纳的容器，架构指定了这些组件在逻辑上的组织形式，但而规范则是则是妥妥的物理组织形式。如果没有合理清晰的规范设计，项目很快就会因为个人开发习惯的不同，导致物理结构混乱，给接下来的应用项目的维护和扩展产生影响。规范设计总共分为两类：放对位置程序架构目录贴好标签类名约定方法名约定错误码约定Doman Eent约定测试约定下面是我们小团队参考了阿里COLA框架建议的命名规范做出的开发规范：程序架构组织层次包名功能Aapter层web处理页面请求的Controllermtop处理mtop的请求hsf处理hsf的请求scheuler处理定时器的请求message处理消息的请求App层executor处理request，包括comman和queryconertor包含转换层类的目录nterceptor包含拦截器目录extpont扩展点目录extenton扩展实现目录hanlerapp 层的一些中间处理逻辑Doman层moel领域模型ablty领域能力，包括DomanSercegateway领域网关，解耦利器extpont扩展点目录extenton扩展实现目录Infra层gatewaympl网关实现mapperbats数据库映射confg配置信息Clent SDKap服务对外透出的APIto服务对外的DTO类命名规范种类对象示例API class增删改服务入参XXXCm. e.g. MetrcsRegstratonCm查询服务入参XXXQry. e.g. LstAllMetrcsQryAPI serceXXXSerceI.jaae.g. MoMetrcsAmnSerceI出参如果是无需返回返回使用Cola框架的Response, 如果是单个概念返回使用Cola框架的SngleResponse, 如果是多个概念返回使用Cola框架的MultResponse. 如果概念是某个明确的对象，例如MultResponse如果是复合对象， 使用XXXResult 例如MultResponse领域层实体XXXE.jaa值对象XXXV.jaa工厂XXXFactory.jaaReponstoryXXXRepostory.jaa域服务XXXDomanSerce.jaa防腐服务XXXGateway.jaa枚举XXXEnum.jaa应用层命令执行器XXXXCmExe.jaa查询执行器XXXXQueryExe.jaa拦截器XXXInterceptor.jaa扩展接口XXXExtPt.jaa扩展实现XXXExt.jaae.g. #{Bz}#{userCase}#{scenaro}Ext.jaa转换器XXXConertor.jaa基础设施层存储的对象XXXPO.jaa仓库实现XXXReponstoryImpl.jaa防腐服务实现XXXGatewayImpl.jaa公共层工具类XXXUtl.jaaThreaLocalXXXThrealocal.jaa其他接口XXXI.jaaSprng配置类XXXConfguraton.jaa配置属性聚合类XXXPropertes.jaa错误码规范 扩展规范使用COLA的扩展框架去实现。COLA的扩展框架的功能不在赘诉，这里讨论的是COLA框架的BzScenaro的划分。 BzScenaroprate Strng bzI = "#efaultBzI#"; prate Strng useCase = "#efaultUseCase#";prate Strng scenaro = "#efaultScenaro#";bzI: 业务，对应某个业务诉求， e.g. 新品孵化。useCase: 业务用例， e.g. 策略定义scenaro：用例下的某个场景。e.g. 定义商家事件任务， 定义小二事件任务全局业务通用实现@Extenton某项业务通用实现@Extenton(bzI=XXX)某项业务,某个用例的通用实现@Extenton(bzI=XXX, userCase=YYY)某个具体实现@Extenton(bzI=XXX, userCase=YYY,scenaro=ZZZ)参考：【1】「技术人生」专题第1篇：什么是技术一号位？ ：https:www.sohu.comna465299450_612370【2】https:tme.geekbang.orgcolumnartcle6605：https:tme.geekbang.orgcolumnartcle6605【3】https:bake.bau.comtem%E9%97%AE%E9%A2%98%E5%9F%9F7181289?fr=alan【4】实现领域驱动设计. 电子工业出版社：https:book.ouban.comsubject25844633【5】https:gthub.comalbabaCOLA
软件设计
2023-04-04
[实验室] 千妙科技技术栈 2023年版
后端主程：Golang 1.20Python3 (RPA机器学习人工智能)PHP 8前端Jaascrpt(Typescrpt)Vue3 Nuxt3 H5微信小程序钉钉小程序Anro OS 原生开发设计Aobe IllustratorFreworksOBS必剪剪映网站Nuxt3Golang 1.20Mysql 8Lnux + Docker云计算基础环境：腾讯云华为云CDN、图床、媒体处理：七牛云代码私有托管：gtee 码云
SaaS,RPA,大数据,人工智能,智能制造
2023-03-27
浙公网安备33020302001030号浙ICP备15001112号-2
品牌：千妙科技 Qianmiao Cloud
运营：宁波千妙科技有限公司
站点索引