HN评论摘要
1.我的观点是，Martin Folwer的最大贡献确实是文档，并定义了词汇表，以便围绕企业中经常遇到（但可能是普通的）问题进行讨论应用开发。他并没有试图开辟新天地，但我很高兴他的作品存在。
下面是关于失血模型和充血模型的争论，MF是支持充血模型的，
2. 我认识一个人认为Folwer在很多方面都是错的。这个人现在是大公司的架构师（FAANG），之前他做过一些很棒的项目，所以我当然相信他。例如，他认为贫血模型是正确的方法，并且将方法放入数据对象是错误的。不幸的是他还不想写一本书，所以我不能透露任何东西，但我只想强调一个优秀的工程师不应该盲目相信任何东西，即使它似乎是由一个受欢迎的作者写的。我自己，读了他的重构书，这很棒。
3. 我不明白贫血领域模型现在是多么无关紧要，尤其是在许多软件从业者似乎都在进入领域驱动设计的时代。在微服务时代，确定明确的上下文边界非常重要。“逻辑生活在多种服务中”听起来更像是一种设计坏气味。在这种情况下，即使非常简单的业务需求的变化也可能意味着系统的多个部分发生变化，这可能意味着对许多不同服务进行多次重新部署。还意味着更复杂的集成（甚至是e2e）测试。
4. 首先，贫血模型在服务环境中运作良好。您不能将业务规则作为数据实体的一部分，然后从一个网页发送到另外一个Web服务，。所以这些贫血模型在这世界上还是有一个位置的。
微服务仍然是服务。因此，我们始终验证跨越信任边界的数据 ，执行该验证的规则不能随数据一起传播。
如此内疚，因为贫血使我感到......奇怪。(banq注：这是将充血和贫血对立，作为充血模型是业务体现，当数据需要传播时，应该变成值对象或失血模型传播，验证规则还是在充血模型实体中，两者共存，而不是二选一，将网页具有UI模型或持久层模型、接口模型与领域模型分离。)
5. Folwer跳过了很多步骤并且做了很多断言。以下是其书籍《重构》的摘录：
>软件的性能通常仅取决于代码的几个部分，而其他任何地方的变化都不会产生明显的差异。
>因此，我对重构性能的总体建议是：大多数时候你应该忽略它。如果您的重构引入性能减慢，则首先完成重构并在之后进行性能调整。
这种“偶然”缺陷的缺点只是使福勒的所有写作都像营销之类的事情。
关于软件是不是工程的争论：
6. 计算机科学不是一门科学，软件工程也不是一门工程学。他的指南更像是写作指南，缺乏数据。
7. 许多编程更多的是艺术或工艺而不是工程。
例如，机械师与工程师之间的区别是什么？他们经常在同一个项目上工作，似乎也在做同样的事情。在我看来，机械师遵循经验法则，眼球设计等。工程师应用数学并导出设计，或使用数学检查设计。机修工会说“这个梁看起来足够厚，可以承受负荷”，工程师可以进行计算，为负荷选择正确的厚度。
对于软件，程序员可以告诉您quicksort更快。工程师可以告诉您为什么它更快，并能够计算它的速度。
8. 软件工程的工程设计与机械工程是工程学一样。
唯一的区别是，使用软件，您的材料是描述。即你描述的东西，给计算机和计算机把它变成这个东西。
最后，世界上有一个物理实体（硬件），它根据您的描述（例如ATM）将自身变成一台独特的机器。
在机械工程中，您的材料是物理的，这可能使其更容易解释。
9. 软件开发既是一门艺术，也是一门科学。
就个人而言，我看到人们在一个项目的早期阶段就做出了糟糕的设计决定，这个项目将成为后来处理的主要问题。很容易看出，如果他们在一开始就花费了一点额外的质量，它会在几周甚至更短的时间内得到回报。
我也看到其他人花费太多时间在一开始就试图做到完美，没有任何东西可以交付，或者过度设计的解决方案会产生自己的技术债务形式。
每种情况都不同，因此您需要判断是否应用某人的建议。
10. 软件开发不需要成为一门艺术，也不需要成为一门科学。
科学的意思是使用数据和统计证据推动发展，艺术的意思是利用你的直觉和你的直觉来推动发展。
计算机是确定性系统。它是100％可预测的，并遵循一套精确的规则。软件开发适用于证明，逻辑和理论。如果问题空间可以用逻辑和公理理论来描述，那么你不需要做出由数据驱动的决策或你的直觉。
问题是当前的“理论”是不完整的，并非系统的所有部分都适合进行统计测量。因此，一个合适的系统架构师需要统一理论，科学和艺术，以形成一个连贯的系统架构框架。
Martin Fowler的问题在于他所有的东西都是100％艺术。它只是由直觉和流行语构成的东西。艺术在很大程度上是临时性的，并且涉及大量猜测工作，这些工作经常是错误的。人们认同Martin Fowlers的东西，因为他们在“肠道”层面上认同它。它“感觉”正确。你的感受不是做工程的好方法，当你别无选择时，你只依靠直觉。
Fowler也是一个面向对象的大型架构师。面向对象的东西是它没有理论或科学的基础，几乎是100％的艺术。这种模式从一开始就失宠，因为人们意识到他们倾向于在遵循模式时会构建过于复杂的系统，因为他们主要依靠他们的直觉来使用由同样有缺陷的直觉验证的原语来构建这些东西。
11. >面向对象的东西是它在理论或科学上没有基础，几乎是100％的艺术。
绝对不正确。
OO的数据部分基于集合论，在数据库设计研究和类型系统中形式化。
OO的动态部分基于有限状态机。
数据抽象和信息隐藏部分基于barbara liskov的工作（她为此赢得了图灵奖） - https://en.wikipedia.org/wiki/Barbara_Liskov
12. 类型系统不是OO独有的，另外OO类型系统允许突变，这基本上根本不是集合论的所有部分。类型系统和数据库系统也没有形式化集合论。集合论来自数学。
>数据抽象和信息隐藏部分基于barbara liskov的工作（她为此赢得了图灵奖） - https://en.wikipedia.org/wiki/Barbara_Liskov
这与类型系统有关，然后与OOP有关。如果您阅读本文，请注意。她的论文没有数据，统计，形式理论，严谨，定理，证据或公理。因此虽然她获得了图灵奖，虽然这是一篇研究论文......但在我定义的意义上，它在很大程度上是“艺术的”。见这里的论文：
HTTP：//citeseerx.ist.psu.edu/viewdoc/download DOI = 10.1.1.136 ...
请注意，她的论文很重要，我并不打折扣。但它更多地出现在设计领域，那么它就属于理论和科学领域。
13. 她在后来的书中提出了公理理论：
HTTPS：//mitpress.mit.edu/books/abstraction-and-specification ...
她是否提出了OO界面设计的公理理论。
绝对不是艺术。
OO中唯一具有艺术性的东西（作为过去30年来实践它的人）正在寻找最初的一组对象。但是你会遇到任何技术问题。
14. > OO中唯一具有艺术性的东西（作为过去30年来实践它的人）正在寻找最初的一组对象。但是你会遇到任何技术问题。
OO具有很高的艺术性。它不仅仅是您决定的初始对象集，而是您必须决定每个单个对象的组成方式以及组成的对象。有很多关于如何组合对象以及何时编写组合的技术：继承，依赖注入，对象组合等等。在这些技术中，您仍然需要编写自定义代码，父级对象是什么，子对象是什么？什么属性？父级对象如何使用注入的对象？等等......你在设计系统而不是在理论框架内运作。这主要是艺术。
如果您在现有理论的框架内运行，您将能够更好地预测大规模系统的结果，但是因为在OO中您几乎为每个应用程序从头开始创建系统，这在很大程度上是不可预测的。
在数学中，所有定理都来自你选择的公理。几乎没有偏差的余地。
任何人为创建的系统都可以融入某种理论的框架中。虽然艺术设计的系统与源自理论知识的系统之间存在巨大差异。
关于DDD和微服务：
15.我分享一下我的经验。几年前，我正在为我的公司内部开发一个电子商务平台。我遵循Martin Fowlers关于使用DDD（域驱动设计）和微服务来构建应用程序的文章。应该是一个月的项目花了我们8个月！我不包括我阅读，理解和练习DDD及其周围概念的时间。每本DDD书至少500页或更多。他们都没有清楚这些概念，而且大部分都充满了绒毛。
我们的堆栈基于Phoenix，但它使用了一个名为Umbrella应用程序的概念（基本上是微服务模式）。一路走来，我遇到了很多障碍，我想我一定是做错了。因为，这就是这些作者一直对那些未能实施他们的讲道的人说的话。所以，我遇到了几个实际上比我更大规模地完成DDD的人，甚至他们分享了同样的失败和挣扎的经历和故事。尽管如此，我还是耸耸肩，认为这肯定是我们做错了而不是DDD / Fowler的教诲本身。与此同时，我们正在努力为我们的电子商务软件推出功能，因为我们基于DDD的微服务架构此时只是一个纸牌屋。然后，我终于打电话给我知道成功完成DDD的人并问他是怎么做到的。他说，一个受欢迎的DDD相关网站的作者之一曾提出为他的公司提供咨询。他们别无选择，只能雇用他，因为他们在这一点上投入了很多。过了一段时间，我开始会见一些这样的公司，他们的作者或某些供应商完成了他们的DDD设置。
然后BINGO，这一切都是有道理的 - 这些作者的大多数这些模式/捷径/发现/秘密酱很难被他们测试。这只是向您提供更多咨询和培训的一种方式。
几个星期后，我们在我们区域召开了一次临时的技术会谈聚会，我们遇到了更多跟随同样道路而失败的人。我们终于决定在一个周末做一个小黑客马拉松并完成我们的项目。最后，在距离Fri-Sun大约3天的时间里，我们使用单体架构完成了比DDD和微服务所做的更多的工作。今天，我的平台正在制作中，是一款引以为豪的单体应用，并且仍然很强大。
这可能是我学过的最昂贵的课程，但是我会记得很长一段时间。
16. Martin Fowler也写道：DDD适用于大型复杂软件。他还建议在微服务之前使用单体巨石。
如果你花一个月就能完成的东西，那就不大也不复杂，它不适合DDD或微服务。
微服务并不总是微观的。这是一个糟糕的名字。5-10的团队通常只在一个微服务上工作。1个微服务可以是数百万行代码。
17. 为什么你仍然每天都会在reddit和HN上看到人们彼此喋喋不休的几乎所有软件设计辩论。（并且软件使用争论甚至更糟。）他们的方法是最佳的，他们的对手是非常过度工程或不充分的工程。
人们喜欢坚持自己的偏好，更喜欢他们在经验不足和技术熟练时所偏离的东西，或者他们尊重的人使用的东西，或者几年前发生在他们的幻想或迷恋中的东西，或者是他们主观上的原因感觉不错。你可以在其他学科中看到完全相同的东西，包括艺术领域，以及完全相同类型的讨论板上的vitriol和货物结果。
好消息是你至少要接触到很多观点。如果有人只读了这个帖子中1/4的帖子，他们可能会被说服采取某种强硬立场，并发现自己走上了一条狭窄的道路。但是，如果他们阅读每一篇文章，他们都可以全力以赴，了解有多少激烈的分歧和模糊，并对正确或错误的做事方式更加怀疑和批评。
18. 在微服务架构中，故障处理很容易。状态管理很难。
在集中式数据库架构中，故障处理很难。状态管理很容易。
19.有时，从长期维护的角度来看，只有在足够长的时间内保持产品市场适应性的捷径才有意义。获得资金并生存。
Twitter就是一个很好的例子。每个人都同意Twitter做出一些糟糕的架构决策，导致频繁出现“失败、故障”。但最终，他们通过VC资金和后来的公共市场的组合获得了足够的资金来重新架构他们的系统。
20. 系统软件与企业软件没有什么不同。业务部分仅仅是技术性的。最大的区别通常是软件开发人员对业务规则没有深刻的理解。
关于UML讨论：
21. 从UML图表生成完整的代码。这就是整体推动OO的整体宏伟愿景。我认为这是“低代码”创业公司现在正在发生的事情。
整个想法是将全局决策（难以改变）分开 - 例如架构，什么类，每个类做什么，来自本地（例如使用哪种数据结构）。因此，您将使用UML进行全局决策，而不是使类的编程变成机械的写代码。
当然，客户看不到这一点。客户查看用户界面，以及是否正确实施了整个用例。因此，使用这些工具可能有所帮助。
让我们以架构为例，为什么人们会使用架构师？为什么架构师需要图表？业主是否会关心建筑师使用AutoCAD设计图表呢？
22. 如果您的经验告诉您UML适合您作为工具，那么，无论如何，坚持使用UML。即使有一种方法可以解决问题。如果你使用钢笔和纸张快速绘制东西，那么，如果这对你有用，那同样有效。我只是不会忽视一种方法，因为它的用处无法预先测量。现实实在太复杂了，有时候首先对这一切进行过多考虑并没有任何意义。