“家家泉”完成近亿元B轮融资，沣途资本领投
06-17
【技术创造训练营第二季】项目架构设计与模块规划.pptx开场 大家好，我是专业出身的程序员猿，目前从事前端开发工作。我记得刚从学校毕业开始工作时，我对项目架构这个词非常陌生，也不知道什么是架构。
但随着我在开发工作中积累的技能和编程思维的积累，我逐渐明白了什么是架构设计。这就是我今天要分享的主题，所以大家就跟随我的脚步，回顾一下我自己对前端项目架构设计和模块规划的理解。
关于我我是一名拥有6年一线开发经验的程序员。我主要从事移动开发和前端开发。
我掌握的开发方向包括：iOS开发、Android开发、微信小程序开发、Flutter开发、Vue.js开发。同时，我也管理和维护自己的名片、公众号和微博。
如果你对我感兴趣，可以搜索我的名字并添加（求婚的除外），哈哈。什么是建筑？架构是事物之间宏观的联系，主要分为以上三个方面： 1. 一切需要理解的东西，不限于软件。
软件只是这些事物的一个缩影模型。 2.宏观经济调整难度大、影响大、成本大。
高 不要让细节压倒你的思维 3. 连接中如何分工 - 如何内聚协作 - 耦合架构的三个层次 1. 业务架构 目标组织的业务是什么？这些企业之间有何联系？ 2、组织结构：目标组织分为哪些部门？部门之间的分工是怎样的？这些部门如何协作？ 3. 系统架构 有哪些IT系统支撑业务运营？这些IT系统之间有何联系？三种架构之间的联系： 市场环境->业务架构->组织架构->系统架构->竞争力架构的“形”就是知识的边界 1.我们称之为知识域的边界。对知识的准确理解是做好知识设计的关键。
架构的前提是由业务领域驱动进行设计，确保系统跟上业务需求的演变。 2. 领域是架构对齐的基准。
如果你希望架构稳定，就必须使其与知识领域保持一致。架构是否合理取决于领域知识。
判断3.这就是领域驱动设计。为什么应用程序会损坏？ 1. 业务需求不断增加（业务问题） 用户有新需求，我们有新想法，竞争对手拿出新功能 2. 旧功能的残余继续堆积（混合问题） 无法删除（我不知道有没有用）不敢删除（不知道删除了会怎么样）删除不了（和其他功能有着千丝万缕的联系） 3、技术环境的变化（技术问题）例如IE已经退出历史舞台。
用户体验方面 1. 质量（可维护性）差，bug多，修复功能慢，老化，跟不上时代 2. 速度慢（性能） 启动慢/首屏加载慢 日常操作慢 不要被数字指标迷惑，关注用户感知性能 Core Web Vitals 评分机制 LCP - Largest Contentful Paint 最大内容绘制反映加载速度 FID - First Input Delay 第一输入延迟反映交互性 CLS - Cumulative Layout Shift 累积布局偏移反映视觉稳定性 研究和开发 1. 迭代周期太长（性能-开发阶段） 构建太慢，测试太慢 部署太慢。 2、一举一动牵一发而动全身（可维护性）。
我不知道该改变什么。不知道改动后会影响到哪里。
3、统一性、一致性太差（概念一致性）。在某些地方使用红色。
表示警告。有些地方使用黄色。
当同一个控件出现在多个项目中时，外观或者行为方式不同。在项目管理方面 1、琐碎的需求太多（灵活性）。
更改颜色、更改文本、更改布局。这并不完全是产品经理的错。
2、沟通/协作成本高（可维护））容易发生合并冲突。跨团队的API管理成本很高。
分工不明确，难以集中注意力，甚至发生争执。 3、人员风险高。
聘请专家难，新手指导也难。我们总结为对架构的要求： 1、工件体积要小，支持分块加载。
2.应具有良好的可维护性，易于添加和修改。架构组件之间的耦合要小，隔离要严格，并且要局部化。
架构组件的职责要明确，这样分工才能明确架构组件。需要能够独立构建和发布 3.需要区分专家和新手的职责，让每个人都能人尽其才 4.需要对各级可复用资产进行管理。
我们的武器库 1. 工作空间具有共同的依赖关系。软件包通常相互依赖 2. 项目 发布周期/载体相同，由同一个项目团队维护 3. 模块隐藏私有 API，可独立加载 如何进行垂直细分 1. 业务专家必须根据业务领域参与，甚至是由他们主导，如果某些运营是围绕同一个业务理念进行的，则将其划分到相同的子域中。
如果不知道怎么做，可以使用DDD方法论来划分。 2. 明确界限。
功能模块被制作成延迟加载的功能模块。他们不应该出口组件。
他们应该只提供路由路由树。与领域树同构 3. 不同依赖关系的控制子树不应该相互依赖 架构设计流程 1. 对业务知识进行建模 业务专家架构师 2. 根据知识边界划分子域 业务专家架构师 3. 映射到系统架构师技术主管它解决了什么问题？ 1、工件尺寸要小，支持分块加载特征模块的懒加载机制。
2、可维护性要好，易于添加和修改。功能模块的所有组件都是私有的，所有影响都限制在很小的范围内。
3.架构组件之间的耦合要小，隔离要严格，功能模块的跨子树依??赖要本地化并禁止。 4、架构组织的职责要明确，这样可以根据业务领域进行明确的分工，以及如何将业务知识本土化，做好横向切割。
要点： 1、做好版本管理，严格遵循语义版本规范。 2、做好关注点分离，技术问题和业务问题分离，简单问题和复杂问题分离。
3、组件库不应仅限于源代码库。形式可以是传统的源代码库。
它可以是一个独立发布的应用程序（Web Components库）。组件库的最佳实践： 1. 私有是规则，公共是例外。
如无必要，请勿公开。公开意味着向他人做出承诺。
向别人许下承诺很容易，但收回承诺却很难。 2、区分业务无关的组件库和业务相关的组件库。
前者只解决技术问题，不涉及和商业理念。后者是在前者的基础上进行封装的，只解决业务问题。
3. 拆分成多个小组件。例如，在表单中使用的编辑器应分为独立于表单的编辑器和控制访问器命令。
而不是直接给支持表单的编辑器开发团队建立合理的分工 1.架构师全栈：业务+前端+后端，着眼大局，不一定专业 2.专攻某一领域的技术专家、解决核心技术问题等 团队共享或外部聘用 3. 资深前端工程师，熟悉业务，擅长前端，懂后端 4. 资深后端工程师，熟悉业务业务，擅长后端，懂前端 5.新手工程师可以选择自己喜欢的领域，可以轮换角色 结论通过以上部分的分析，大家可以看到项目的架构设计和模块的大致体系规划。上述注意点可以在以后的开发中使用，达到整体的认识。
感谢您的收听，敬请关注。”表达这一点的唯一方式是“三掌柜”。
版权声明：本文内容由互联网用户自发贡献，本站不拥有所有权，不承担相关法律责任。如果发现本站有涉嫌抄袭的内容，欢迎发送邮件 举报，并提供相关证据，一经查实，本站将立刻删除涉嫌侵权内容。
标签：
相关文章
06-17
06-17
06-18
06-18
06-17
06-17
06-18
06-18
最新文章
【玩转GPU】ControlNet初学者生存指南
【实战】获取小程序中用户的城市信息（附源码）
包雪雪简单介绍Vue.js：开学
Go进阶：使用Gin框架简单实现服务端渲染
线程池介绍及实际案例分享
JMeter 注释 18 - JMeter 常用配置组件介绍
基于Sentry的大数据权限解决方案
【云+社区年度征文集】GPE监控介绍及使用