我在想我应该如何组织我的项目。构建项目的最佳方式是什么？
我们有一些项目（重新）在其他项目中使用。
我的意思是，我们的数据项目和模型的项目在一到许多其他项目使用。
我真的知道的是如何构建这种类型的项目，什么是最好的方式来命名呢？
在一个标准的3层应用程序，是想是这样的：
任何其他的想法？
在每个公司我的工作，他们得到了不同的方式来组织它，有一个比另一种更好？你使用哪一个，你更喜欢哪一个？为什么？
Thx！
对于数据层，我通常使用：
Company.ProjectName.Data（即AdventureWorks.OrderManager.Data）
对于业务层，我更喜欢像 “ObjectModel”（我已经使用“业务”或“业务逻辑”，但这是数据在对象/类中汇集到一起的领域，为什么不把它命名呢？）。
Company.ProjectName.ObjectModel（即AdventureWorks.OrderManager.ObjectModel）
对于UI，我想无论是普通的老 “UI” 或 “演示” ......
Company.ProjectName。演示（即AdventureWorks.OrderManager。演示）
那差不多就是我做的，除了香港专业教育学院有一对夫妇图书馆项目在哪里我试图把我所有的可重用代码。然后我的模型和DAL坐在这些图书馆的顶部，只是增加项目具体情况给他们
软件架构依赖于软件来构建的类型。如果你想进行内核编程，与进行应用程序开发相比，其他原则适用。当你要做物理模拟，天气预报软件，软件IDE或编译器时，还有另一个原则适用。
我假设你想要做应用程序开发。那么，你很可能会想要围绕你将要反映的领域设计你的软件。但即使如此，还是有很多选择。
欲了解更多关于这个主题的更多信息，我强烈建议您从Eric Evans和Applying Domain-Driven Design and Patterns从Jimmmy Nilsson读取Domain Driven Design。
我目前工作中的前端Web应用程序，有一个3层架构：
它有一个分层架构中，并在应用程序层中的层是：
这只是一个例子项目结构，最终结果将取决于应用程序的类型。您可以在my answer至this question的包装分部和命名策略中阅读更多内容。
您可以根据需要添加/交换/删除图层。例如，在SOA中，您可以在应用层或服务层之上分层Web服务层，以便ESB（企业服务总线）可以连接到您的应用程序或服务。如果任何这些都不可能或者看起来非常困难，那么您没有最佳的架构和设计。
在考虑项目的结构，并允许像上面的场景中，你希望你的模块和组件的一些重要属性是：
您可以通过设计低耦合度和高内聚度来实现此目的。通过按功能/抽象级别对模块进行分组来选择分层架构是一个好的开始。在每个层次中，进一步按功能进行分组也是有帮助的。让每个更具体的层只取决于更一般层的接口也会减少耦合。
大多数情况下，我使用微软模式推荐的分层体系结构&实践Application Architecture for .NET: Designing Applications and Services。 Document描述了实现它的体系结构和.NET技术。
