一年前，马克西姆·阿什诺夫（Maxshi Arshinov）（marshinov）发表了题为“即时设计”的演讲。 很棒的报道，有魅力的演讲者，最后有用的材料。 这份报告改变了我对自己正在做的事情的理解-我们中哪个人没有尝试直观地应用管道架构？ 然后是乘以DDD的优雅解决方案！ 这是我作为特定领域设计的推广者开始的旅程。

DotNext 2019莫斯科即将推出。 与往常一样，我们正在等待对新功能的审查，经验交流，最佳实践，体系结构解决方案-为此，我们所有人都喜欢会议。 报告列表中有wokshop “主题模型的闪耀和贫困” ，引起了我的注意。 从页面引用：

Fowler和Evans认为贫血模型是反模式。 但是，演讲者使用的许多代码库都是以贫血模型的形式实现的。 该报告致力于比较两种方法的优缺点，以及在OOP范式和功能样式中实现领域模型的不明显细节。

生产本身使人们认为DDD运动的发展已经出现了危机。 剖析使用功能障碍以及这种变形的原因。

使用面向对象设计的功能障碍

当前的情况具有一定的历史发展。 让我们分阶段考虑局势如何发展。

晋升

我认为，Maxim是社区中最著名的开发人员，多年来，他们积极地推动了DDD的发展，并讨论了概念，用法。 尊敬他并称赞他！ 我以Arshinov为例，只是因为我认为他目前是dotnext的最佳发言人。

功能障碍1：获利能力

marshinov写了几篇有关实施DDD实践的成本的文章。 结论很简单-面向主题的设计很昂贵。 而且判断是公正的-埃文斯本人在书中指出，团队必须非常熟练，因此非常昂贵。 另外，这些都是持续的改进，这对于企业来说是昂贵的。 好揭示马丁•福勒（Martin Fowler）关于建筑成本的主题文章。 我敢于假设，企业要花费多少资源是首先要解决其自身的问题。 而且客户无法解决自己的任何重大问题，那么即使SOLID也无法将其出售。

了解业务需求和体系结构决策的对立关系非常重要。 企业需要最便宜的解决方案来满足他们的需求（并且第一次和永远都更好）。 团队希望提供最正确，快速和美观的工具和解决方案，以解决业务问题，尤其是适应变化的任务。 这些需求的性质（实际上是两极矛盾）是非常辩证的，这反过来意味着如果不详细说明体系结构就不可能实现复杂的需求，并且不能建造公寓来代替狗窝。 不，当然一切皆有可能。 但是事实是，一方面高的要求引起了相应的要求。 就像一侧的病理缺陷一样，它限制了另一侧。
因此，为了匹配业务，又形成了第二场灾难...

功能障碍2：即时设计（又称贫血模型）或同意

显然，某些程序员社区正在尝试将更便宜的面向主题的设计引入大众，降低成本并应用新技术：RailwayProgramming，Pipelines，Anemic模型。 许多建议认为，这是一种很酷的方法，可以教给任何程序员：“在这里，您的SeedWorks具有接口，可以实现它们，一切都会实现。” 而且有效！ 但这不是DDD。

您不太了解Evans。

• 谁不赞扬Klopstock？ 但是每个人都会读吗？ 不行 我们希望少受尊敬，但请多加努力阅读！ （减少）。

我现在解释。

贫血模型是反模式

事实是，科学中有两种研究方法：描述性和分析性（你好亚当·斯密）。 制作Anemic模型时，我们只需描述所见内容，并按原样使用它。 这反映了一项业务，足以实现商机。 Evans描述的一个重要原则不是在理想的系统上浪费资源，而是按原样模拟过程，然后才开始进行深度重构。 在什么时候可以使用Anemic模型进行深度重构？ 它应该完全启动吗？ 在我看来，答案将是否定的，这里的模型仍然是虚构主义。

那仅仅是模型本身并不重要！ 战术模式并不重要！ 有限的上下文，单一的语言和大规模的结构很重要。 这就是为什么有必要从分析的角度来研究业务实体，描述聚合根，价值对象，业务方法，并因此了解有限上下文的边界。

一方面，贫乏的模型和廉价的解决方案是好的，因为新手程序员将了解编程中的新维度-业务对象。 但是，如果采取类似的职位，您自己的工作就很糟糕。 通过每次雇用一个能力较弱的程序员来完成与复制粘贴相同的操作，您是否有理由要求企业寻找更强大的员工？

但这不能以DDD想法的光辉终结而告终。

功能障碍＃3业务对象（又称工具复杂）之后的生活。

在2019年春季，Maxim和Wagib告诉我们C＃中F＃的功能是如何出现的，如何在F＃中正确地建立模型更容易，以及功能主义中如何不违反OOP。 现在，大众可以相信，不仅DDD不仅可以订购音乐，而且不是所有凡人都能负担得起的，而且只有那些了解函数式编程的人才能负担得起。

聆听它们的驱动力-现在面向主题的设计非常昂贵，您只能有效地用F＃编写，并且有时有时可以正常工作。 没有淡淡的印象，以这种方式，书籍和文章的作者将我们从DDD中最重要的部分中分散了出来，从而以理想的战术模式吸引了游戏。 而且它们必须美丽且被舔，否则...

当然，没有其他办法。 当每个人都需要非常清楚地了解所有内容时，所有这些抽象在BrainSrorm对话中都很重要。 或者，如果您找到将查看您的代码的经理和分析人员-一种语言（如果代码为UL）。

但是，如上所述，对立面将寻求自己的方式。 这种方法已经扎根于企业愿意为功能上不明显的代码的开发支付费用的地方-这只是市场的利基市场，而不是规则。

这里绝对令人恶心的是对成就的态度的简单的人性-人们欣赏自己的成就，却没有给予形式和应用的意义。 这里的清单可能很长。 爱因斯坦给我们提供了STO，GR，FE，他是一位杰出的科学家，但他向相对普通的人询问相对论运动，时间-他不需要爱因斯坦，但是在一次“智能”对话中，人们可能会提到一切都是相对的。 向某人询问弗洛伊德（Freud）是一位在科学领域取得了长足进步的杰出心理学家，例如，该人是否使用心理学来解释昨天的噩梦-他不会，但他有一天会提到性与大众的心理。 马克思是用社会学和历史学创造科学的人，但是没有人需要科学社会主义，但是每个人都可以谈论累进税制和诚实民主。 面向问题的设计也没有任何形式-埃里克·埃文斯（Eric Evans）为我们打开了一个新的台阶，为降低软件复杂性提供了出色的工具，但表面上如何使用DDD以及执行的操作表面上尚不清楚，而且通常根本不起作用。

我不知道其余的如何，但是通过面向主题的设计，您可以了解造成误解的原因。

使用危机的原因

面向主题的设计原理非常诱人，合乎逻辑且具有整体性。 一切都近在咫尺-敏捷，CI，SOLID，GRASP-开发人员想出的最好的一切。 但是，仅仅相信DDD，业务或经验是不够的。 社区中的许多人，仅仅是集成商和外包办公室的开发人员，在他们的工作中都留下了商业价值的烙印，并且他们迫切希望不能尝试领先的方法和实践，因为这些尝试和错误的价格未包含在价目表中-这完全是一种实质性的结局。

除了如何使编程赚钱，使用更简单的方法，以更低的价格雇用开发人员之外，这些命令绝对没有剩下，但贫乏的模型可以被“半英寸”钩住。 如果您是一个小时开发人员中的一个的开发人员-您没有很大的前景-您必须完成订单，并且仅在家庭项目的github上鼓励创造力。 对于建筑师来说，DDD不是奢侈，不是客户炫耀-单独的Enteprise中的团队级别。 您需要意识到以下几点-当您与那些将您的熟练工作卖给那些薪水更高的人建立生产关系时，您只会做客户付钱的事情-实现业务任务。 不幸的是，测试最佳实践并不总是处在这些任务的范围之内。

总结

如果您要描述真实世界的对象，则可以始终尝试DDD。 这种方法可以在PHP，VBA和1C中应用（开发人员可以应用）。 在人与人之间的交流中，采用该方法的问题更有可能出现，而技术则更有可能提供帮助。 交流，尝试，教别人！ 提高软技能，团结互助，目标统一。 DDD只是一种团队合作技术。

下次当您考虑去哪儿面试时，请仔细考虑您的选择-公司毫不留情地转售您的技能，或者真正需要他们解决特定问题的人。 您有能力帮助这样的公司做得更好，尝试按比例的方法和方法，组成一个团结的团队，以完成您作为程序员的使命。 后者尤其重要，因为对于新技术和好东西，许多人已经忘记了该专业的初衷。

尽管如此，仍然有希望的是，在尝试接触领先实践时，DDD不会为了方便客户和团队而朝任何其他方向转变。 我期待着即将发布的报告。

PS 该主题的目的是邀请进行讨论。 贬低DDD社区的任何成员的优点是没有目的的。 尊敬的是，我请所有代表，这不能消除发展问题。