design-patterns - 用新技术重建初创公司代码库和架构

我知道这将是一个非常广泛的话题，但我已经到了一个点，我需要在这件事上迈出第一步。

去年年底，我开始在一家与金融服务相关的初创公司工作。它提供贷款和小额信贷服务，并计划整合数字钱包服务并增加多国业务。

在处理了支持和日常问题之后，我被分配开始重建完整的后端架构和代码库。已选择替换技术，我们将删除旧版本的 PHP 和 Laravel 代码，并开始使用 .NET Core 3.1 和 C# 语言。当然，这个想法是以渐进的方式实现的，主要是在使用 API 的客户端应用程序上替换小的功能单元。

当前的后端环境由 3 个 repos 组成：

我一直在使用已经建立的架构，所以这将是我第一次遇到这些重要的决定。目前，我读到的关于架构模式和设计模式的大量信息让我不知所措。我什至不知道从哪里开始。

除了已弃用的版本之外，我已经收集了一些关于当前堆栈存在哪些问题的信息。所以记住这一点很重要。

你会建议什么样的程序？我应该创建一些概念验证项目吗？我很难决定哪种模式、技术或库的最合适组合。

我作为开发人员的背景一直是 .NET 变体（+6 年经验），所以没有问题。但是例如，在洋葱/分层/清洁、垂直切片或微服务架构之间进行选择时，真的很难选择哪个更适合。Repository 或 CQRS 等设计模式也是如此。

我几乎没有使用 DDD 的经验（至少我知道有意识地使用它），也许这种业务是应用它的好机会。我决定开始阅读 Eric Evan 的书，但这将是一条漫长的道路。

如果需要更多信息，请告诉我。

我非常感谢您的知识和经验。

标签： design-patternsarchitecturebackendcodebase

就作为解决方案架构师处理任何新参与的广泛方法而言，此材料可能会有所帮助：https ://morphological.wordpress.com/2021/01/27/your-first-project-where-to-start/ 如果没有别的它会给你一些关于你的方法和大局的结构。

你需要专注于这个口头禅：“我们需要解决什么问题”。首先，让您专注于问题，而不是将技术放在首位。还要考虑你的问题是什么——优先考虑它们，并将大问题分解成更小更易于管理的问题。

一些稍微更具体的建议

开始捕获和定义架构——“页面架构”是一个很好的起点。
使用该方法，针对以下每个特定主题制作一组图表（并发展您的思维）：业务功能和功能（“业务”需要解决方案实际做什么）；逻辑系统和组件；数据; 一体化。
需要考虑的关键方面包括用户——他们是谁，他们在哪里？他们将如何使用该系统？这里的想法是开始确定您是否正在查看需要强大的 UI / API 分层的客户端-服务器架构或多客户端架构；您是否与许多第三方进行交互？等等
稍后，一旦事情在逻辑上开始成形，就开始引入部署和基础设施。
考虑所有这些并开始研究一些跨领域的问题，特别是：安全性；可观察性（记录、监控、警报、报告），因此您可以在操作上维护解决方案。
如果您不知道要使用哪种模式，那么请让事情尽可能简单。
牢记良好的设计原则，例如高内聚和松散耦合。
仔细考虑解决方案的哪些部分最好自己构建而不是使用现成的东西。这些决选项减少。

关于模式和技术选择的一般建议

选择能够完成工作的技术 -并且- 易于雇用。无论现在还是将来，寻找优秀的员工都将是一个持续的挑战，因此请尝试使用在可预见的未来可能会获得相对较好的开发人员/市场支持的技术。
通常，一个解决方案将有几个关键场景或驱动因素往往占主导地位。例如，如果您正在构建一个完全在线的服务，该服务旨在通过 API 使用，那么 API 和集成对于您的解决方案的成功至关重要，因此请优先考虑相关决策。
与前一点类似，在完成了一些初步分析和页面架构之后，确定您是否有任何特定的系统功能将变得非常重要和重要。进入该阵营的一个可能是异步消息传递——这可能会导致您考虑从一开始就采用某种工业事件系统。