来自不同团队的四位不同的首席工程师向我们提出了尖锐的问题……
他们正在仔细审查我为之做出重大贡献的软件设计。
今天，我想谈谈软件设计。你如何设计经得起高级工程师审问的系统？
你太拘谨了！
我正在写这个设计决定，因为我认为它对我的读者有用。
不幸的是，我不得不含糊其辞。
我不能公开分享我公司代码的详细信息。所以，你必须抽象地想象这个问题。
这真的很难做到。对不起。我希望我能分享更多细节。
但无论如何，我仍然希望这篇文章对您有所帮助！
一点背景
我们公司现有一项服务。
有用！但它不灵活。当其他人想要开始使用它时，我们不能很容易地扩展它来满足他们的需求。
它是为特定用途而编写的。该设计与我们最初理解的问题非常吻合。
但是，现在其他团队希望以不同的方式使用该服务。
服务的原始实现过于死板。它对如何使用它做了太多假设。某些属性和行为只对第一个调用者有效。
既然其他团队要用，我们就需要更灵活的设计。
设计讨论
我帮助做出了更灵活的设计。
但可怕的部分是捍卫该设计。
我们向我公司的一些顶级工程师展示了它。其团队将使用新设计的服务的人员。
对于扩展设计的方法，存在讨论、问题和建议。
来自整个公司的首席工程师深入研究了实施的细节。他们还询问了有关设计如何与其他团队交互以及所有权终止的高级问题。
会议结束时，一位首席工程师说：“很棒的工作。这回答了我所有的问题，而且看起来确实比我们以前的设计更具可扩展性。”
😀哇！终于解脱了！
是什么让它成为一个好的设计？
那么，我们做了什么？设计好的怎么样？
简而言之，这是我的要点：
- 保持简单——软件架构应该清晰易懂。如果你正在做一些超级复杂的事情，你可能犯了一个错误。
- 无副作用——设计的每个部分都应该做一件事并且把它做好。单一责任适用于软件设计！不要创建服务做不止一件事的架构。
- 减少未知数——我们设计的一部分要求调用服务在调用我们的服务之前预先创建一些相关对象。我们不想必须引导任何数据或对其他服务需要什么做出假设。相反，我们询问相关对象的 ID，并真正明确地了解服务将（和不会）采取什么行动。
- 发出事件——由于我们减少了未知数和副作用，调用服务需要对我们服务中的变化做出反应的方法。我们使用事件驱动架构将事件发送到消息队列。任何对该事件感兴趣的服务都可以订阅并决定要做什么。
这有用吗？
我喜欢分享这样的故事。但是很难说……
作为读者，您觉得这篇文章有用吗？它是否太模糊而没有意义？
日常文章
你有问题要问我吗？可以在评论区留言！
如果你喜欢我的文章，点赞，关注，转发！
