如何使软件与业务流程保持一致？
根据我的经验，当业务流程发生变化时，与业务流程保持良好一致的软件更容易更改。什么类型的架构最适合这种方法？
In my experience, software that is well aligned with business processes are easier to change when the business processes change. What type of architecture is best suited for this approach?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
好问题...但首先...SOA？这是一个很棒的流行词，但经常被误解，很大程度上是由于缺乏任何一个“真正的”定义。哎呀！甚至 Martin Fowler 现在也将其称为“ServiceOrientedAmbiguity”，并鼓励人们完全避免提及它。
确实不存在“一个”“最佳”答案。企业对 IT 的需求可以是：通常是；变化很大。这些需求通常受到外部驱动因素的影响，例如客户、合作伙伴、市场趋势、立法、监管机构等。在许多情况下，这些驱动因素决定架构，或者至少损害或限制您完全实现您认为可能“更好”的能力。 “ 建筑学。这听起来也可能是油嘴滑舌，但这不是我的本意。存在“最佳”架构这样的概念导致许多人继续浪费大量的精力（和金钱）来追求它。尽管可能不是故意的，但这些观点通常得到了那些成为单个供应商/社区代理人的人的支持，或者将流程作为产品出售给您。
话虽如此……从软件工程的角度来看，旧的原则仍然是确保您能够满足业务需求的最可靠的方法。例如，
请注意，没有提及任何一种架构模式、技术或语言……这是因为这些并不是真正的驱动因素，尽管它们可能是推动因素，并且会因各种因素而发生变化。让我再谈一点。 “业务流程”和软件工程流程有非常不同的关注点、视角等......强迫任何一个组与另一个组发挥相同的作用只会导致彻底的失败。这并不是说他们不应该分享日期、功能性可交付成果等承诺。这些团队需要有所不同才能有效地完成工作，但肯定需要找到方法来传达那些需要共同愿景的事情。这是任何数量的设计和生命周期管理流程都可以提供帮助的地方。 （例如 DDD、MSF、SCRUM、CMMI 等）。
我的意思是这是有建设性的......希望它有所帮助。
Good question... But first... SOA? That is a great buzzword but is often misunderstood, largely due to the lack of any one "real" definition. Heck! even Martin Fowler now refers to it as "ServiceOrientedAmbiguity" and encourages people to avoid bringing it up at all.
There really is no "one" "best" answer. The demands placed on IT by businesses can be; and usually are; quite varied. These demands are often influenced by external drivers such as customers, partners, market trends, legislation, regulators, etc. In many cases these drivers dictate architecture, or at least compromise or constrain your ability to fully acheive what you feel might be a "better" architecture. That may also sound glib, but that is not my intention. The notion that there is such a thing as a "best" architecture leads many to continue to waste huge amounts of energy (and money) in its pursuit. Although it may not be intentional, these perspectives are often backed by people who have become proxies for a single vendor/community, or are selling you a process as a product.
With all that said... from a software engineering perspective, the old tenets continue to remain the most reliable means to ensuring you can meet business demands. For example,
Notice there is no mention of any one architectural pattern, technology, or language... that's because these aren't really the drivers, although they may be the enablers and will change given a variety of factors. Let me touch on one more point. "Business Processes" and software engineering processes have very different concerns, perspective, etc... Forcing either group to function the same as the other will only lead to utter failure. That's not to say they shouldn't share commitments such as dates, functional deliverables, etc. These groups need to be different to do their job effectively, but certainly need to find ways to communicate those things that require a shared vision. This is where any number of design and lifecycle management processes can help. (Ex. DDD, MSF, SCRUM, CMMI, etc...).
I meant this to be constructive... hope it helps.
圆滑的回答：企业架构。
您真正在寻找什么样的答案？根据我的经验，每个企业都有独特的需求，特别是当涉及到他们想要发展的方向时。可修改性只是理想的品质之一，与成本控制、上市时间、效率、安全性、可用性和剩下的一群人。
Glib answer: an enterprise architecture.
What sort of answer are you really looking for? In my experience, each business has unique needs, especially when it comes to the directions they want to evolve in. Modifiability is just one of the desirable qualities, competing for resources with cost control, time to market, efficiency, security, usability and the rest of the gaggle.