最近开始做一个CDK项目，想对你们如何构建它有看法。我说出了我的想法。
将有 2 个单独的包。
- 应用共享包
- SpecificApplicationCDKPackage(可以有很多这样的包)，这些将取决于ApplicationCommonsPackage
ApplicationCommonsPackage 将保存我们所有应用程序的所有通用逻辑(到目前为止已经想到了配置、通用构造、用于创建构造的工厂方法)
后者(SpecificApplicationCDKPackage)将保存构造的配置，并将使用ApplicationCommonsPackage中的工厂来创建东西。
您如何看待在 ApplicationCommonsPackage 中使用工厂模式？我面临的一个问题是，我无法为工厂公开具有通用方法的通用接口(或不能公开？原因是每个结构都需要非常特定类型的道具，我不能将它们概括为any或者这样会失去打字稿的美感。所以我的工厂里有像createLambda(scope: Stack, id: string, props: LambdaProps): Function这样的功能。我不太喜欢这种结构，我会喜欢将Function作为输入并从中确定道具类型的通用函数。类似于create<T>(scope: Stack, id: string, props: <U derived from T => some methodology to get this?>): T的东西，因此当我实际在 SpecificApplicationCDKPackage 中使用它时，我会像这样 -this.factory.create<Function>(this, 'SampleLambda', {})我得到 props 参数 ({}) 的所有编译时错误
在使用 aws-cdk 时，重要的是要记住我们如何将资源收集到Stack中。一旦您将资源放入 cdkStack中，然后映射到 CloudFormationStack，在初始生产部署后将其移动到不同的堆栈可能会更复杂。
确定两个资源是否应位于同一堆栈中的最佳方法是应用模块设计启发式方法。换句话说，如果资源在一个堆栈(模块)中比在不同的堆栈(模块)之间有更多的耦合，那就更好了。
例如，我们经常有一个数据库(例如RDS)和一些连接到它的服务。与数据库通信时，服务需要其主机名、用户名、密码，数据库需要在 AWS 安全组级别允许这样做。因此，服务和数据库之间的引用数量很高，它们应该位于单个模块 (CDKStack中)。
另一方面，如果我们有 2 个服务，它们通过 http 相互通信，那么一个服务可能只需要知道其他服务 DNS 名称。在这种情况下，这两种服务可能更适合住在不同的Stack中。
我们显然可以使用帮助程序库来帮助创建公共构造。但是，请务必记住，在 cdk 中构造的对象映射到 AWS 资源。部署 CDK 应用程序后，看似无辜的重构可能会导致资源在后续部署中被替换。