我正在为一项新业务设计一个系统，并且处于一个独特的“全权委托”职位。
就像它计划持续很长时间并发展到不确定规模的每家企业一样。
是否值得全力以赴并开发具有显式数据和服务总线的完整企业架构，其中每一层都是某种 Web 服务...或者我应该设计一个可能工作的最小系统并计划发展随着时间的推移，它会有机地流逝。
根据我的经验，有机生长 ™ 系统在我看来是最难继承的，所以我想知道社区的想法是什么？
我们是否正处于发展没有这些层的业务是一种不好的做法的阶段，即使它很小？
谢谢
【问题讨论】：
标签： architecture
如果不知道您的项目的具体情况作为一般经验法则，我会选择可行的最小/最简单的解决方案。如果他们期望在很长一段时间内成长，他们应该期望他们的 IT 解决方案与他们一起成长。
很不幸，但似乎大多数软件都需要尝试几次才能正确处理，即使这样，自然发生的变化也很难处理。
因此，除非您能非常清楚地说明为什么最好将精力投入到未来可能/发生/需要的事情上，否则我会保持简单。
就继承有机增长™系统而言，我认为如果利益相关者不知道您从简单的东西开始，一旦需求发生变化可能会被抛弃（但体验不会！ !!!）那么它可能是噩梦，因为你不能做正确的事情。但是，如果每个人从一开始就知道这个想法是什么，并且他们应该期待 IT 解决方案的变化以及业务的变化/增长，那么在我看来应该没有什么大问题。
总结做最简单的可行的事情，并确保利益相关者明白这不是一次性的事情。
【讨论】：
做最简单的解决方案。如果您现在创建“完整解决方案”，您很可能会错过一些重要的需求，或者浪费时间和金钱来添加不需要的功能。也就是说，设计您的解决方案，以便可以相当容易地修改部分。
作为一个实际示例，如果您使用 .NET 进行编码，请为每个“服务”创建一个接口和默认实现。尽可能针对界面编程。稍后，如果您需要中断服务，您将能够轻松地放入实现您的接口的 WCF 客户端。控制反转也可以帮助您。
【讨论】：
有机增长本身并不坏。只有做得不好的时候才不好。然而，话虽如此，我会展望未来 3 到 5 年，并对公司的计算需求和架构做出最佳估计。尝试从管理团队那里获得诚实和现实的信息，以作为您估算的依据。
【讨论】：