journey

旅程1：我们的领域：Contoso会议管理系统 起点:我们从哪里来，我们带来了什么，谁将与我们同行?“ 只要前进，我愿意去任何地方。” --大卫•利文斯通 本章介绍了一个虚构的公司Contoso。它描述了Contoso计划推出的会议管理系统，这是一个新的在线服务，可以使其他公司或个人通过此系统组织和管理自己的会议和活动。本章从高层次描述了新系统的一些功能和非功能需求，以及为什么Contoso希望使用CQRS和Event Sourcing实现部分功能。与任何考虑此过程的公司一样，有许多问题需要思考和挑战，特别是这是Contoso第一次同时使用CQRS和Event Sourcing。接下来的章节将逐步展示Contoso是如何设计和构建其会议管理系统的。 另外，本章还介绍了一个虚构的专家小组来评论开发工作。 Contoso公司 Contoso是一家新兴的ISV公司，拥有大约20名员工，专门使用微软技术开发解决方案。Contoso的开发人员熟悉各种微软产品和技术，包括.Net Framework、ASP.NET MVC和Microsoft Azure。一些开发人员以前有使用领域驱动设计(DDD)方法的经验，但是他们以前都没有使用过CQRS模式。 会议管理系统应用程序是Contoso想要推向市场的首批创新在线服务之一。作为一家初创企业

最近在工作中碰到了 GC 的问题：项目中大量重复地创建许多对象，造成 GC 的工作量巨大，CPU 频繁掉底。准备使用 sync.Pool 来缓存对象，减轻 GC 的消耗。为了用起来更顺畅，我特地研究了一番，形成此文。本文从使用到源码解析，循序渐进，一一道来。 本文基于 Go 1.14 目录 是什么 有什么用 怎么用 简单的例子 fmt 包如何用 pool_test 其他 源码分析 Pool 结构体 Get pin popHead getSlow popTail Put pushHead pack/unpack GC 总结 参考资料 是什么 sync.Pool 是 sync 包下的一个组件，可以作为保存临时取还对象的一个“池子”。个人觉得它的名字有一定的误导性，因为 Pool 里装的对象可以被无通知地被回收，可能 sync.Cache 是一个更合适的名字。 有什么用 对于很多需要重复分配、回收内存的地方， sync.Pool 是一个很好的选择。频繁地分配、回收内存会给 GC 带来一定的负担，严重的时候会引起 CPU 的毛刺，而 sync.Pool 可以将暂时不用的对象缓存起来，待下次需要的时候直接使用，不用再次经过内存分配，复用对象的内存，减轻 GC 的压力，提升系统的性能。 怎么用 首先， sync.Pool 是协程安全的，这对于使用者来说是极其方便的。使用前，设置好对象的 New

旅程2：分解领域 设计停靠站点 “没有石头就没有拱门” --马可波罗 在本章中，我们将对Contoso会议管理系统进行一个高层次的概述。这将帮助您理解应用程序的结构、集成点以及应用程序的各个部分之间的关系。 在这里，我们借用Eric Evans在他的书《领域驱动设计 软件核心复杂性应对之道(Addison-Wesley Professional, 2003)中描述的领域驱动设计(DDD)方法来描述这个高级结构。DDD是成功实现CQRS模式的先决条件虽然还没有达成普遍的共识，但我们团队依然决定按照CQRS社区的惯例使用DDD里众多概念和方法，例如领域、限界上下文,和聚合。参考指南的第1章“上下文中的CQRS”更详细地讨论了DDD和CQRS模式之间的关系。 本章使用的定义 在本章中，我们使用了一些术语，我们将在后面定义它们。有关更多细节和可能的替代定义，请参见参考指南中的第1章“ 上下文中的CQRS ”。 领域(Domain):领域是指Contoso会议管理系统的业务域(参考实现)。第一章“我们的领域：Contoso会议管理系统”概述了这个领域。 限界上下文(Bounded Context):术语限界上下文来自Eric Evans的书。简而言之，Evans引入这个概念是为了将一个大型的、复杂的系统分解成更易于管理的部分。大型系统由多个限界上下文组成

旅程8：后记:经验教训 我们的地图有多好?我们走了多远?我们学到了什么?我们迷路了吗? “这片土地可能对那些愿意冒险的人有益。”亨利.哈德逊 这一章总结了我们旅程中的发现。它强调了我们在这个过程中所学到的最重要的经验教训，提出了如果我们用新知识开始这段旅程，我们将以不同的方式做的一些事情，并指出了Contoso会议管理系统的一些未来道路。 你应该记住，这个总结反映的是我们的具体旅程，并非所有这些发现都适用于你自己的CQRS旅行。例如，我们的目标之一是探索如何在部署到Microsoft Azure并在利用云的可伸缩性和可靠性的应用程序中实现CQRS模式。对于我们的项目，这意味着使用消息传递来支持多个角色类型和实例之间的通信。您的项目可能不需要多个角色实例，或者没有部署到云中，因此可能不需要如此广泛地(或者根本不需要)使用消息传递。 我们希望这些发现能够被证明是有用的，特别是当您刚刚开始使用CQRS和事件源时。 我们学到了什么 本节描述了我们学到的主要经验教训。它们没有以任何特定的顺序呈现。 性能问题 在我们的旅程开始时，我们对CQRS模式的一个概念是，通过分离应用程序的读和写方面，我们可以优化每个方面的性能。CQRS社区的许多人都认同这一观点，例如: “CQRS告诉我，我可以分别优化读和写，而且我不必总是手动的反规范化到平面表中。” Kelly Sommers - CQRS顾问

C++智能指针 来源 https://zhuanlan.zhihu.com/p/30933682 参考 https://www.zhihu.com/question/319277442/answer/1094961099 ======================== 智能指针只能代替 T* 的一部分功能，而这部分本来就不适合用 T* （因为容易造成bug）。 如果本身就没有所有权，Bjarne（ P1408 ）的建议是直接用 T* 。 ======================== 智能指针表示的是某个资源的“ 所有权 ”的概念， unique_ptr表示唯一的所有权； shared_ptr表示可共享的所有权； weak_ptr表示可共享的未来的所有权。 然而资源拥有者如果只是要把一个对象借给别人用一下，用完就归还呢？ void borrow_sth(??? resource); 有两种选择： T* 和 const std::unique_ptr<T>& 我更喜欢用第一种 ======================== 嗯，大家都在说普通指针和智能指针，少说了一个“引用” 先考虑用引用和值，减少90%的指针，特别是函数之间，基本上没有必要传指针。 再考虑使用unique_ptr，替换类的成员不能用引用的情况下使用指针。 最后考虑使用share_ptr/weak_ptr

【推荐阅读】微服务还能火多久？>>> A Knight’s Journey Time Limit: 1000MS Memory Limit: 65536K Total Submissions: 58714 Accepted: 19998 Description Background The knight is getting bored of seeing the same black and white squares again and again and has decided to make a journey around the world. Whenever a knight moves, it is two squares in one direction and one square perpendicular to this. The world of a knight is the chessboard he is living on. Our knight lives on a chessboard that has a smaller area than a regular 8 * 8 board, but it is still rectangular. Can you help this adventurous knight to make

链接： https://codeforces.ml/contest/1321/problem/B Tanya wants to go on a journey across the cities of Berland. There are nn cities situated along the main railroad line of Berland, and these cities are numbered from 11 to nn. Tanya plans her journey as follows. First of all, she will choose some city c1c1 to start her journey. She will visit it, and after that go to some other city c2>c1c2>c1, then to some other city c3>c2c3>c2, and so on, until she chooses to end her journey in some city ck>ck−1ck>ck−1. So, the sequence of visited cities [c1,c2,…,ck][c1,c2,…,ck] should be strictly increasing.

There are n cities and n - 1 roads in the Seven Kingdoms, each road connects two cities and we can reach any city from any other by the roads. Theon and Yara Greyjoy are on a horse in the first city, they are starting traveling through the roads. But the weather is foggy, so they can’t see where the horse brings them. When the horse reaches a city (including the first one), it goes to one of the cities connected to the current city. But it is a strange horse, it only goes to cities in which they weren't before. In each such city, the horse goes with equal probabilities and it stops when there

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 一、前后端分离痛点剖析 1、你有没有遇到过： · 前端代码刚写完，后端的接口又变了。 · 接口文档永远都是不对的。 · 测试工作永远只能临近上线才能开始。 2、为什么前后端分离了，你比从前更痛苦？ 前后端分离早已经不是新闻，当真正分离之后确遇到了更多问题。要想解决现在的痛，就要知道痛的原因： ①为什么接口会频繁变动？ · 设计之初没有想好。 这需要提高需求的理解能力和接口设计能力。 · 变动的成本较低。德国有句谚语：“朝汤里吐口水。” 只有这样，才能让人们放弃那碗汤，停止不合理的行为。 前后端同学坐在一起工作的时候效率会有提升，当后端同学接口变化时，只需要口头上通知一下即可，我们没有文档，我们很敏捷啊。 没错，我们需要承认这样配合开发的效率会很高，但是频繁的变动会导致不断返工，造成了另一种浪费，这种浪费是可以被减少，甚至是被消除的。 ②为什么接口文档永远都是不对的？ 接口文档在定接口时起到一定作用，写完接口就没有用了。后面接口的频繁变化，文档必定会永远落后于实际接口，维护文档的带来了一定的成本却没能带来价值。除非对外提供的接口，否则文档谁来看呢？没人看，用处又在哪？ 有些公司干脆丢掉接口文档，说我们要拥抱敏捷。所以接口文档落后的原因在于没有给我们带来价值。 ③为什么测试工作永远只能临近上线才能开始？ 一个需求