architect

https://www.bilibili.com/video/BV1Tm4y1Z7iH?p=36&spm_id_from=pageDriver

聚合: 聚合往往是一些实体为了某项业务而聚类在一起形成的集合 ， 举个例子， 社会是由一个个的个体组成的，象征着我们每一个人。随着社会的发展，慢慢出现了社团、机构、部门等组织，我们开始从个人变成了组织的一员，大家可以协同一致的工作，朝着一个最大的目标前进，发挥出更大的力量。领域模型内的实体和值对象就好比个体，而能让实体和值对象协同工作的组织就是聚合，它用来确保这些领域对象在实现共同的业务逻辑时，能保证数据的一致性。可以这么理解，聚合就是由业务和逻辑紧密关联的实体和值对象组合而成的，聚合是数据修改和持久化的基本单元，每一个聚合对应一个仓储，实现数据的持久化。

DDD 全程是 Domain-Driven Design，中文叫领域驱动设计，是一套应对复杂软件系统分析和设计的面向对象建模方法论。

https://zq99299.github.io/note-architect/hc/07/01.html#%E6%94%AF%E6%92%91%E9%AB%98%E5%B9%B6%E5%8F%91%E7%9A%84%E8%AE%A1%E6%95%B0%E7%B3%BB%E7%BB%9F%E8%A6%81%E5%A6%82%E4%BD%95%E8%AE%BE%E8%AE%A1

ntity（实体）这个词在计算机领域的最初应用可能是来自于Peter Chen在1976年的“The Entity-Relationship Model - Toward a Unified View of Data”（ER模型），用来描述实体之间的关系，而ER模型后来逐渐的演变成为一个数据模型，在关系型数据库中代表了数据的储存方式。而2006年的JPA标准，通过@Entity等注解，以及Hibernate等ORM框架的实现，让很多Java开发对Entity的理解停留在了数据映射层面，忽略了Entity实体的本身行为，造成今天很多的模型仅包含了实体的数据和属性，而所有的业务逻辑都被分散在多个服务、Controller、Utils工具类中，这个就是Martin Fowler所说的的Anemic Domain Model（贫血领域模型）。 https://developer.aliyun.com/article/758292

四色建模法包括

项目的目录结构 分为 application，domain，facade，infrastructure 四个部分

微软 AzureCAT 模式和实践团队在 Azure 架构中心发布了 9 个新的微服务设计模式

微服务思想以及相关的技术为 IT 架构的发展带来了一系列深刻的变革：

https://docs.aws.amazon.com/zh_cn/IAM/latest/UserGuide/id_credentials_mfa_enable_virtual.html

1，首先，解决一下当网络不好时，用户多次点击提交造成的多订单问题，可以在秒杀表中对用户id和商品id和本次活动的code进行一个唯一索引约束，可以避免多插入。

https://www.tingyun.com/ https://www.tingyun.com/tingyun_network.html https://demo.tingyun.com/server/overview/application https://www.tingyun.com/lp.html

通过业务管理域与运行域分离、业务与业务的隔离架构，大幅度提高了业务在可扩展性、研发效率以及可维护性问题，同时以更好的开放模式，让业务方能自助进行无侵入的需求开发。 业务可视化：平台能力、业务规则决定是否对外透出； 需求结构化支持：基于透出的业务能力、已有的业务规则完成需求结构化分解降低沟通成本； 业务配置化：这是可视化的前提，要在需求明确的情况下在线配置业务、快速发布上线； 业务测试一体化：根据修改的代码进行自动化用例筛选、自动化测试； 业务监控：以精细化的业务维度进行监控，而不仅仅局限于交易大盘； 故障排查：当业务故障时快速拿到故障快照、还原故障现场以及迅速定位问题原因。

什么是DDD？ 以下是考虑使用DDD的原因：

高可用性指的是系统如何保证比较高的服务可用率，在出现故障时如何应对，包括及时发现、故障转移、尽快从故障中恢复等等

RD自助DDL操作，其实这种操作开放给RD自助执行是非常危险的，即便是DBA在做大表操DDL的时候，都经常会出现一些状况，比如造成锁等待，连接打满，主从延迟等。

事件驱动架构（Event Driven Architecture，EDA）一个事件驱动框架（EDA）定义了一个设计和实现一个应用系统的方法学，在这个系统里事件可传输于松散耦合的组件和服务之间。一个事件驱动系统典型地由事件消费者和事件产生者组成。事件消费者向事件管理器订阅事件，事件产生者向事件管理器发布事件。当事件管理器从事件产生者那接收到一个事件时，事件管理把这个事件转送给相应的事件消费者。如果这个事件消费者是不可用的，事件管理者将保留这个事件，一段间隔之后再次转送该事件消费者。这种事件传送方法在基于消息的系统里就是:储存（store）和转送（forward） 构建一个包含事件驱动构架的应用程序和系统，会使这些应用程序和系统响应更灵敏，因为事件驱动的系统更适合应用在不可预知的和异步的环境里。 事件驱动架构在具体实现中是指由一系列相关组件构成的应用，而组件之间通过事件机制完成一定的业务功能。由于在一个EDA系统中各个组件都只专注于处理输入的消息与发布输出的消息，因而EDA系统能够更有加效地对管道化（pipelined）的、由多软件模块链接而成的并发事件流（concurrent processing of events）进行处理。 EDA系统中各组件以异步方式响应事件，在本质上是可以并行的，因而在政府部门的电子政务应用中具有极大的优势。其具备以下特点: ◆ 并发执行 ◆ 事件触发/数据触发/时间规则触发 ◆ 实时/增量响应 ◆ 分布式事件系统处理 事件驱动架构优势编辑 事件驱动设计和开发所提供的优势如下所示: ◆ EDA提高了对不断变化的业务需求的响应，最大限度地减少了对现有业务应用的影响，也常消除了对新打包应用的需要。如果采用特有的粗颗粒服务模型可以基于业务目标快速确定可控的业务变更，并直接、迅速、有效地实施变更以达到业务敏捷性和完整性。 ◆ 可以更容易开发和维护大规模分布式应用程序和不可预知的服务或异步服务; ◆ 可以很容易，低成本地集成、再集成、再配置新的和已存在的应用程序和服务。 ◆ 促进远程组件和服务的再使用，拥有一个更灵敏、没有Bug的开发环境。 从时间维度来看EDA的优势: ◆ 短期利益:更容易定制，因为设计对动态处理有更好的响应; ◆ 长期利益:系统和组织的状态变得更精准，对实时变化的响应接近于同步。

Spring Data之@DomainEvents注解 背景 在对一个Entity进行save操作时，往往需要触发后续的业务流程，通常采用如下做法

在设计后台时时常会查阅后台的相关资料，但是关于后台的文章等内容分享的太少了，正好这一段时间在调整，想尝试撰写一系列的关于后台文章，希望跟大家一起来探讨、分享，希望对大家有所裨益，由于不同的后台需求多样化，不能一一兼顾，只能蜻蜓点水，尽量深入浅出。

http://www.woshipm.com/operate/1746.html 品类管理在传统行业中并不新鲜，只是在电子商务的领域中很少见而已；

https://github.com/hongyangAndroid/AndroidChangeSkin 我认为目前的换肤主要分成3种，一种是返回图片的地址，APP再根据图片日志去取图片，另一种是下载zip包然后再解压去替换图标，再一种是图片资源放到包里，接口控制是否显示。

Scenario： 有多少网页， 有多长，有多大 Service: Crawler, TaskService, StrorageService Storage: Use db To store task, 用 big table存网页

行业背景 零售行业困局 目标 业务中台的理念 服务如何沉淀 技术体系与建议 业务中台的技术要求 产品体系与建议 全渠道营销解决方案 泛电商解决方案 客户管理系统解决方案 行业背景 政策因素：包括供给侧改革，合理调整产能，增加有效和中高端供给。中国制造2025，信息技术与制造技术相结合，推动生产管理和营销模式变革。“十三五”规划纲要，加快建设数字中国。

https://mp.weixin.qq.com/s/mHHPaYEvon4zFHHDNP8A9A 微服务架构已经成为现代应用程序开发的主流。虽然说它能够解决某些问题，但却也不是万金油。而我们在使用这个体系架构时，还有许多的问题要我们解决。这就需要学习这些问题的通用模式，并通过可复用的解决方案来解决问题。因此，有必要讨论微服务的设计模式。但是在深入研究设计模式之前，我们还需了解微服务架构的构建原理：

什么是业务

GTS 今年双 11 的成绩 今年 2684 亿的背后，有一个默默支撑，低调到几乎被遗忘的中间件云产品——GTS（全局事务服务，Global Transaction Service），稳稳地通过了自 2014 年诞生以来的第 5 次“大考”。

什么是微服务

https://www.jdon.com/dci.html DCI是对象的Data数据, 对象使用的Context场景, 对象的Interaction交互行为三者简称， DCI是一种特别关注行为的模式(可以对应GoF行为模式)，而MVC模式是一种结构性模式，DCI可以使用演员场景表演来解释，某个实体在某个场景中扮演包公，实施包公升堂行为；典型事例是银行帐户转帐，转帐这个行为按照DDD很难划分到帐号对象中，它是跨两个帐号实例之间的行为，我们可以看成是帐号这个实体(PPT，见四色原型)在转帐这个场景，实施了钞票划转行为，这种新的角度更加贴近需求和自然，结合四色原型 DDD和DCI可以一步到位将需求更快地分解落实为可运行的代码，是国际上软件领域的一场革命。 DDD DCI和领域事件 DDD是领域驱动设计(Domain-Driven Design )的简称，DDD是一种分析设计建模方法，它倡导统一语言，提出了实体和值对象 以及聚合根等概念，借助DDD我们能够在结构理清需求中领域模型。DDD专题。

官方解释下就是：反向代理的场景，upstream后端用域名时，配置resolver以便于nginx能够解析该域名

达达商城和众包任务是公司的两个变现业务，商城是做定位蓝领的电商，众包则是做除了物流之外的众包模式的尝试。 两个项目在开发上共同的难点都是系统如何应对灵活多变的业务形式，来支持新模式的落地。 对此我们设计了一套插件系统，很好的处理了系统的复杂性，让开发变的轻松简单。 起因和思路：

https://blog.csdn.net/Ture010Love/article/details/104340379/ 业务架构有三化——配置化、产品化、自动化，配置化解决业务系统灵活性、动态可变的问题，产品化解决工具复用提效的问题，自动化让机器工作、解决人力成本问题。本文来自百度刘志伟、韩炳涛两位同学对百万行配置化经验的分享，具备有一定总结的抽象性 背景 互联网软件市场是一个快速变化的市场，优秀的服务层出不穷，所以互联网软件公司需要快速推出服务抢占市场、并且能够快速响应用户的需求，否则就面临被淘汰的命运。这跟达尔文主义的观点是一致的：

1.1 什么是组件化?

1. 四色原型 1.1. 时刻-时段原型（Moment-Interval Archetype） 表示事物在某个时刻或某一段时间内发生的。

面向对象分析与设计，即Object Oriented Analysis and Design（OOA\D） 领域驱动设计，即Domain Driven Design（DDD） 四色原型：MI原型、Role原型、PPT原型、Description原型 DCI架构：Data Context Interaction CQRS架构： 命令查询职责分离原则，即Command Query Responsibility Segregation

1. 碰到一个业务系统，我们该如何分析业务，分析需求，并最后得到一个只包含业务概念的模型？答案是通过四色原型进行业务建模。四色原型的中心思想是：一个什么什么样的人或组织或物品或地点以某种角色在某个时刻或某段时间内参与某个活动。 其中“什么什么样的”就是DESC，“人或组织或物品或地点”就是PPT，“角色”就是Role，而”某个时刻或某段时间内的某个活动”就是MI。 2.业务模型建好了，该如何通过面向对象的分析与设计方法来进行对象建模呢？ DDD和DCI思想可以帮助我们。首先，DDD能够指导我们建立一个静态的领域模型，该领域模型能够清楚的告诉我们建立出来的对象“是什么”，但是DDD却不能很自然的解决“做什么”的问题。大家都知道DDD在对象设计的部分实际上是一种充血模型的方式，它强调对象不仅有属性还会有行为，如果行为是跨多个领域对象的，则在DDD中用领域服务解决。但是DDD却没有完整的考虑对象与对象之间的交互如何完成，虽然它通过领域服务的方式协调多个对象之间进行交互或者在应用层协调多个对象进行交互。但是在DDD中，对象往往会拥有很多不该拥有的属性或行为。在我学习了DCI架构之后，我认识到了DDD的很多不足。

DDD

首先谈到Uber的初心，他们想实现一键打车功能。左边是Uber最早期的界面，大家可以看到跟现在有很大的区别，按一下就可以打到车了。

https://zhuanlan.zhihu.com/p/48208940 大家都知道，要增强自己的职场影响力，和你所参与的项目，以及你在项目中扮演的角色是有非常大的关系的。每个人都在积累自己硬实力的同时，也都希望能够抓住机会去主导一个项目，让它从0到1产生更大的Impact。 今天，Project Leader @ Uber，短短两年间主导了两三个产生千万级影响的项目的嘉宾陈新茜将为大家分享：如何在一家科技公司里主导一个能产生千万级影响力的项目。

我们首先实现一个类似于PayPal、Venmo、支付宝类型的支付系统，我们之后再考虑不同领域中的扩展。 让我们从系统设计的基本方法SNAKE原则来切入。

https://github.com/donnemartin/system-design-primer/tree/master/solutions 系统设计的基本方法——SNAKE原则（Scenario,Necessary,Application,Kilobit,Evolve），它是BitTiger创始人冯沁原在准备系统设计相关知识时整理出的一套方法论，非常适合用于系统设计的各个方面，无论宏观还是微观，初期还是晚期。 系统设计有四大要素。第一，是要满足一个需求即Requirements；第二，对内容进行一个定义；第三，从不同维度去考虑宏观的架构层、组件层、模块层；第四，也要考虑到互相间交流的接口和相关传递的数据。所以这些内容一起构成了整个系统设计。

如何设计Twitter是个经典的面试问题，我们要想一想Twitter的本质是什么，它其实是feed流。那什么是feed流呢？有很多list，这些List的集合就是你最终展现的结果，把一些list集合到一块去就是feed流。这个概念跟Kafka其实是非常相似的，Kafka是按照时间排序把很多log流聚合到一块。除了Twitter，还有很多现在火爆的应用主要功能都涉及到了feed流，比如Facebook、微博、微信朋友圈、Google Reader、今日头条。 比如说在Twitter中，我们有三个feed list，这里需要强调，因为在不同公司不同项目叫法不太一致，我们讲的feed是指单独的list，而list的集合叫timeline，所以timeline是feed的聚合，而每个单独的feed就是一个list。比如说上图中第一列是关于Nelson自己的list，第二列是关于Tim自己的list，第三列是QCon的list，每个人自己的feed可以放一起。

如何设计Twitter？此问题同样也可以推广到如何设计Facebook、微博、微信朋友圈等 太阁冯沁原提出的SNAKE原则和九章算法东邪老师提出的4S原则都不能完全体现系统设计的真髓，SNAKE原则缺少了Storage（存储）部分的强调，4S原则缺少对系统参数的计算。在此我想总结两位前辈的经验，提炼出自己对于系统设计原则的理解：4SE原则。

尤其是春节期间，大家不仅使用 12306，还会考虑“智行”和其他的抢票软件，全国上下几亿人在这段时间都在抢票。“12306 服务”承受着这个世界上任何秒杀系统都无法超越的 QPS，上百万的并发再正常不过了！

分布式解决方案有：

全局事务服务（Global Transaction Service ，简称GTS）用于实现分布式环境下特别是微服务架构下的高性能事务一致性。可以与RDS、MySQL、PostgreSQL、DRDS等数据源，Spring Cloud、Dubbo、EDAS及其他RPC框架，MQ消息队列等中间件产品配合使用，轻松实现分布式数据库事务、多库事务、消息事务、服务链路级事务及各种组合。 https://www.aliyun.com/aliware/txc?spm=a2c4e.11153959.blogcont542020.22.589066baa8wv3r 2 微服务落地存在的问题

2004年Eric Evans 发表Domain-Driven Design –Tackling Complexity in the Heart of Software （领域驱动设计），简称Evans DDD。领域驱动设计分为两个阶段：

在图论的基本理论中，有加权顶点的概念。顶点具有的与之相关的数，称为权（weight）；该顶点称为加权顶点。