【发布时间】：2010-05-14 09:57:33
【问题描述】：
根据我的经验，当业务流程发生变化时，与业务流程紧密结合的软件更容易更改。哪种架构最适合这种方法？
【问题讨论】：
标签： architecture business-process
【发布时间】：2010-05-14 09:57:33
【问题描述】：
好问题...但首先... SOA？这是一个很棒的流行词，但经常被误解，主要是由于缺乏任何一个“真实”的定义。见鬼！甚至 Martin Fowler 现在也将其称为“面向服务的歧义”，并鼓励人们完全避免提及它。
确实没有“一个”“最佳”的答案。企业对 IT 的要求可以是：通常是；相当多样。这些需求通常受到外部驱动因素的影响，例如客户、合作伙伴、市场趋势、立法、监管机构等。在许多情况下，这些驱动因素决定了架构，或者至少会妥协或限制您完全实现您认为可能是“更好”的能力“ 建筑学。这听起来也很油嘴滑舌，但这不是我的本意。存在“最佳”架构这样的概念导致许多人继续在追求中浪费大量的精力（和金钱）。尽管这可能不是有意的，但这些观点通常得到那些已成为单个供应商/社区的代理人或正在向您出售作为产品的流程的人的支持。
话虽如此...从软件工程的角度来看，旧的原则仍然是确保您能够满足业务需求的最可靠方法。例如，
- 分开您的顾虑
- 分层架构
- 设计时考虑到灵活性
- 单独测试层，然后一起测试它们
- 采用持续集成实践让回归更快可见
- 将要求和规范作为主要驱动力
- 投资于工具，投资于您的开发人员
- 等等……
请注意，这里没有提到任何一种架构模式、技术或语言……这是因为这些并不是真正的驱动因素，尽管它们可能是推动因素，并且会因各种因素而改变。让我再谈一点。 “业务流程”和软件工程流程有非常不同的关注点、观点等……强迫任何一个组与另一个组功能相同只会导致彻底失败。这并不是说他们不应该分享诸如日期、功能可交付成果等承诺。这些团队需要与众不同才能有效地完成工作，但肯定需要找到方法来传达需要共同愿景的事情。这是任何数量的设计和生命周期管理流程都可以提供帮助的地方。 （例如 DDD、MSF、SCRUM、CMMI 等...）。
我的意思是建设性的......希望它有所帮助。
【讨论】：
-
感谢您提供非常好的和平衡的答案。我特别同意要求和规范应该是您的主要驱动力。与业务无关的其他因素往往会影响我们的解决方案。
Glib 答案：企业架构。
您真正在寻找什么样的答案？以我的经验，每个企业都有独特的需求，尤其是当涉及到他们想要发展的方向时。可修改性只是理想的品质之一，它通过成本控制、上市时间、效率、安全性、可用性和其他人。
【讨论】：
-
你是对的。还有更多的品质。我选择了可修改性，因为它可以使业务更加敏捷，并且应该反映上市时间。我认为 SOA 是一种以业务一致的方式构建软件的方式。