统一语言的坏味道：

dao对于ddd来说是坏味道，因为它是纯技术层面数据访问内容。使用它，说明程序员放弃了对于业务逻辑领域归属的考量——不应该让业务去找技术归属。repository比dao好一些，它应该存在于聚合根上，如果确实考虑了业务对于数据的操作的封装，它就是好的。如果仍然对于数据库对象各产生一个操作对象，还是仅仅对dao一个重命名，没有意义。

业务的数据逻辑可以拆分为对象的逻辑和集合的逻辑，引入集合逻辑对象，有助于明确业务逻辑，减少坏味道。

低代码是行业毒瘤：

形式逻辑和历史事实证明，让不懂代码的人写代码的想法是错的。图灵邱奇定律：没有一个模型可以跨越另一个模型提供额外的能力。图灵完备意味着提供完整能力，非程序员无法跨越编程知识而掌握，非图灵完备意味着功能缺失。非程序员不能借助一种新语言跨越编码细节，实现程序编写。最终还是会落在程序员头上。

测试金字塔和测试策略：

系统需要两类测试：发现问题的测试和定位问题的测试。功能测试覆盖代码量大，主要用于发现问题，单元测试、组件测试和集成测试覆盖代码量小，用于定位问题。单元测试本身一般已经不能验证功能是否正确，需要构造等效测试，把功能测试等效为一系列单元测试，使得它能帮你定位问题。所以测试金字塔只是一种实现策略的结论，本质上，你要思考你的测试策略能不能帮你达到上述目的，怎样帮你达到目的，怎么实现效率最高，来具体设计测试策略。

六边形架构还值得选择么：

六边形架构核心价值是通过适配器桥接，定义边界输入输出，把业务和技术的内容分离，来保持技术架构改变时，业务可以不变。但实际上需求变化比技术架构变化要快的多。六边形架构本身是基于单体架构假设的一种设计，当时认为是变化，需要隔离的部分，今天已经不再是变化的了。考虑架构时，应当先从部署结构和物理形态考虑：今天的部署和当时非常不同，所以六边形架构基于过时设计，不能适应今天的情况。只有从最基本的原理思考，怎样隔离和适应变化，才是有效的架构设计的思路。

面向对象仍然是默认的选项么：

面向对象的前提是数据完备于内存中，这种情况下，把数据模型和数据处理的逻辑放在一起是合适的实现。后来出现数据库之后，数据不再是完备的，完整的面向对象就不存在，自然而然的出现贫血模型。seviceless的架构完全把逻辑和数据剥离，而hadoop则倒置为代码迁移给数据源去执行。这些新兴事物提示我们，面向对象不应该被看作一种默认的实现。从restful接口外部看，无论是否是面向对象的设计，都是无关的。

TDD和瀑布没什么区别：

瀑布需要完备的文档，在纸面预演开发过程，完备的思考和解决可能遇到的问题。TDD将需求拆分成任务，每个任务大约15min左右，都是用测试用例表达的。在这一过程中澄清需求和发现技术能力缺失，去尝试补充能力。殊途同归，都是软件开发的良好实践。

好的showcase：

好的showcase就是没有惊喜，也没有意外的。你可以先通过与showcase各方私下沟通，趟平问题。可能有人挑战，但要保证基本盘。最好的是让一部分业务方回答其他业务方的问题。showcase在敏捷中非常重要，没有通过的情况客户可以不付钱。showcase可以弥补客户对敏捷项目的当前状态把握的缺失。showcase不需要开发人员发光，可以把舞台给客户和领导，让他们多表现。

为什么说《领域驱动设计》已经过时了：

领域驱动设计通过领域建模解决业务复杂度问题。根本复杂度来自业务，进一步看，来自运维模式和业务模式变化的时候，it如何去跟随。而领域驱动设计没有这方面内容，它没有对变化点建模和描述的内容。对于一个企业来说，用户渠道变化最快，运维模式次之，业务模式最次。在不同的速率上，系统稳定的程度不同，适用于ddd的程度就不同。对于相对稳定的系统，ddd的建模是有效的，对于变化速率高的部分，ddd建模会额外的增加成本和复杂程度，而它本身在付出高成本后旋即被抛弃，适用ddd的策略会十分荒唐。

中台三问：

中台与平台不同在于，平台是对业务流程的封装，抽象的是个别能力和技术能力。中台试图抽象业务模式或业务流程，在不同前台需求中抽象公共服务模块，避免成为大后台。它需要开发者思考和抽象企业依靠什么做业务，什么样的业务在驱动各个模块运转。

1.如何避免中台成为一个单点，以至于中台瘫痪导致系统瘫痪

中台没有必要按单点部署，也不需要所有前台访问相同实例。完全可以是相同的逻辑，分离的部署。复用的只是抽象的能力。

2.中台实现前台的定制需求与中台实现通用需求的矛盾如何解决

中台开发者思维的出发点是我是什么，而非你是什么，你有什么需求需要我满足。观察前台业务的目的是给自己找到主体性。

3.中台在企业结构中，会给it与业务的合作带来怎样的冲击和影响

康威定律：线型系统和线型组织架构间有潜在的异质同态特性。成立服务中台的组织架构会带来中台和前台的张力，但这不是问题，会帮助中台服务找到边界，达到平衡。

微服务拆分粒度：

对于单体应用，业务高峰到来时，各个业务部分有不同的弹性需要，单体的扩展不能支持这一点。以部署需要为微服务边界拆分，符合微服务设计的最初目的。微服务架构是在云原生时代，把弹性放在核心地位的架构。有时也基于发布周期解耦的考量，会拆分微服务。

对于通常被认为的微服务能提供服务重用功能来说，实际上不存在计算的重用的瓶颈，往往带有数据和逻辑的内容是需要重用的。所以无服务并不是微服务的趋势，它们是不同的。复用是一个潜在的收益，而非明确的收益，不应该以复用作为拆分微服务的原因。

基于细胞特化的架构思想，也可以制造相同的单体部署，通过其所处位置的不同，发挥不同的功能，并且通过定制网关解决弹性的问题。这样做方便功能的延续和复用，解决一部分cap和代码架构层面遇到的困难。也侧面说明了，微服务不是越微越好。

领域逻辑与运维逻辑：

业务逻辑分为领域逻辑和运维逻辑，领域逻辑是通用的，与具体公司的运作无关的，与所处行业地区等有关。企业谈业务需求一般没有领域概念，而是提软件的运维逻辑。所以市场上软件定制也有两个思路，一个是要求企业适应软件的运维逻辑，做对应组织调整；一个是软件存在通用功能，定制运维逻辑，也会要求企业适应，但程度会低。今天的环境下，无法抛开运维逻辑谈领域逻辑，设计软件的时候要多做相关思考。

DDD遇到业务系统，还是最佳实践么：

领域的复杂度和业务的复杂度不是同一维度的问题，DDD提出时，系统多是在领域的维度复杂，目前的多数系统主要复杂度在业务方面。对业务的抽象会体现在中台，而不是领域中。所以当遇到业务复杂度高的系统，不应当首选DDD，直接开发会更好。

*内容来自对八叉说栏目内容的笔记