まず、なぜ層化必要があります
階層化アーキテクチャは、すべての建築の創始者である、層状の効果が孤立している、しかし、私たちは時々誤解を持っている、それは、層アセンブリとの関連で、それは一般的なソリューションでは、このような単純な3層システムであり、そこに3つのアセンブリプロジェクトになります：層としてXXUI.dll、XXBLL.dllとXXDAL.dll、その後、これら三つのアセンブリ、これは大きな、複雑なプロジェクトではありませんが、とき、それはこの方法であれば、その後、あなたのプログラムは、アセンブリが成長され、フォルダ数の増加に焦点を当てます。アセンブリの概念のうち、あなたのビジョンは、あなたが見つけるとき、ちょうど層と対応するアセンブリ、および、溶液のフォルダ、または対応するソリューション全体、あるいは層がシステムに対応していません。
階層化オブジェクトは、「高凝集と低カップリング」に順番にと思いました。
第二に、Microsoftの古典的な3層アーキテクチャ
.NETは、Microsoftの三層、3層アーキテクチャのいずれかがビジネス層インタフェース（ユーザインターフェイス層）、ビジネスロジック（ビジネスロジック層）、データアクセス層（データアクセス層）に分かれている知っています。下記に示すように、
各層の役割：
界面層（UI）：メイン表現WEBの方法は、それはまたのWinForm方法として表現することができ、ロジックは関係なく、どのように定義するかの、非常に強力かつ完璧な層とプレゼンテーション層を変更した場合、ロジック層は、サービスの提供を向上させることができます。主にユーザの要求を受け付け、データを返します。
ビジネスロジック層（BLL）：データ層は、これらのビルディングブロックの上に構築することであるビルディングブロック、ロジック層であれば、特定の問題の主な操作は、また、データ層、データのビジネスロジックの処理を理解するためにペアで動作させることができます。
データアクセス層（DAL）：論理処理を含むいかなるデータ層は存在しない主に参照するために、実際には、その機能がデータファイルの各個別の操作を完了するために主にあります。そして、あなたは他の操作が必要です。
ログは、などの著作権管理、技術的なアーキテクチャ上のデータベースの永続性、メッセージングサービスを、記録しますので、開発者の目には、階層ビジネス・システムのみが、いくつかは、分離することが可能な限り分離することができ、その後、それらを置きます組み合わせたもの、それはシステムレベルの役立つだろう、彼らは全体の業務システムを運びます。
3層アーキテクチャの典型的なトランザクションスクリプト論理構造で、BBLで複雑なビジネスは非常に複雑なビジネス無力を扱う、最初から最後まで、メソッド本体を記述！！！
すべての.NETプログラマーは、この古典的な3層アーキテクチャから推定されているステップバイステップで可能になりました。
三、DDD古典的な成層
DDD：ドメイン駆動設計
TDD：テスト駆動開発されます
POEAA：エンタープライズアプリケーションアーキテクチャ
DDDの核となるアイデアは、センターフィールドへの遷移のためのデータベース中心のモデルから問題の解決策の形で業務によって制御されます
以下のグラフはDDDの、彼は完全に解釈撃墜本の中で、古典的な階層私「モデル駆動型の設計と実用的な領域」です。
レイヤの概念：
プレゼンテーション層（プレゼンテーション層）：図中のユーザインタフェース層は、ユーザインタフェース層、データ表示及びユーザ入力を含みます。
アプリケーション層（アプリケーション層）：アプリケーション層は、ビジネス機能システムを定義し、技術の分野、これらの機能を実装するオブジェクト層を向けます。
FIELD層（ドメイン・レイヤー）：コア層は、すべてのビジネスロジックを実現しています。
インフラストラクチャ層（インフラストラクチャ層）：基本的なサービスに全体の業務システムを提供します。
層は、以下のコンパイル時の依存関係（これは非常に短い小発育図悪い）でクラスでした：
高レベルモジュールは、抽象に依存すべきどちらの基本モジュールに依存するべきではありません
要約は、詳細が抽象的に依存しなければならない、細部に依存すべきではありません。
四、ABP成層
祭りFirstABPソリューション：
ABP詳細な成層：
私たちは、上から下に意味のすべてを見て：
プレゼンテーション層
プレゼンテーション：
ビューモデル（Javascriptを）：=
ビュー（HTML / CSS）：=
ローカライズ、ナビゲーション、通知：多言語、メニュー、予告
ウェブ：
ウェブAPIコントローラ：WEBAPIインタフェース
MVCコントローラ、のOData：私は、ODataのが何であるかを知りません
アプリケーション層（アプリケーション）
アプリケーションサービス：アプリケーションサービス
DTO：データ転送オブジェクト
DTOマッパー：エンティティとDTOの間AutoMapperのマッピング
認証：パラメーターの検証
セッション：
監査ログ：監査ログ
应用层提供一些应用服务（Application Services）方法供展现层调用。一个应用服务方法接收一个DTO(数据传输对象)作为输入参数，使用这个输入参数执行特定的领域层操作，并根据需要可返回另一个DTO。在展现层到领域层之间，不应该接收或返回实体(Entity)对象，应该进行DTO映射。一个应用服务方法通常被认为是一个工作单元（Unit of Work）。用户输入参数的验证工作也应该在应用层实现。ABP提供了一个基础架构让我们很容易地实现输入参数有效性验证。建议使用一种像AutoMapper这样的工具来进行实体与DTO之间的映射。
领域层（Domain(Core)）
Entities:实体，领域对象，代表业务领域的数据和操作
value objects：实体模型
Repositories：仓储，用来操作数据库进行数据存取。仓储接口在领域层定义，而仓储的实现类应该写在基础设施层。
Domain Services：领域服务，当处理的业务规则跨越两个（及以上）实体时，应该写在领域服务方法里面。
Domain Event：领域事件，在领域层某些特定情况发生时可以触发领域事件，并且在相应地方捕获并处理它们。
Unit of Work：工作单元，一种设计模式，用于维护一个由已经被修改(如增加、删除和更新等)的业务对象组成的列表。它负责协调这些业务对象的持久化工作及并发问题。
基础设施（Infrastructure）
ORM (EntityFramework, NHibernate)：ORM框架，ABP提供了EF和NHibernate支持
DB Migrations：EF Code First创建数据库用的
Background Jobs：作业调度和自动任务，（类似Quartz.NET）
补充（单页面应用和多页面应用）
在单页面应用中（SPA）,所有的资源都会一次性加载到客户端（或者只加载核心资源，懒加载其他资源），所有的后续和服务器的交互都是通过Ajax调用。Html代码是使用从服务端接收到的数据在客户端生成的。整个页面不会刷新，视图只是在必要时换入换出。有许多的Javascript SPA框架，比如AngularJs，DurandalJs,BackboneJs和EmberJs。ABP可以使用它们中的任何一个，但是提供了使用 AngularJs和DurandalJs的样例。
在多页面（经典）应用中(MPA)，客户端向服务端发送请求，服务端代码（ASP.NET MVC 控制器）从数据库中获取数据，然后Razor视图引擎生成html 代码。这些编译后的页面发回给客户端显示。每个新的页面都会导致完整页面的刷新。
SPA和MPA涉及了完全不同的架构。对于后台管理系统来说，SPA是最好的候选者，另一方面，博客更适合MPA模型，因为博客渴望被搜索引擎抓取数据。虽然有很多工具可以使SPA对于搜索引擎可见，但是目前的一般做法就是使用MPA。
最后
ABP平衡了一些最好的框架或者类库，除此之外，ABP自己的类和系统也提供了一个很好的用于N层架构Web应用构建的基础设施，也提供了很轻松地创建分层的解决方案的模板，用作应用的起点。
根据分层我们把项目的类库用解决方案的文件夹整理下：
