这几乎就是我所做的，除了我有几个库项目，我试图在其中放置所有可重用代码。 然后我的模型和 DAL 位于这些库的顶部，只需向它们添加项目细节即可。
That's pretty much what I do, except I've got a couple of library projects where I try to put all my reusable code. Then my Model and DAL sit on top of these libraries, just adding project specifics to them.
For business layer I prefer something like "ObjectModel" (I have used "Business" or "BusinessLogic" but this is the area where data comes together in objects/classes so why not name it so?).
为了对这个大主题有更多的了解，我强烈建议阅读来自 Eric Evans 的领域驱动设计和来自 应用领域驱动设计和模式代码>吉米·尼尔森。
The software architecture depends on the type of software to build. If you want to do kernel programming other principles apply compared to doing application development. Yet another principles apply when your are going to do physical simulation, weather-forecast software, software IDE's or compilers.
I assume you want to do application developement. Well, then you will most probably want to design your software around the domain you are going to reflect. But even then there are lots of options.
For more insight in this big topic, I strongly suggest to read Domain Driven Design from Eric Evans and Applying Domain-Driven Design and Patterns from Jimmmy Nilsson.
I'm currently working on front-end web application that has a 3-tiered architecture:
Client tier (the browser)
Application tier (Java EE application server, where the application will live)
Backend tier (mainframe and legacy apps, various databases)
It has a layered architecture, and the layers in the Application tier are:
Presentation layer: generates the UI that will be used in the Client tier
Application layer: the equivalent of use cases, contains application logic
Service layer: maps domain logic and data from Backend tier onto a Java model
Integration layer: communicates with the Backend tier and contains gateways for JMS, email, ... and DAOs and other stuff
This is just an example project structure, and the end result will depend on the type of application. You can read more in my answer to this question on the division and naming strategy for packages.
You can add/swap/remove layers as you see fit. In a SOA for example, you can layer a Webservice layer on top of the Application layer or Service layer, so that the ESB (Enterprise Service Bus) can connect to your application or services. If any of this is impossible or seems very difficult, you don't have an optimal architecture and design.
When thinking about the structure of your project and to allow scenarios like the one above, some important properties of your modules and components you want are:
Testability
Reusability
Maintainability
You can achieve this by designing for low coupling and high cohesion. Choosing a layered architecture by grouping modules by the level of functionality/abstraction is a good start. Within each layer grouping further by functionality helps as well. Letting each more specific layer only depend on interfaces of a more general layer reduces coupling too.
发布评论
评论（5）
这几乎就是我所做的，除了我有几个库项目，我试图在其中放置所有可重用代码。 然后我的模型和 DAL 位于这些库的顶部，只需向它们添加项目细节即可。
That's pretty much what I do, except I've got a couple of library projects where I try to put all my reusable code. Then my Model and DAL sit on top of these libraries, just adding project specifics to them.
对于数据层，我通常使用：
Company.ProjectName.Data （即 AdventureWorks.OrderManager.Data）
对于业务层，我更喜欢“ObjectModel”（我使用过“Business”或“BusinessLogic”）但这是数据在对象/类中聚集在一起的区域，所以为什么不这么命名呢？）。
Company.ProjectName.ObjectModel（即 AdventureWorks.OrderManager.ObjectModel）
对于 UI，我喜欢普通的旧“UI”或“演示文稿”...
Company.ProjectName.Presentation （即 AdventureWorks.OrderManager.Presentation）
For the data layer, I usually use:
Company.ProjectName.Data (i.e. AdventureWorks.OrderManager.Data)
For business layer I prefer something like "ObjectModel" (I have used "Business" or "BusinessLogic" but this is the area where data comes together in objects/classes so why not name it so?).
Company.ProjectName.ObjectModel (i.e. AdventureWorks.OrderManager.ObjectModel)
For UI, I like either plain old "UI" or "Presentation"...
Company.ProjectName.Presentation (i.e. AdventureWorks.OrderManager.Presentation)
我主要使用 Microsoft Patterns & 中推荐的分层架构。 实践.NET 应用程序架构：设计应用程序和服务。 文档描述了实现它的体系结构和.NET 技术。
Mostly I use layered architecture as recommended in Microsoft Patterns & Practices Application Architecture for .NET: Designing Applications and Services. Document describes the architecture and .NET technologies to implement it.
软件架构取决于要构建的软件类型。 如果您想做内核编程，则与应用程序开发相比，其他原则也适用。 当您要进行物理模拟、天气预报软件、软件 IDE 或编译器时，还适用另一个原则。
我假设您想做应用程序开发。 好吧，那么您很可能希望围绕您要反映的领域来设计您的软件。 但即便如此，仍有很多选择。
为了对这个大主题有更多的了解，我强烈建议阅读来自
Eric Evans的领域驱动设计和来自应用领域驱动设计和模式代码>吉米·尼尔森。The software architecture depends on the type of software to build. If you want to do kernel programming other principles apply compared to doing application development. Yet another principles apply when your are going to do physical simulation, weather-forecast software, software IDE's or compilers.
I assume you want to do application developement. Well, then you will most probably want to design your software around the domain you are going to reflect. But even then there are lots of options.
For more insight in this big topic, I strongly suggest to read
Domain Driven DesignfromEric EvansandApplying Domain-Driven Design and PatternsfromJimmmy Nilsson.我目前正在开发具有 3 层架构的前端 Web 应用程序：
它具有分层架构，应用程序层中的各层为：
这只是一个示例项目结构，最终结果将取决于应用程序的类型。 您可以在 我对这个问题关于包的划分和命名策略。
您可以根据需要添加/交换/删除图层。 例如，在 SOA 中，您可以在应用程序层或服务层之上放置一个 Web 服务层，以便 ESB（企业服务总线）可以连接到您的应用程序或服务。 如果其中任何一个是不可能的或看起来非常困难，那么您就没有最佳的架构和设计。
在考虑项目结构并允许上述场景时，您想要的模块和组件的一些重要属性是：
您可以通过低耦合和高内聚的设计来实现这一目标。 通过按功能/抽象级别对模块进行分组来选择分层架构是一个好的开始。 在每一层中，按功能进一步分组也有帮助。 让每个更具体的层仅依赖于更通用层的接口也可以减少耦合。
I'm currently working on front-end web application that has a 3-tiered architecture:
It has a layered architecture, and the layers in the Application tier are:
This is just an example project structure, and the end result will depend on the type of application. You can read more in my answer to this question on the division and naming strategy for packages.
You can add/swap/remove layers as you see fit. In a SOA for example, you can layer a Webservice layer on top of the Application layer or Service layer, so that the ESB (Enterprise Service Bus) can connect to your application or services. If any of this is impossible or seems very difficult, you don't have an optimal architecture and design.
When thinking about the structure of your project and to allow scenarios like the one above, some important properties of your modules and components you want are:
You can achieve this by designing for low coupling and high cohesion. Choosing a layered architecture by grouping modules by the level of functionality/abstraction is a good start. Within each layer grouping further by functionality helps as well. Letting each more specific layer only depend on interfaces of a more general layer reduces coupling too.