我是来自c＃.net背景的node.js的新手。在.net中编码时，我习惯使用几种设计模式来组织我的代码，服务层，存储库等。当我需要添加跨越多个模型的逻辑时，我也可以使用这些服务。转到node.js并查看示例和示例代码等。我没有看到很多服务层，存储库等的使用情况。以下是一些推荐的做法：
1）代码组织和结构，特别是对于富有业务逻辑的应用程序？
2）如何处理跨越多个模型的逻辑？
3）什么是一些很好的教程和示例代码网站，它们展示了一些包含项目的良好项目和代码结构（1和（2）？
.net附带了许多推荐的方法，实践，模式和编码结构技术，这些技术实际上是非常好的建议。像www.asp.net等网站为这些建议提供了很好的文章等。
我无法找到审查node.js示例的一致方法。
答案 0 :(得分：2)
和我一样，我来自C＃/ .NET到Node.js，发现我认为在C＃中很好的做法在Node.js中不太有用。
域驱动设计（DDD）通常不在Node.js设置中讨论，因为DDD通常与面向对象设计相关联，而Javascript不是OO语言（即使Javascript具有基于原型的继承，很多OO模式只是不能很好地翻译为Javascript）。
相反，我们看到更多的微服务架构，我们将大型域分解为更小的，解耦的服务，这些服务可以很好地执行一个业务功能。 Node.js非常适合这些轻量级HTTP服务。
有趣的是，我发现在尝试使用微服务方法而不是DDD之后，我实际上发现它更容易实现，并且更容易将事物与适当的行分开。事实上，当我回到C＃时，我发现自己也在应用微服务方法。
就模式而言，抽象化持久性仍然是一个非常好的想法 - 类似于存储库模式的东西很好地从OO转换为Node.js.至于在哪里放置业务逻辑，我发现有时我需要在我的存储库上有一个“服务”或“应用程序”层，这样我就可以访问几个存储库来编译复杂的响应。有时你不需要那些额外的抽象，所以只需把它放在需要的地方 - 不要过于虔诚地拥有业务逻辑的层 - 这就是N层思考，它会导致很多不必要的代码被编写。在它们变得有用时添加抽象，而不是在需要时添加占位符 - 这是一种过早的优化。
当我们需要真正的高级业务逻辑时，我们可能需要协调几个微服务的操作。 Node.js也是你的朋友 - 你可以编写轻量级的编排服务，消耗掉ESB上的消息并对它们做出反应。