PHP,DDD,CQRS,Event Sourcing,Kubernetes,Docker,Golang

CQRS/ES下，许多开发者不了解如何在系统中处理这样的场景：

在用户创建的时候，我们想要去验证用户名在数据库中是否是唯一的。我应该使用Event Store还是使用读数据库查询？我该在哪执行这个查询？

这个问题是StackOverflow上与CQRS话题有关的最受关注的话题。因此在这篇文章中，我们将尝试针对这个问题寻找出最佳解决方案。

经常能看到在一些书本和文章中写到hydration，这一单词单独去翻译为“水合”、“水合作用”等，但放在文章中又似乎读不同，难以理解。

通过查阅了更多的信息之后，hydration的大致意思基本了解了。

可以理解为对象提供水分，为什么对象呢？就是刚实例化的对象。并且我们最常见提到“水合”的地方就是刚从数据库或其他存储介质中取出数据填充到对象上。

那么这种一个已经在内存中实例化的对象，还没有包含任何数据，然后用数据（例如从数据库、网络、文件系统等获取的）填充到该对象内，这种行为成为hydration水合。

常见的一种水合方式就是序列化和反序列化了，如在PHP中对对象进行serialize和unserialize，此时的反序列化==实例化+水合。

将类的继承层次表示为单张数据表，这张表内含有每个类的所有字段

关系数据库不支持继承，当对象映射到数据库时，我们必须考虑如何在关系数据表中良好的展示我们的对象继承结构。当对象映射到关系数据库时，在多张表中处理继承结构过程中，我们尝试着去尽量减少迅速增加的join查询。（参考类表查询）。单表继承将所有类的继承结构的所有字段映射到了一张表中。

表示类的继承层次结构，每个类都对应一张数据表

对象关系阻抗不匹配的一个显著方面是由于关系数据库不支持继承。你想要数据库结构能够清晰的映射到对象，并想要在继承结构中可以任意链接。类表继承通过使用一个数据表对应一个类的方式来实现这样的目的。

本篇博文由本博客(http://www.veitor.net)经原文翻译，转载请注明出处。

为了能够构建一个复杂的应用程序，其中一个关键点就是需要有一个适合该程序的架构设计。领域驱动设计的一个优势就是它不受任何架构风格的约束。相反，我们可以自由的去为核心领域内的每一个限界上下文选择最合适的架构，为每一个领域问题提供多种架构选择。

例如，订单处理系统可以使用事件溯源(Event Sourcing)去追踪所有不同订单的操作；一个产品目录系统能够使用CQRS去将产品详情展示给不同客户端；一个内容管理系统能使用六边形架构(Hexagonal Architecture)来展示如博客、静态页等需求。

本章将介绍PHP相关的每种架构风格，从传统PHP代码演变为复杂的架构。请注意虽然还有很多其他现有的架构如Data Fabric和SOA，我们发现他们其中一些从PHP角度来介绍太过于复杂。

本篇博文由本博客(http://www.veitor.net)经原文翻译，转载请注明出处。

有什么大惊小怪的呢？如果你已经阅读了Vaughn Vernon和Eric Evans关于这个话题的书籍，那么你可能对我们即将要谈论的会很熟悉，因为我们大量借鉴了他们书中的定义和解释。 领域驱动设计（DDD）是帮助我们成功理解和构建软件模型设计的一种方法。 它为我们提供了策略(strategic)和战术(tactical)建模工具，以帮助设计符合我们业务目标的高质量软件。

问题重现步骤：
有两个不同域名的页面a.com/a.php和b.com/a.php两个域名，其中b.com/a.php会在其b.com下设置cookie，a.com/a.php页面中通过iframe或script src等方式嵌入b.com/a.php页面。保持b.com下的cookie为空，正常chrome等浏览器访问a.com/a.php时，嵌入的b.com/a.php可以正常对b.com域名下设置cookie，而safari中设置不了。

有些OOP程序员认为对象重用、扩展就等同于使用继承。一个类可以有大量属性和方法，通过继承这个类，我们增加新属性和方法，就能轻松的进行扩展，因为无需再重新编写代码。不过最后对于紧密绑定的对象，一味的使用继承方式来扩展会导致这么一个问题，那就是过度继承。

第一个设计模式原则：按接口而不是按实现来编程。
以最简单的方式来讲就是，要将变量设置为一个抽象类或接口数据类型的实例，而不是一个具体实现的实例。

树大招风，当然网站被恶意攻击注入是常有的事，这也是对一个程序员代码质量以及经验水平的考验。

今天公司一个项目不幸被sql注入了，根据日志查询到了注入点，是某个详情页的代码，大致就是根据某条数据id查询该条数据。