软件架构

作者：京东科技  倪新明设计用意的传播是架构可视化关注的重要维度，在技术计划评审过程中不可避免的会呈现各种各样的架构图或设计图，这些图形化表述在设计用意传播成果层面体现不一，本文从图形化的视角为软件架构图的评审关注点提供了参考。 注：对于架构及架构可视化参考文章 《 探寻软件架构的实质，到底什么是架构？》 《 软件架构可视化及C4模型：架构设计不仅仅是UML》 1 准则•明确的主题：架构图要表白的用意明确，比方是容器图、组件图还是部署图 •统一的形象层级：保持一致的形象层级，不应超过2个以上的档次变动 •粒度适合的范畴：不应试图在一张图表白“所有的货色”，每张架构图聚焦于本身职责边界的范畴 •清晰的图例阐明：对架构图色彩、形态等有明确的图例，以不便浏览导航 •图形色彩不宜太多：过多色彩减少认知老本，倡议不超过 4 种 •图形元素不宜太多：过多图形元素减少认知老本 •明确的连线关系形容 2 评审检查单如同上线检查单和开发检查单，针对于软件架构图的评审制订一套检查单同样具备价值。不管架构设计者，还是参加设计评审的开发人员，对于形式各异的 “架构图” 是提供通用的参考关注点，以便干系人更多、更深刻、更高效、更有针对性的获取架构图的更多信息。 2.1 通用查看项架构图是否具备题目? 是否可能了解架构图的类型是什么？ 是否可能了解架构图的范畴是什么？ 架构图是否有图例？ 2.2 元素架构图中每一个元素是否有名字？ 是否可能了解架构图中每个元素的类型？ (比方，形象级别，软件系统？容器？组件？等等) 是否可能了解架构图中的每个元素是做什么的？简要形容信息？ 是否可能了解与该元素相干的技术选型（适宜表明技术选型的元素） 是否可能了解架构图中应用的所有缩写/简称的含意? 是否可能了解架构图中元素应用的所有色彩的含意 是否可能了解架构图中元素应用的所有形态的含意 是否可能了解架构图中元素应用的所有图标的含意? 是否可能了解架构图中元素应用的所有边框款式的含意? (比方，实线 vs 虚线) 是否可能了解架构图中应用的所有元素大小的含意? (比方， 小框 vs 大框 ） 2.3 关联关系架构图中的每条线是否有形容关系含意的信息? 是否可能了解架构图中的每个关联关系（适宜表明技术选型的场景）的技术选型是什么？ (比方，过程间的交互的协定) 是否可能了解架构图中的关联关系的简称或缩写？ 是否可能了解架构图中的连线色彩的含意？ 是否可能了解架构图中的连线箭头的含意? 是否可能了解架构图中的连线款式的含意? (比方，实线 vs 虚线) 3 结语本文形容了软件架构图的一些评审关注点，其实不只是评审的视角，对于任何一个图形化的软件系统架构或设计表诉，如何可能疾速的理解其要表白的用意至关重要，对于设计者而言如何疾速传递架构设计信息并于干系人达成统一也至关重要。

研发工作重，手动同步状态和信息，分身乏术； 信息不通明，跨职能成员协调难、沟通老本高； 负责人到任，我的项目细节和代码信息却无从理解； …… 传统研发流程中，机械反复和信息孤岛或成为妨碍高效合作的头等因子。数字化与信息化的浪潮袭来，基于零碎和工具优化治理形式，构建数据闭环和流程自动化是研发提效的主旋律。 本文将从需要痛点解析和解决方案倡议两个方面，对研发效力优化开展解读，帮忙企业更好地打造坚硬、可继续倒退的研发生态。 一、研发流程治理中，企业的要害需要和痛点是什么？01 五个要害需要企业研发流程治理的五个要害需要别离是平安、自主可控、高效、低成本和可拓展。 安全性。包含代码平安、数据安全等。企业能够应用独立的代码仓库、依赖服务/数据可私有化等进步安全性。自主可控性。企业的外围业务应自主可控、不受限于内部；常通过可扩大的、可信的开源组件提供本人的服务实现。高效性。继续通明的研发流程是高效运行的低线。企业应建设无效的麻利项目管理机制，并联合DevOps进行继续集成与构建，谋求更高效的研发流程治理。低成本。我的项目研发要把资源用在刀刃上——通过正当的资源调配，产生尽可能低的附加老本，将无限的资源施展出最高性价比。可扩展性。满足当下技术须要的同时，企业还该当与可扩展性共成长，将可继续倒退贯彻到底。02 人治治理痛点人治管理模式下，研发流程治理非常灵活，但也存在诸多限度：我的项目信息不通明、代码同步滞后、状态更新消耗时力、信息传递易出错等等； 更重要的，我的项目信息和研发继续输入难以造成良性闭环，信息孤岛极大地限度了治理优化的下限。 其次，因为个体能力差异和能力阈值限度，忽略和谬误总是在劫难逃；南征北战的新手如若不足趁手兵器，也无奈保障高效交付高质量成绩。 除此之外，随着研发效力越来越受企业器重，研发流程治理也延长出更多的诉求： 有没有一种更稳固、可控的治理形式？企业如何依据本身状况定制计划，解决问题？哪些可借鉴的流程治理教训可减速突破难关？如何实现低成本、高效益的研发流程优化？在信息化的旅程中，更多基于人治的治理痛点和需要逐步浮现，企业也开始探究更好的研发流程治理方法和计划。 二、基于SaaS的研发流程治理计划许多实践经验发现，小规模研发团队的效率有时会更高。因为团队越大，部门越多，同步和沟通就变得复杂，再加上不足适合的工具佐助，协同老本便会大大增加。 相比之下，应用零碎/工具搭建流程闭环，或者是更高效的治理形式。而基于零碎提效的外围就是解决协同问题——代码协同、我的项目协同，以及代码和我的项目间的协同。 01 代码协同工具——GitLab对所有研发型企业来说，其外围资产就是代码，而云版GitLab能够满足代码治理、CI/CD、常识治理等需要。小规模团队应用云版GitLab，甚至能够不须要Jenkins或运维团队；如果想要进行代码私有化治理，能够思考托管版的GitLab。 同时，GitLab还领有丰盛的拓展能力，比方Jenkins、镜像仓库、maven仓库、K8S集成等等，对于买通研发全流程有显著意义。 02 容器化工具——Kubernetes随着研发团队的规模逐步变大，具备业余的运维团队，须要更多的资源协调能力时，企业可能会思考抉择容器化工具如Kubernetes。 在GitLab应用K8S集成能够实现主动编排，让部署容器化利用简略又高效。 代码是研发流程中最重要的产出，而GitLab以代码为外围，可能以极低的代价（甚至无需运维老本）实现简略的CI/CD流程，还能以私有化部署解决代码治理问题，晋升代码协同治理的效率。 显然，GitLab解决了局部的继续集成问题，然而在定制化我的项目研发流程和我的项目信息协同方面，却不肯定能满足企业需要，因而咱们须要一个可将两者联合的研发流程治理计划。 三、精简的研发全流程治理计划：LigaAI+GitLabLigaAI是新一代智能研发合作工具，通过AI赋能研发合作，解放人工机械工作，让人工智能成为企业生产力的一部分。 LigaAI解决我的项目信息协同问题，而GitLab通过DevOps解决代码协同问题；二者的集成联合可进一步实现我的项目和代码的无效协同，最终达成三个层面的研发效力晋升指标。 01 LigaAI+GitLab，如何实现「我的项目-代码」协同？LigaAI与GitLab的集成实现了我的项目信息和代码信息的双向同步。研发团队能够间接在LigaAI查看GitLab的代码提交和合并申请记录，还能间接创立分支、提交合并申请，疾速轻松地实现代码治理。 实现集成后，应用LigaAI丰盛的工作表组件，研发管理者可在工作台清晰地理解成员效力与代码提交状况，实现研发效力可视化，更及时地作出布局调整与治理。 通过配置【LigaAI-智能助理】，执行以创立Git提交为触发节点的主动执行规定，自动化研发合作流程，打消更新、同步和告诉等简单机械的工作； 或者应用LigaAI IDE插件中的模板，快捷提交代码并主动提取关联工作信息，缩小反复操作，开释更多生产力。 02 LigaAI+GitLab，如何实现研发流程可拓展性？LigaAI反对多种内部集成形式，如工具集成开发、丰盛的Open API和WebHook配置等，串联跨零碎/工具的我的项目和代码信息，赋能企业打造研发全流程的信息闭环。 通过形如「LigaAI + GitLab + Jenkins + K8S + IDE插件 + 飞书WebHook」的拓展利用，在实现代码治理和项目管理的同时，还能够借助人工智能等信息化工具，建设开发信息标准、晋升代码品质、构建自动化研发流程，并造就弱小的可拓展能力、大规模部署能力和容器化治理能力，最大水平地晋升研发效率。 Liga总结研发效力优化与晋升是企业降本增效的重要命题。与人治治理相比，基于零碎的研发流程治理办法更加合乎企业定制化治理和低成本转型的需要。 「LigaAI+GitLab」的精简化流程治理计划可能在实现我的项目协同和代码协同的同时，买通我的项目信息与研发继续输入的壁垒，实现我的项目与代码间的协同，并通过丰盛的可拓展计划打造研发全流程数据闭环，高效赋能研发团队稳步晋升。 对于 LigaAILigaAI是新一代智能研发合作平台。咱们以人工智能技术为外围，致力于通过AI场景化繁为简，晋升合作效率，赋能宽广研发团队。 从开发者的具体工作场景登程，LigaAI通过人工智能将开发者们从繁冗琐事中抽离进去，为其提供简洁、智能的合作体验，也为不同类型的组织提供数字化、个性化、智能化的我的项目合作平台。 理解更多麻利开发、项目管理、行业动态等音讯，关注咱们的sf账号-LigaAI~ 或者点击LigaAI-新一代智能研发合作平台，在线申请体验咱们的产品。

原文：Clean architecture for the rest of us 作者：Suragch 这是一篇介绍性文章。如果你是一名高级软件工程师，能够到此为止了，这篇文章不适宜你。这篇文章是写给那些像我一样的一般程序员的，他们写着乌七八糟的代码，创立着像意大利面一样凌乱的架构，但却对构建洁净的、可保护的、适应性强的货色很着迷。 前言我通常不购买计算机相关的书籍，因为它们切实是过期的太快了。还有就是，反正这些书中信息在网上都能够查失去。但在一年前，我浏览了 Robert Martin 编写的 Clean Code，这本书实在的帮我改善了开发软件的形式。所以，当我看到同一作者另外一本书《Clean Architecture》出版的时候，便毫不犹豫的买下了它。 和 Clean Code 一样，Clean Architecture 中讲述了大量经的起工夫考验的准则，这些准则实用于任何人编写的任何代码。如果你在网上搜寻书名，会发现有些人并不认同作者的观点。显然，我不是要在这里批评他。我只是晓得 Robert Martin （又名 Uncle Bob）曾经从事编程超过50年，而我没有。 只管这本书了解起来有点艰难，但我会尽最大致力，把书中的重要概念加以总结和解释，让普通人也可能了解。作为一名软件架构师，我依然在一直学习成长，所以，请以批评的眼光浏览我写的货色。 什么是 clean architecture?架构 (Architecture) 是指我的项目的整体设计，是代码放入类(classes)、文件(files)、组件(components)、模块(modules) 的组织构造，以及这些代码单元之间互相关联的形式。架构定义了应用程序在哪里执行外围性能，以及这些性能如何与数据库、用户界面等事物进行交互。 Clean 架构是一种易于了解、能够随着我的项目倒退灵便扭转的我的项目组织形式。这不是随随便便就能够办到的，须要无意识的布局。 Clean architecture 的特点构建一个易于保护的大型项目的秘诀是：将类或文件拆分到不同的组件中，每个组件都能够独立于其余组件进行批改。让咱们用几张图片来阐明这一点： 下面的图片中，如果想用刀代替剪刀，你须要做什么？你必须解开连贯到笔、墨水瓶、胶带和指南针的绳子。而后你再将这些物品从新系到刀上。兴许这对于刀来说是能够了。但如果钢笔和胶带说：“等等，咱们须要剪刀。” 所以当初笔和胶带不能失常工作了，不得不在做扭转。这个扭转反过来又会影响那些连贯到它们下面的相干物体。 一团糟。 比照下图： 当初咱们应该如何替换剪刀呢？咱们只须要从便当贴上面拉出剪刀的绳子，而后把系在刀子上的新绳子插进去。容易多了。便当贴不在乎，因为绳子甚至没有绑在它下面。 第二张图所代表的架构显然更容易扭转。只有便当贴不须要被常常的更换，这个零碎就很容易保护。同样的，这种架构能够使软件更易于保护和变更。 内圈是应用程序的畛域层 (domain layer) ，用来搁置业务规定。咱们所说的“业务”不肯定是指公司，它只是意味着你的应用程序的实质，即代码的外围性能。例如：翻译应用程序的外围性能是翻译，线上商店的实质是要发售商品。这些业务规定通常相当的稳固，因为你不太可能常常扭转利用的实质。 外层是基础设施层 (infrastructure layer)，包含 UI、数据库、网络 API、以及软件框架之类的货色。绝对于畛域，这些更容易发生变化。举个例子，你更有可能更改 UI 按钮的外观，而不是更改贷款的计算形式。 畛域和基础设施之间设置了一个显著的边界，目标是让畛域对基础设施毫无感知。这意味着 UI 和数据库依赖业务规定，但业务规定不依赖 UI 和数据库。这使它成为一个插件架构 (plugin architecture)，无论 UI 是一个网页、桌面应用程序、还是挪动利用都没有关系；数据是存储在 SQL、NoSQL 还是云端也没有关系，畛域基本就不关怀。这使得更改基础设施变得非常容易。 ...

文｜吴成辉（花名：清霄 蚂蚁团体高级技术专家) 校对｜陈真、庄晓丹、冯家纯 本文 6250 字 浏览 11 分钟 ▼ 咱们一起回顾下监控下层业务已经面临的问题： 烟囱式的监控剖析反复建设在技术危险畛域，一度有超过 5 个零碎在做监控剖析的能力建设，大抵逻辑根本都是拉监控的 Raw Data，做根底的聚合、剖析解决后（相似同环比、阈值类的形式），依据一些以后的场景输出，联合一些算法能力，得出一个论断并触发一系列的 Action。相似这种烟囱式的监控剖析场景，都是比拟高级的反复建设，不足智能化、体系化。 SRE 教训标准化积淀的问题在剖析场景里也面临 SRE 教训无奈标准化积淀复用的问题，什么是 SRE 教训？拿交易付款上涨来举例，如果以后交易付款上涨 10%，SRE 通常有这么几个剖析门路，首先看下淘宝交易是否上涨（起源），再看交易创立，收银台渲染是不是上涨等，这一类咱们称为业务依赖。从全局看是否有大规模的压测、变更等动作，这一类称为变更关联，以及如何依据以后故障状况决策进行切流、限流等复原措施，咱们称为剖析后置操作。 长尾需要比方比拟常见的，算多数据之间的成功率，流量损耗等等需要，通过产品化解决的老本十分高，而且用户不能疾速批改、定制相干能力。 同时咱们看到以后监控零碎本身面临的问题： 监控的数据应用简单蕴含了几万张数据表、十几万张自定义数据表，数据类型超过 20+，以及跨站点、数据源异构等等问题。 监控服务不够凋谢如何动静日志荡涤计算、如何做剖析后的时序存储、监控的时序检测能力如何复用等等。咱们须要把监控的数据、能力齐全服务化进去。 高效的可编程代码化平台缺失没有一个高效平台帮忙 SRE 先积淀教训、再促成教训的标准化、复用，最初产品化。 基于下面问题，咱们提出了 MaaS 的构想（Monitoring as a Service), 监控能力服务化，凋谢、交融监控能力到技术危险各个领域，疾速实现 SRE 场景建设，积淀可复用能力，次要蕴含以下 4 个阶段指标： 1.凋谢服务把监控的计算、存储、算法、视图等等能力凋谢进去。 2.外围共建几个重点的技术危险畛域场景，比方变更进攻、压测引流、无损注入、定位应急等等。 3.促成服务的标准化积淀，让更多的场景能够复用、独特建设这部分的能力。 4.解决“监”与“控”之间的链接问题。 （咱们的这里的 AIOPS 更多指的是 一系列专家教训的汇合、积淀、继续保护优化） PART. 1 平台技术概览能力服务化 监控的服务化能力整体蕴含这么几局部，数据服务化、配置服务化、计算、存储服务化、算法服务化、告诉、云原生服务化等等，也包含一些内部能力集成比方音讯缓存等等。 我简略举两个服务化的例子来介绍下什么是服务化： 比方视图服务，当某个变更发动后，这个变更关联的 100 个利用指标、20 个业务指标中的 10 个指标呈现了问题，这个时候，咱们须要动静为这个 10 个指标创立一个数据视图，来剖析业务影响范畴，这个时候就会用到咱们的视图服务。 ...

*导读：畛域驱动设计（Domain Driven Design - DDD）起源于2004年Eric Evans出版《畛域驱动设计》，相比于在国外IT圈享有盛誉且卓有成效不同，国内IT圈理解DDD的人很少，落地实际的少之又少。最近几年随着微服务架构的遍及和中台的衰亡，DDD也成了各大技术论坛和微信公众号文章里常常谈起的话题。* DDD的热度是起来了，但业界介绍DDD的材料大多偏实践，不足生产我的项目可借鉴的实践经验。因而大多人读了很多DDD资料后还是一脸懵，怎么掂量DDD带来的价值？老板能批准搞DDD吗？什么样的业务和团队适宜DDD？DDD跟互联网强调的小步快跑疾速迭代能搭吗？如果要实际DDD产研团队都要做些啥？研发写代码跟平时有什么不一样？本文联合百度爱番番产研团队在过来一年多经验的从摸索、推广到全面落地DDD的过程，尝试答复上述问题，力求给大家带来一些借鉴意义。 全文约9500字，预计浏览工夫25分钟。 1  初心：以客户为核心，产研团队如何高效交付需要百度爱番番围绕营销拓客和销售提效帮忙企业收集、裁减、荡涤、造就、跟进和转化线索。一方面爱番番的业务特点是典型的企业级（ToB）业务，具备肯定的复杂度。业务对象多，单个业务对象提供的性能多，单个性能面向的场景多，业务对象之间组合进去的业务流程多。并且会随着交付的性能越多而变的越简单。另一方面产品处于爬坡阶段，性能须要疾速迭代交付到客户，从而疾速取得客户的反馈。产研团队在资源肯定的状况下如何高效交付更简单的需要成为了主要矛盾。 剖析以后阶段需要迭代过程中的问题，能够总结为以下几类问题： 业务逻辑不能从产品团队精准传递到研发团队，有时研发进行了一段时间开发才发现需要了解有偏差，导致须要从新跟产品经理探讨需要。产品团队和研发团队对于业务复杂度没有的意识不对立，产品经理认为一个需要的开发不难，理当在较少工夫内开发结束。研发团队面对需要增长和变动时，不足对业务逻辑的形象，往往开发一个须要点须要改变多处，容易出错且开发效率低，代码维护性差。需要文档和代码逻辑不匹配，线上性能的业务逻辑为什么实现成那样没有根据可查，畛域常识得不到积淀，团队得不到可继续成长。2  摸索：找到适宜的开发模式上述问题集中体现在两个方面，一是产品属于企业应用类，性能自身简单，如何让产研团队疾速了解业务、疾速交付。二是如何让畛域常识可能比拟精确的失去开发实现，让代码有比拟好的可维护性。借鉴业内解决简单企业级软件的开发教训，加上局部团队成员已经有过DDD应用的教训，团队决定尝试使用DDD设计思维来领导产研团队的日常需要迭代。 2.1  DDD是啥？DDD是一种围绕领域建模来解决简单业务交付的设计思维。读者无妨自问几个问题，什么是简单？什么是领域建模？ 1. 什么是简单？如何了解简单？简单可能是现状业务就简单，也可能是业务日渐演变成简单。简单来自规模在变，比方几个业务对象的逻辑不简单，几十上百个业务对象就会变得盘根错节。简单来自结构化有余，比方下图所示，结构化的中国结比非结构化的意大利面更有序、易于大脑了解。此外，一旦协同方多了，如何协同不同团队实现软件交付也是一种简单。 2. 什么是领域建模？畛域模型跟技术毫无关系，而是为了更有结构化的拆解和表白业务逻辑。业务逻辑来自事实世界里的具体场景，波及可视画面、操作动作和流程。要精确表白业务逻辑须要先讲清楚每个概念是什么，再建设概念之间的分割，基于这些关系再组合出更多的流程。概念、分割、流程就是畛域模型。围绕畛域模型去表白业务时也自然而然地把技术实现细节拆散进来了。后续代码实现就是将业务架构映射到零碎架构的过程，当前业务架构调整了能疾速的调整技术架构。 3. DDD中的畛域如何了解？DDD中示意业务逻辑的畛域概念是：实体、值对象、畛域服务、畛域事件。这意味着所有畛域逻辑都应该在这四种对象里，对立称为畛域模型对象，这将极大缩小业务逻辑的蔓延。引入聚合进一步封装实体和值对象，让畛域逻辑更内聚，起到边界爱护的作用。聚合的引入使得业务对象间的关联变少。如何设计聚合见上面实际局部。围绕聚合的操作引入工厂和资源库。工厂负责简单聚合的创立，资源库负责聚合的加载、增加、批改、删除。聚合内的实体状态变更通过畛域事件来推动。引入应用服务，对畛域逻辑编排、封装。供下层接口层调用。一个应用服务就是一次编排，一次编排就是一个用户用例。4. DDD畛域概念具体解释和举例 2.2  DDD如何发展？DDD蕴含策略设计、战术设计、技术实现三个局部。策略设计侧重于高层次、宏观下来划分限界上下文，而战术设计则关注应用建模工具来细化上下文，通过畛域模型来表白业务。技术实现次要通过分层架构来隔离畛域模型代表的业务逻辑和技术细节。一个整体过程大抵包含：宏观划分各畛域 → 畛域内划分限界上下文，定义上下文之间的关系 → 上下文内剖析业务，辨认畛域概念，定义适合的畛域概念 → 通过分层架构实现编码，并验证畛域模型的合理性，必要时从新回到后面步骤重构畛域模型。 1. 策略设计策略设计是团队领导层或业务负责人关怀的，该步骤须要针对产品愿景、业务要解决的问题域，布局外围域、通用域、撑持域，做适合的资源投入。 1. 什么是畛域和限界上下文？畛域代表事实世界的特定问题和解决方案的汇合，比方销售畛域、营销畛域。DDD里的限界上下文（Bouded Context）是对畛域的软件实现，比方线索零碎、商机零碎就是销售畛域内的限界上下文。限界上下文定义了解决方案的显著边界，边界里的每一个畛域概念，包含畛域概念内的属性和行为都有非凡含意。出了限界上下文这个边界这层含意就不复存在。 2. 如何划分限界上下文？1：依据相关性做归类。个别是优先思考性能相关性而不是语义相关性，比方创立订单和领取订单都是订单语义，但性能相差比拟大，应该划分为两个限界上下文。 2：依据团队粒度做裁剪、依据技术特点做裁剪。一些通用的技术性能应该尽可能归拢到一个限界上下文，比方每个业务限界上下文都有监控，但监控能力应该归拢到监控限界上下文。 3. BC与微服务什么关系？微服务是蕴含高度相干性能的一个开发部署单元，有本人的技术自治性包含技术选型、弹性扩缩容、公布上线频率等，有本人的业务演变自治性。BC是依据畛域逻辑的内聚状况造成的一个整体。一个微服务能够蕴含一个或多个BC，到底蕴含几个？须要依据团队大小、BC复杂度和技术个性来定。 2. 战术设计DDD设计思维里领域建模是最外围的一步，该阶段次要指标是提炼和定义出畛域模型和之间的关系。 1. 领域建模建模就是设计的过程，建模的过程就是梳理、走查业务逻辑，拆解为要解决的问题和波及的业务场景、业务流程、业务概念，在这个过程中造成对应的畛域概念。 如果团队对于业务比拟生疏适宜采纳事件风暴办法进行梳理；如果团队对业务比拟相熟，如果业务流程绝对简略，则能够采纳四色建模法进行业务梳理。采纳这些剖析业务的办法能够保障产研团队对业务逻辑的了解在一个程度上。 2. 业务逻辑的显性表白在实现了实体和值对象的设计后，有的时候会发现有些概念其实在畛域上是存在的，但设计和代码里没有Class来体现，可能仅仅是一个根本类型参数加上散落的对该参数的判断测验逻辑，这个时候还须要思考应该把这个概念显性化，定义专门的Class并蕴含相应逻辑，入出参以相应Class为类型。凡是业务代码逻辑蕴含了一堆if-else，这时候须要思考尽可能给这段逻辑建模成一个畛域概念。 比方CRM零碎里判断一条线索是否为推广线索须要看线索的渠道属性是否来自推广平台，那么比拟好的形式是这段逻辑用"推广线索"这个概念来显性表白，而不是吞没在代码里不容易了解和保护。 3. 对立语言为了解决业务逻辑连接的问题引入了对立语言。每个业务名词的含意具备明确的定义，产品和研发都统一认识。没有对立语言的沟通重大不足效率。比方CRM线索的概念，没有对立语言的时候每个人的了解不一样，有的人了解为有过征询记录的访客是线索，有的人了解为留下过联系方式的访客是线索，有的人了解为有购买志愿的访客是线索等等。 有了对立语言形容，每个概念就有了明确定义，能够节俭十分大的沟通交流老本。并且这个概念也同样利用在相干的需要文档、设计文档、代码编写中。每个概念从引入到日常交换，从需要文档到代码实现都有了统一的表白，代码实现和需要形容的真实度高，可了解性和可维护性就变好了。 3. 技术实现1. 分层架构为了让代码实现围绕畛域模型发展，尽量升高业务代码和纯技术选型代码的耦合，DDD引入了分层架构。确保了最外围的畛域层不依赖其余层，反过来让畛域之外的代码依赖畛域代码，升高了技术升级带来的影响。 2. DDD框架框架内定义不同畛域概念须要实现的接口，比方实现了聚合根接口的实体类就成为了聚合的根实体。定义了异样治理标准，不同的分层应该抛出什么类型的异样。定义了数据拜访的资源库接口等等。 3. 畛域事件畛域事件是对畛域内产生的流动进行的建模，即聚合内的实体状态变动的一个载体。DDD提倡限界上下文间尽量解耦，尽可能应用公布订阅畛域事件的合作模式进行上下游解耦。 2.3  DDD vs 数据模型驱动传统的业务开发模式里，研发受到关系型数据库设计范式、ER图等影响深远，在做软件具体设计过程中往往先想到如何设计对应的表构造，由此倒推出业务逻辑代码该如何组织。这就是典型的数据模型驱动设计，或者叫面向数据表设计编程。数据模型设计关注的是数据存储，数据尽量不要冗余，管制表数量不收缩，更多思考数据的扩展性，比方新加一个字段尽量不要在几张表都加，能用一个字段表白就不必两个字段。 这样的思维跟DDD是相同的，DDD优先思考畛域概念的业务语义表白，具备独立业务概念的货色会尽量形象成一个内聚的畛域对象。畛域对象不仅仅有属性，还有该有的行为。 因而，基于数据模型驱动的设计后果往往是： 1. 业务逻辑代码十分过程式，畛域实体只蕴含一堆属性，只是数据表的映射，没有业务行为。也就是常说的只有getter和setter办法的贫血对象。十分不足畛域概念的表白，业务逻辑散乱。比方值对象的设计在DDD里是一个类，在数据模型设计里往往是其余类的几个属性。 2. 聚合是DDD最小的复用单元，粒度更粗。数据模型设计里畛域实体的数量跟表数量一一对应，数据表是最小的复用单元，粒度太细。导致业务逻辑对应的实现类须要拜访很多的畛域实体，实现类之间的调用关系发散而盘根错节。下图是贫血模型和DDD富血模型的区别。 ...

一、导读因为向麻利转型，软件架构图的应用规模曾经大幅缩减。即便有在应用软件架构图，它们往往也混淆不清。C4 模型由一系列分层的软件架构图组成，这些架构图用于形容上下文、容器、组件和代码。C4 图的层次结构提供了不同的形象级别，每种形象级别都与不同的受众无关。为了避免出现含糊不清的状况，能够在图中蕴含足够数量的文本和要害的图例。二、C4概念软件架构图是一种十分好的表达方式，能够用它们来表白你将如何构建一个软件系统（事后设计）或者现有的软件系统是如何工作的（回顾文档、常识分享和学习）。 然而，你所看到的大多数软件架构图很可能只是由凌乱的框和线组成。麻利软件开发宣言的一个副作用就是让很多团队进行或缩减了他们的图表和文档工作，包含应用UML。 当初，这些团队偏向于依附他们在白板上绘制的长期图表，或者应用通用的图表工具（如微软的Visio）。Ionut Balosin 在去年写了一篇叫作“软件架构图的艺术”的文章，他在文章中形容了一些常见问题，这些问题与不可了解的符号和不明确的语义无关。 含糊不清的软件架构图容易导致误会，这可能会拖慢一个优良团队的后退步调。在咱们的行业中，咱们真的应该致力创立出更好的软件架构图。多年来，我本人参加软件开发，并与世界各地的团队单干，基于这些教训，我建设了一个称之为“C4 模型”的货色。C4 代表上下文（Context）、容器（Container）、组件（Component）和代码（Code）——一系列分层的图表，能够用这些图表来形容不同缩放级别的软件架构，每种图表都实用于不同的受众。能够将其视为代码的谷歌地图。 要为你的代码创立地图，首先须要一组通用的形象来创立一种无处不在的语言，用来形容软件系统的动态构造。C4 模型应用容器（应用程序、数据存储、微服务等）、组件和代码来形容一个软件系统的动态构造。它还思考到应用软件系统的人。 第1 层：零碎上下文第1 层是零碎上下文图，它显示了你正在构建的软件系统，以及零碎与用户及其他软件系统之间的关系。以下是一个零碎上下文图的示例，形容了一个互联网银行零碎的零碎上下文： 银行的集体客户应用互联网银行零碎查看无关银行账户的信息并进行领取。互联网银行零碎应用银行现有的大型机银行零碎来执行此操作，并应用银行现有的电子邮件系统向客户发送电子邮件。图中的色彩示意哪些软件系统曾经存在（灰色）以及待构建的零碎（蓝色）。 第2 层：容器第2 层是一个容器图，将软件系统放大，显示组成该软件系统的容器（应用程序、数据存储、微服务等）。技术决策也是该图的要害局部。以下是互联网银行零碎的容器图示例。它显示了互联网银行零碎（虚线框）由五个容器组成：服务器端Web 应用程序、客户端单页面应用程序、挪动应用程序、服务器端API 应用程序和数据库。 Web 应用程序是一个 Java/Spring MVC Web 应用程序，它仅提供动态内容（HTML、CSS 和 JavaScript），包含组成单页应用程序的内容。单页面应用程序是一个运行在客户网络浏览器中的 Angular 应用程序，提供所有的网上银行性能。或者，客户能够应用跨平台 Xamarin 挪动应用程序拜访互联网银行的局部性能。单页应用程序和挪动应用程序都调用 JSON/HTTPS API，这是由服务器端运行的另一个 Java/Spring MVC 应用程序提供的。API 应用程序从数据库中获取用户信息（关系数据库模式）。API 应用程序还应用专有的 XML/HTTPS 接口与现有的大型机银行零碎进行通信，以获取无关银行账户或交易的信息。如果须要向客户发送电子邮件，API 应用程序还会调用现有的电子邮件系统。 第 3 层：组件第 3 层是组件图，将单个容器放大，以显示其中的组件。这些组件映射到代码库中的实在形象（例如一组代码）。上面是一个虚构的网上银行零碎的组件图示例，显示了 API 应用程序中的一些组件（而不是全副）。 两个Spring MVC REST 控制器为JSON/HTTPS API 提供拜访点，每个控制器随后应用其余组件拜访数据库和大型机银行零碎中的数据。 第4 层：代码最初，如果你的确想要，或者说有这个必要，能够放大个别组件，以显示该组件的实现形式。以下是一个虚构的网上银行零碎的UML 类图示例（局部），显示了组成MainframeBankingSystemFacade 组件的代码元素（接口和类）。 它表明该组件由很多类组成，实现细节间接反映了代码。我并不倡议创立在这种具体水平的图表，有时候你能够间接从大多数IDE 中获取它们。 ...