所以我从团队中的一位开发人员那里得到了这个问题:什么是域驱动设计？我当然可以指出埃文斯的这本书,但这实际上是一个答案吗？
您如何用几句话向团队中的初级软件工程师解释DDD？
我知道如何使用文本格式化程序使用Microsoft Enterprise Library 2.0发送邮件.但这些电子邮件始终是纯文本.有没有办法使用entlib 2.0以HTML格式发送这些邮件？
在另一次压力释放之后,软件工程师会遇到什么？好吧,我们在小组中遇到的第一件事是我们在公开场合发布的错误.我们作为软件工程师在压力释放后遇到的最大问题是意大利面条代码,也称为泥球.
追求完美的时间和金钱很少可用,也不应该.为了生存,我们必须尽一切努力让我们的软件按时运转.事实上,如果一个团队有时间完成一个项目,今天的管理人员很可能会将其作为一个标志,以便在下一次提供更少的时间和金钱或更少的人.
您需要在预算范围内按时交付高质量的软件
成本:架构是一项长期投资.支付账单的人很容易解雇,除非有一些切实的直接利益,如税务注销,或者除非有多余的资金和时间可用.这种情况很少发生.更常见的是,客户需要明天工作的东西.通常,控制和管理开发过程的人根本不认为架构是一个紧迫的问题.如果程序员知道工艺是看不见的,而管理者无论如何也不想为此付出代价,那么就会产生恶性循环.
但如果真的如此,那么每个长期的软件项目最终都会导致一团糟.
我们知道并非总是会发生.怎么会？因为管理者不把架构视为紧迫问题的说法是错误的.至少现在.IT领域的管理人员非常清楚可维护性是业务的关键.
业务依赖于驱动它的数据.企业已经变得严重依赖于他们的软件和计算基础设施.有许多关键任务系统必须每周二十四小时/每周七天播出.如果这些系统出现故障,则无法检查库存,无法支付员工费用,无法路由飞机等.[..]
因此,寻求方法使系统远离泥泞的大球是业务的核心.该系统仍然可维护.系统实际上是有效的,而且你作为程序员可以证明它确实如此.你的经理是否问你今天是否完成了编码,她是否会问你是否可以在今天完成修复A,B和C的版本,或者她是否询问将要发布的软件是否真的有效？你证明它有效吗？什么？
现在我的问题:
我们有什么方法可以向我们的经理和/或利益相关者证明我们的软件有效？我们软件单元测试的那些绿灯是否足够好？如果是的话,那不仅仅证明我们的泥球仍在按照我们的预期行事吗？该软件是否可维护？你怎么能证明你的设计是对的？
[后来添加]
Chris Pebble他的回答是让我的团队走上正轨.质量保证绝对是我们正在寻找的东西.谢谢克里斯.与利益相关方达成一致的QA政策不是我的团队所寻求的合乎逻辑的结果.
后续问题是质量保证政策应该是什么？
更多信息:我领导的团队正在构建其他软件团队所使用的Web服务.这就是为什么破坏网络服务立即花钱的原因.当演示层团队的开发人员或实际的测试人员无法前进时,我们立即面临压力并且必须尽快修复错误,这反过来会导致快速破解.
[稍后补充]
感谢所有的答案.这确实是关于'信任'.如果利益相关者不信任该软件,我们就无法发布,他们正在使用使用我们的网络服务的网站自行测试我们的软件.出现问题时,我们测试人员的第一个问题是:它是服务层问题还是表示层问题？这导致我有一个质量保证政策,确保我们的软件可以用于他们正在进行的测试.
因此,我能够(现在)设想与测试人员建立信任的唯一方法是: - 与当前的测试团队交谈,检查他们能够手动执行的测试(来自他们的测试脚本和场景)并确保我们的团队将这些测试作为单元测试已经检查过我们的Web服务.在我们发布presentationlayerteam必须集成的版本之前,这将是一个"签字"的良好起点.需要花费一些精力来澄清为所有这些场景创建自动测试需要一些时间.但它肯定会有用,以确保我们构建的实际工作.