导语 | 腾讯前端工程师唐霜在React项目中，尝试使用DDD方法论为业务对象建模，其所在团队形成良好的业务沟通规范和业务逻辑沉淀流程，构建了更加稳固的业务系统。作者将多年的积累探索经验总结分享出来，从对业务的思考、react项目的特征出发，阐述在项目中进行的前端DDD探索。欢迎阅读和交流。 前言 我们所处的业务团队服务于腾讯某投资部门，系统涉及的投资相关业务在国内具有典型意义，是覆盖一级市场、二级市场、基金的多品类全流程的投资系统。其中包含了对投资项目本身的业务处理，也包含了投资流程的工
携程机票前台团队在使用 React Native 实现众多业务的过程中，经历了前期少量探索，中期大量应用，后期架构和性能优化的三个阶段。
下面的自带响应式，getter，setter 也自动给出了，同时使用了工厂模式，不需要了解函数内部的逻辑。
上篇文章大致总结了plantuml的基本用法。今天聊一聊使用Taro开发小程序进行多端适配的问题。
这两个概念是早些时候 Martin Fowler 总结出来的两种常见模型设计类型，没有说谁好谁不好，为不同的模型类别选择合适的场景是设计者的工作。没有工具本身的问题，只有工具使用者的问题。
React Server Component（后文简称RSC）是React近几年最重要的特性。虽然他对React未来发展至关重要，但由于：
前两篇教程介绍了 Redux 的基本用法和异步操作，今天是最后一部分，介绍如何在 React 项目中使用 Redux。 为了方便使用，Redux 的作者封装了一个 React 专用的库 React-R
给组件输入一个参数，最终返回一个 React Element,React Element 就是在页面上展示的内容，相当于一个 DOM 节点
一个复杂的应用都是由简单的应用发展而来的, 随着越来越多的功能加入项目, 代码就会变得越来越难以控制. 本文章主要探讨在大型项目中如何对组件进行组织, 让项目具备可维护性.
业务系统和一般的应用有非常大的不同，一般的应用以提供给公司/企业外的用户（消费者、普通玩家）提供服务，以完成2C的销售目的，而业务系统一般是2B或者自身消费的模式，完成的是自身业务的管理目标。所以，应用侧重服务，业务系统侧重管理。两者的不同，导致我们对项目开发中，代码的组织方式会有差别。2C应用要满足大量用户在使用时的舒适性，因此要提高项目中有关性能、用户体验、效果等方面的要求，以吸引用户付费。但业务系统则稍有差别，虽然系统的使用体验也很重要，但是不是占最重要的部分，业务系统最重要的部分，是必须保证用户看到的数据、流程等，必须与真实的业务、业务流程一致，否则会带来自身利益的损失，因此，在稳健性、安全性等方面要求更高。
不过话说来，很多人都认为前端无非就是 HTML+CSS+JS,一个目录一类文件，有何架构可言。但是我想说。。。。你说的都对！
人们习惯将系统分为三个组件：UI，业务逻辑，和数据库。对于一些简单的系统来说，三个就够了，但是稍微复杂一点的系统组件就不止这三个了。
概述 近年来，随着浏览器性能的提升与移动互联网浪潮的汹涌而来，Web前端开发进入了高歌猛进，日新月异的时代。这是最好的时代，我们永远在前行，这也是最坏的时代，无数的前端开发框架、技术体系争妍斗艳，让开发者们陷入困惑，乃至于无所适从。Web前端开发可以追溯于1991年蒂姆·伯纳斯-李公开提及HTML描述，而后1999年W3C发布HTML4标准，这个阶段主要是BS架构，没有所谓的前端开发概念，网页只不过是后端工程师的顺手之作，服务端渲染是主要的数据传递方式。接下来的几年间随着互联网的发展与REST等架构标准的提
可以说 React 是构建 web 应用最流行的库。然而，它并不是全能的 web 框架。它只关注 MVC 中的 view 模块。
当你进行用户需求调研后，往往收集到的都是一个个的用户需求点，而一个软件需求分析员要做的是最终将这些需求实现为一个完整的业务系统。这里面就涉 及到业务模块的划分，模块间的分析，需求层面的复用能力分析，各种性能，可靠性，安全等非功能性需求。这些更加已经是一个完全的系统分析方面的内容，或者 说软件需求已经会兼顾部分软件架构设计的内容，因此作为一个软件需求人员更加需要去了解业务组件化，服务化，软件模块集成，复用等方面的技术内容。也需要 去了解涉及到交互设计方面的内容，这些都是形成一个高质量的软件业务系统的重要输入。
从 PC 时代、移动时代到万物互联的 IoT 时代，伴随终端设备的日趋多样化，跨端复用的种子自此落地，开始生根发芽。从依靠容器能力、各类离线化预装包的 Hybrid 方案，到通过 JSC 连接 JavaScript 生态与原生控件，结合视图框架（React、Vue等）寻找效率、动态性和性能更均衡的 Native 容器方案（React Native、Weex 等），接着由微信牵头的以多进程 WebView、容器标准化的小程序方案出世，各平台小程序随之春笋萌发，随后带来了国内Taro、uni-app、Rax、Remax等多端框架的百家争鸣。
有赞作为一家 SaaS 公司，除了传统的微商城，还提供了零售、美业等产品解决方案。随着公司业务的快速发展，各业务系统也不断的进行着功能迭代或系统重构，如何保证这个过程中系统功能的正确性和服务的稳定性，是公司测试和开发人员需要面对的一个重要挑战。
摘要 以React技术栈为主分享我们在大规模企业应用建设过程中遇到的问题，对前后端分离架构的思考，前后端分离的技术方案，前后端分离过程中的实践经验，前后端分离带来的效果与价值，以及目前存在的问题与未来可能的尝试。 嘉宾演讲视频及PPT回顾：http://suo.im/2A3F57 应用的现状 我们的应用拥有接近100w的用户、3K+的QPS、5亿+的单表数据、万亿级别的资金流，但是同样也面临着诸多问题。 首先是颜值低，换肤受限、无法集成更好的前端框架和组件。然后是前后端的高度耦合使得无法快速的响应业务变化，
基础代码的复用往往比较简单，但是业务代码的复用通常是困难的，如果没有特殊的手段去治理项目会逐渐发展为难以维护的巨石应用，按照维基百科记载，代码的复用形式主要有三种，程序库，应用框架，设计模式
Angular是最早声称基于MVVM架构的前端框架，但在我眼里，Angular根本没有M这一层，React和Vue也好不到哪里，目前最热的三大框架，都只是V层前端框架，和M层谈不上什么联系。
随着软件系统越来越庞大，需求越来越模糊，代码越来越混乱，测试越来越困难，技术演进基本不可能，而其中大型复杂的软件项目更容易走向系统老化的过程，形成需求难、开发难、测试难、创新难，单体架构局部业务膨胀可以拆成微服务，那么微服务局部业务膨胀又应该怎么做？DDD之所以火，即能解决微服务解决不了的问题。DDD是为了解决快速变化、复杂系统的设计问题。
本文将会很少涉及 dotnet 的知识，主要讲用定义过滤的方式解除过程业务的耦合。在一些业务上，可以从业务层面或逻辑层面明显分为几层，每一层之前的数据相互依赖或处理顺序相互依赖，但逻辑都独立。此时如果将业务处理放在过程处理里面，将会让过程处理耦合具体业务。而定义过滤的方式为让过程逻辑只是搭建框架为主，具体业务通过注入过滤的形式加入到处理
当今互联网+高速崛起，大前端这个概念已经成为前端技术老生常谈的话题，但去做好“大前端”，并不容易。
有时我们需要知道一款产品上线后的受欢迎程度，推广效果、有多少人安装、使用率，平均在线时长、活跃用户、启动次数、版本分布等数据，这个时候我们不得不用到统计分析。如果条件允许我们可以自己实现统计分析的功能，但如果要做的很专业很详细那么则需要一个庞大的工作量。在这里我们也可以采用第三方统计umneng。 在这篇文章中我会向大家分享，在React Native中集成umeng统计的方法及流程。因为umeng官网有非常详细的集成文档集成文档，在这里我会介绍在React Native的Android和iOS中如何集成统
最近在做一些项目重构的工作，看了不少脏乱差的代码，身心疲惫。本文将讨论如何编写整洁的代码，不求高效运行，只求可读性强，便于维护。
SOA 是一种在计算环境中设计、开发、部署和管理离散逻辑单元（服务）模型的方法。 SOA 并不是一个新鲜事物，而只是面向对象模型的一种替代。虽然基于 SOA 的系统并不排除使用 OOD 来构建单个服务，但是其整体设计却是面向服务的。由于 SOA 考虑到了系统内的对象，所以虽然SOA 是基于对象的，但是作为一个整体，它却不是面向对象的。
作为一名精致的前端猪猪女孩，也有那么点想让自己的代码同样看起来精致一点。所以在拿到新需求的 UI 设计稿时，经常会面临如下问题：如何拆解页面？如何划分组件才算是合理？好像用于组件拆分的 A 方案和 B 方案在当前业务场景下也都还算合理，那究竟要怎么选择？组件的抽象与粒度貌似是一个老生常谈的问题了～学习了很多前辈的文章，那么今天结合业务场景，也来讲下我的心得～
其实写到这里，相信大家已经明白我的价值倾向了。在没有企业包袱的角度来看，大厂都是 react 为先😯， 我更加推荐使用 vue，原因如下👇
过去的一段时间和一些架构师 / 技术负责人聊天，云原生和企业上云是最近一段架构演进的一个常见话题，那么小公司到大型公司在上云和云原生上有什么价值和收益呢。
架构模式的出现时为了管理复杂的应用程序，这样可以在一个时间内专门关注一个方面。例如，您可以在不依赖业务逻辑的情况下专注于视图设计。同时也让应用程序的测试更加容易。同时也简化了分组开发。不同的开发人员可同时开发视图、控制器逻辑和业务逻辑。我们经常说的MVC架构、MVVM架构属于此类。
写在开头 去年CTO一直跟我在宣扬faced模式，但是当时没有get到它的点 等我get到的时候，他已经不在我身边工作了，真是一个悲伤的故事 阅读本文前需要先了解的知识点 什么是react hooks
如果我仍然去解释什么是状态管理器，为什么我们需要它，这篇文章将会索然无味。我的想法是，我们原本不需要状态管理器，但我们确实需要状态管理。
组件间逻辑复用一直是个问题，Render Props、Higher-Order Components等常用套路模式都是为了分离横切关注点（Cross-cutting concern），复用诸如：
本文将介绍在具体业务实践中，携程玩乐团队一套代码多端复用的一些实践与经验，希望能给面对同样问题的同学提供些思路和参考。
createElement函数， 三个参数， 第一个参数是html标签或自定义组件，第二个参数一个obj（包含props， on...等等）， 第三个参数children(通过createElement构建， 或者字符串)
软件架构的发展经历了从单体架构、垂直架构、SOA架构到微服务架构以及到现在最新的service mesh（网格服务架构）的过程。借用dubbo的网站架构发展图和说明：
Tech 导读 组件化渗透在开发的方方面面，本文主要从“为什么”、“是什么”、“怎样做”三方面来系统讲述前端组件化的相关知识。通过阅读本文，读者可以对组件化形成一个更加深入的认识和理解。在实现前端组件化的过程，大家可以更加关注组件化的目的，需求及其特点，了解前提才能结合项目来思考如何更好的拆分和实现组件化。 01 思考：为什么要实施前端组件化？ 在项目开发中，页面和功能大都拆分为多文件来实现，多文件管理逐渐暴露出以下问题： 1.相似的业务代码无法复用：X同事实现了一遍A页面，Y同事要实现一个和A页面类似
注意：本文极长，超过17000字，可能需要花30分钟以上才能阅读完，且内容要点密集，可能需要在读后花费比较多的精力和时间深入理解。
传统模式下，企业的经营活动会产生大量的业务数据。财务人员需要根据业务数据，进行会计核算，并输出财务数据。通过这些财务数据，企业可以进行财务管理、财务分析、业务决策。但会计核算的工作量非常庞大，大多工作也比较基础、简单，可以被计算机替代。企业每年在基础的核算工作上会花费大量的人力资源，在更重要的财务管理、财务分析、业务决策上无暇顾及。为了解决此类问题，财务中台应运而生。
AIGC 这一时代潮流已然不可阻挡，我们要做的不是慌乱，而是把握住这个时代的机会。本文就和大家一起来探索在 AIGC 下，前端工程师即将面临的挑战和机遇。聊聊从以前到现在，AIGC 给我们带来了怎么样的变化，下一代前端工程师又该何去何从？
创业之初，我们往往会为了快速迭代出产品，而选择最简单的技术架构，比如LAMP架构，SSH三层架构。这些架构可以适应初期业务的快速发展，但是，随着业务变得越来越复杂，我们会发现这些架构越来越难支撑业务的发展，出现在一个类中写好几千行代码，一个方法中到处都是if else语句，如果中间遇到主程序猿离职，后面介入的程序猿几乎无法理解这些代码，到最后，产品越来越难迭代，只能推翻重做。如果我们在创业初始就以一种适应性较强的架构去写代码，后面就会少走很多弯路。下面的文章是我自己总结出来的一套架构，经过实践，适应性还算不错。
关于Android架构，可能在很多人心里一直都是虚无缥缈的存在，似懂非懂、为了用而用、处处生搬硬套，这种情况使用的意义真的很有限。本人有多个项目重构的经验，恰好对设计领域较为感兴趣，今天我将毫无保留的将自己对架构、设计的理解分享给大家。
随着应用程序单页面需求的越来越复杂，应用状态的管理也变得越来越混乱，而Redux的就是为解决这一问题而出现的。在一个大型的应用程序中，应用的状态不仅包括从服务器获取的数据，还包括本地创建的数据，以及反应本地UI状态的数据，而Redux正是为解决这一复杂问题而存在的。
在使用类似Vue,React框架时，我们一定会使用状态管理吗？这个答案是肯定的。或许我不会主动去使用Vuex, Redux，但我们编写每一个组件的时候就已经在管理状态，Vuex, Redux只是更方便我们进行全局的状态管理。
UserEntity 和 UserRepository 组成了数据访问层，UserBo 和 UserService 组成了业务逻辑层，UserVo 和 UserController 在这里属于接口层。
1、通用架构概述 创业之初，我们往往会为了快速迭代出产品，而选择最简单的技术架构，比如LAMP架构，SSH三层架构。这些架构可以适应初期业务的快速发展，但是，随着业务变得越来越复杂，我们会发现这些架构越来越难支撑业务的发展，出现在一个类中写好几千行代码，一个方法中到处都是if else语句，如果中间遇到主程序猿离职，后面介入的程序猿几乎无法理解这些代码，到最后，产品越来越难迭代，只能推翻重做。如果我们在创业初始就以一种适应性较强的架构去写代码，后面就会少走很多弯路。下面的文章是我自己总结出来的一套架构，经过
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
即时通信 IM
ICP备案
对象存储
实时音视频
