mac*_*iek 5 nhibernate domain-driven-design
我开始的新地方刚刚开始从头开始开发一个全新的产品。他们正在应用程序服务中使用事务脚本，完全愚蠢的实体，以及带有存储过程的手动 DAL（论点是 nhibernate 不能很好地优化 sql，加载太多东西，不能很好地扩展到大型项目等等等等）。该应用程序应该是刚刚起步的巨大项目。
我来自一个位置，我正在做域模型，其中封装了所有业务逻辑，应用程序服务仅处理基础设施 + 使用 nhibernate 加载模型并编写脚本。
我真的相信采用第二种方法要好得多。我正计划做一个关于为什么的演讲。我有很多书籍/文章/个人意见，我可以支持这一点……但更像是一个“初级”在那里可能没有多大意义（我也是我最后一个地方的单一开发者）。
我正在寻找的是来自更高级人员的一些失败项目的经验/技巧/示例，为什么使用事务脚本/手动 DAL 不是正确的想法。
除了Paul T Davies和Magnus Backeus所说的之外。我认为归根结底这将是一个人和文化问题。如果人们思想开放并且愿意学习，那么说服他们就会相对容易。如果他们认为你是“初级”（这是一个坏兆头，因为唯一重要的是你所说的内容而不是你的年龄/经验），你可以向“更高的权威”提出上诉：
存储过程已经死了，你不是唯一一个这么认为的人：
令我们惊讶的是，我们在 2011 年继续发现在存储过程中实现重要业务逻辑的新系统。通常用于实现存储过程的编程语言缺乏表达能力，难以测试，并且不利于简洁的模块化设计。您应该只考虑在存在已证实的性能问题的特殊情况下在数据库引擎内执行存储过程。
说服那些不愿意改进和学习的人是没有意义的。例如，即使你设法赢得一场争论并挤进 NHibernate，他们最终也可能会像以前一样编写紧密耦合、不可测试、面向数据或 linq 的代码。DDD 很困难，需要改变很多假设，会伤害自尊心等。根据公司的规模，这可能是一场不值得开始的持续战斗。
《推动技术变革》这本书可能会帮助您解决这些问题。它包括您可能会遇到的几种行为刻板印象：
祝你好运！