【发布时间】：2009-01-21 16:58:07
【问题描述】：
关于如何开发能够适应不断变化的业务需求的软件的想法？任何模式、架构等。可能一些轶事示例会很棒。这更像是一个调查，而不是一个具体的问题。谢谢
【问题讨论】：
标签： architecture design-patterns
【发布时间】：2009-01-21 16:58:07
【问题描述】：
您将想要了解有关整个Agile Development 运动的更多信息。敏捷就是它所说的：能够快速适应。
【讨论】：
在我看来，具体代码比通用和抽象代码更易变化。因此，如果您想要可更改的代码，请坚持使用特定代码并避免元编程。
从现在起 6 个月后，很可能没有人会了解这些通用和抽象方法的真实用例并害怕更改它们。
【讨论】：
如果这是您的开发环境，您将需要使用Agile development process。
作为此过程的一部分，您可能希望不断有一个工作系统向您的客户展示，以便他们可以在此过程中进行路线修正。这将帮助他们了解正在取得的进展以及您所处的位置。但更重要的是，这将使他们更好地了解系统如何满足当前的业务需求，以及他们的新更改将产生什么影响。
请注意不要让您的原型在视觉上很吸引人。如果原型看起来图形精美，那么您的业务开发人员很有可能会认为该软件很比实际更完整。相反，我建议尝试让它看起来不那么精致，并更多地关注功能。例如，如果您正在使用 Java Swing，那么有一个很棒的 look & feel called Napkin 可以帮助您解决这个问题。 IT 允许您构建尽可能多的功能，但屏幕看起来就像是在餐巾纸上绘制的。所以人们的注意力和关注点都在功能上，而不是图形细节上。
【讨论】：
试图设计一个可以轻松适应不断变化的需求的通用系统是行不通的。正如 Mark 所暗示的，整个敏捷运动都源于这样一种认识，即简单的特定代码比通用代码更容易适应，只要它编写得好且可维护。
【讨论】：
Domain-Driven Design 是一个很好的方法，有一本好书可以帮助你前进。
这种方法的一个重点是软件中使用的开发领域模型与它所建模的实际“现实世界”之间的紧密反馈循环，因此可以改变现实世界。
【讨论】：
考虑业务需求变化的规模：
- 如果小规模需求经常变化，即人们改变了他们对想要什么的想法，但他们需要做的事情并没有真正改变，那么采用敏捷实践并保持您的迭代非常短（短至 1 个功能迭代，如果有必要实际完成某事！）
- 如果更大规模的需求经常变化，即运营业务需要哪些基础设施，这可能反映了管理人员的突发奇想（我认为是“最后一个推销员综合症”——不管最后一个推销员在卖什么突然的未来之路）。如果您参与这些决策，请尝试将技术问题减少到基础（通信、存储、计算、交互、访问……），并且不要被产品级的花里胡哨分散注意力。请记住，没有什么事情可能是 100% 适合的，但是过于频繁地改变主意的成本可能会超过改变平台或架构的好处。如果您没有参与这些决定，那么除了快速学习并在可能的情况下温和地鼓励更深入的承诺之外，您无能为力;-)
- 如果业务的性质经常变化，即每隔几周就需要新的业务线，合并旧线等，并且您参与了这一级别的讨论，您可以尝试通过探索来预测未来的变化更深入地了解公司计划。如果您没有参与到这个级别，请尽量保持灵活和无价，直到您找到更稳定的公司的工作;-)
【讨论】：
考虑一个业务规则引擎。并不总是合适的，但可以帮助将业务逻辑和需求与您的技术架构/解决方案分开。例如，假设您需要根据一组测试结果设置汽车的安全等级。在汽车上进行的测试可能会改变，分类标准也会改变（包括分类的实际数量，例如从 5 星系统到 10 星系统）。在这种情况下，业务规则引擎可能是对汽车进行分类的好方法。
规则引擎将提供基于文本或 XML 的规则，至少在理论上，这些规则可以由非编程人员（例如业务分析师）编写和维护。这些规则将应用于Car 对象（假设Car 对象包含对TestResults 对象的引用）。规则/规则引擎将分析测试结果并相应地设置Car 对象的SafetyClassification 属性。
实际规则可以驻留在数据库或共享位置，甚至可以通过消息传递基础架构或 Web 服务调用提供给系统。无需重新编译/重新部署系统即可将新规则提供给系统并激活。
不同的技术有不同的规则引擎可用。例如，.Net 有 Drools.Net、WWF 规则引擎，以及其他一些。 Java 有 JBoss 规则以及许多其他规则。
【讨论】：
（几乎）每个程序都有不断变化的业务需求。 尝试与客户谈判（营销或产品经理也是客户）很重要，但还不够。需求总是变化的。 Scrum 有很多技术来管理需求的变化。
【讨论】：