ビジネス技術アーキテクチャ
アーキテクチャの実装
ゲートウェイ層
もちろん、HTTPなどのゲートウェイ層プロトコルの性質上の異なるネットワークプロトコル、TCPプロトコルの処理要求であり、他のプロトコルを処理することができます。具体的には以下に示します：
1.HTTP要求
PC側とAPPからの一般的な要求が要求するプログラムHTTPを処理するためのHTTPプロトコルに基づいており、業界ではすでに非常に成熟しています。まず、パッケージ外の複雑さを処理容器自体TomcatのHTTPリクエスト、
第二に、スプリングMVC要求プロセスはRESTfulな符号化を提供大幅開発の複雑さを低減します。私たちが行うすべては、このような大面積、この分野で動作している様々な方法を分割するため、会員に従いなどのビジネス分野の区分に従い、コントローラのためです。
ここで、ゲートウェイ・コントローラは、均一な処理層であり、唯一の三つの方法は、まず、要求は、パラメータの内部パラメータに解析され、組み立てられ、サービス実行の基礎となるビジネス・ロジックへの第2の呼、各コントローラは、第三のアセンブリの結果を返し、
異常な状況、例外スタックは、エラーコードをログに記録し記録し、変換する必要の場合は、呼び出し側にスタック情報を公開しません。
2.TCP要求
TCP要求処理プログラムでは、業界でも非常なネッティーとして、成熟してきました。しかし、根本的なTCP要求は、すべての後、あまりにも、私たちは、TCPプロトコルに基づいて、独自のプロトコルを開発する傾向があります。加えて、多くの分散フレームワークは、TCPプロトコルに基づいて、
例えば、RPCフレームダボ、等メッセージフレームRocketMQため。スタンドアロンシステムから分散システムに、マルチレイヤゲートウェイは、論理的な処理TCP要求以外の何ものでもありません、理論的には、基礎となるビジネスは、スタンドアロン環境または分散環境のために、最終的に自分自身を知覚する必要はありません
シールド層へのゲートウェイは、外部ソースの異なるコールの詳細です。ダボサーバでは、我々は、最初にすべてのパラメータおよび内部パラメータの組み立てを解析することで、内部転送ロジックを転送するリモートインタフェースとリモートサービスコールは非常に簡単です実装する必要があります
サービス層を呼び出し、最終的なアセンブリが結果を返すインタフェースを行うサービスロジックは、次に、例外処理は、外部アプリケーションへの異常な曝露を防止するために、ここに行うことが要求されます。
要約：
本質的に処理されたゲートウェイ・プロトコル層は、同時に、内部ビジネス・ロジックは、外部発信者を再構築するとき、これらの変更を認識する必要がなく、外部に露出していない、ビジネスロジック層ゲートウェイに収束します
場合は、外部コール元増加し、内部サービス・ロジックは、内部および外部の発信者ビジネスロジックはデカップリングだから、この認識を変更する必要はありません。
II。ビジネスレイヤ
ビジネス層は、ビジネス・プロセスおよびルールを搬送しているローカルビジネスシステム、ビジネスレイヤ単一のシステム又は分散システムのグループであるかどうかを、システムです。
外部からの3つの層を含む内部層へのサービス：サービス事業、ビジネス・プロセスが第二層であり、第3の層は、ビジネス・コンポーネントです。図は次のとおりです。
1.ビジネスサービス
ビジネスインタフェース、上院およびパラメータ：ビジネスは、3つのエリアで構成され、均一外部ファサードのビジネス・サービス層です。
a）のサービス・インタフェース
サービス・インターフェースは、このようなビジネス・サービスのオーダードメインなどのビジネスサービスの一つの領域を表し、インターフェースOrderServiceのは、事業ドメインサービスのメンバーは、インターフェースMemberServiceで表現されると言います。
インタフェースは、OrderReadServiceとOrderWriteServiceとして、界面の性質に応じて、実行する読み出しおよび書き込みインタフェースに分けることができます。リーディング、ライティングのメリットの分離を読んで、トラフィックを管理するために、クラスタグループに書き込むことができ、もちろん、読み取りと書き込みの別々のスタンドアロンシステムは、あまり重要ではありません。
そのような単一ドメインのようなフィールドサービスインターフェース動作場所の形で具現方法はcreateOrder注文、注文をキャンセルし、等cancelOrder動作を有しています。
これらの操作のために、方法はできるだけCRUD、いくつかの簡単なビジネスのために、当然のことながら、むしろCRUDよりも、ビジネス上の意味を持って工夫してみてください。
b）のパラメータ
次に、リファレンスデザインです。基準方法に読み込むための比較的単純な、議論されていません。書き込み方法については、我々は、参照レベルのデータモデルを設計しました。
あなた、このような注文データモデル、ビジネスデータモデル、データモデルや他の商品、その後、文字データ、データモデルにおける及び特定の企業結合として、共通データモデルを設計する最初の必要性、Requestオブジェクトの構成、
異なる動作におけるサービス要求オブジェクトは、対応する結果が、異なるサービスに対して異なるパラメータで戻される応答を返され、異なります。
例えば：
拿下餐饮订单来说，首先，我们应该识别出这些业务流程中一些比较基础的数据模型，比如餐饮领域的菜品、桌位等，这些模型之所以说是基础模型，
是因为，不管下什么餐饮订单，菜品和桌位肯定是逃不了的，它们是可以被复用的！因此，我们分别为这些基础模型设计相对于的DO（Domian Object）:DishDO（菜品）、BoardDO（桌位）等等，
接下来，我们为下餐饮订单设计一个请求对象DishOrderCreateRequest其中DishOrderCreateRequest内部包含了DishDO和BoardDO，另外会包含一些特定的属性，比如人数啊，折扣啊等等，
这样一来就能做到通用和灵活兼顾，DishOrderCreateRequest代表的个性化的灵活的业务入参，而DishDO和BoardDO等则代表了不易变化的基础模型。
c) 出参
最后，是出参的设计。对于写方法，一般出参比较简单。对于读方法，出参往往是一个结构与层次比较复杂的组合对象。
比如查询一个订单，这个订单有订单基本信息，还有商品信息，收货人地址信息等。在设计出参的时候，结构上要设计成组合对象，但是真正查询的时候，通过查询选择器，去查询不同的组合对象。
比如查询选择器设置商品查询为true，地址查询为false，那么这次查询出的订单就只包含商品，而不包含地址。
2.业务流程
业务流程其实就是对业务规则的解释，只是这种解释使用代码去实现的，我们要做的其实就是准确翻译这些业务规则，并维护好这些业务规则。
业务流程中可以大致分为三种动作节点，1、组装参数节点；2、规则判断节点；3、执行动作节点；其中每个动作节点都是一些业务代码的片段。
举个例子：
下餐饮订单，我们第一步就是将上层传入的参数组装出一个基础的DishOrderDO（组装参数节点），然后按照特定的规则去填充这个DishOrderDO（规则判断节点），然后就是调用DAO去创建DishOrderDO（执行动作节点）。
业务流程是最容易变化的地方，要想维护好业务流程并不容易，总的思想是将大的业务流程拆分成小的业务流程，抽出每个业务流程中共有的代码片段，变成可维护的业务组件。
3.业务组件
a) 基础组件
业务组件其实是将一些内聚的可复用的代码片段进行封装。和业务流程中的三种业务节点相对应，业务组件也分为三种：组装参数组件 、规则判断组件 、动作执行业务组件。
业务组件的抽象往往是对业务有了深刻理解之后才进行的，盲目地进行业务组件的抽象，往往到头来白忙活。
b) 能力
对业务组件进行进一步抽象，可以得到能力。业务能力是具有一定复用性的组件的组合，比如发短信能力=组装短信参数组件+发短信组件。对于发短信能力，可以被不同的业务流程复用，
比如订单下单成功发短信，支付成功发短信，逻辑都是相似的，只有内容不同。
能力是一种粒度比较大的组件，粒度越大，往往复用性就越小，对能力的抽取，也是基于对特定业务深刻的理解，没有一劳永逸的银弹。
c)更高纬度的抽象
对于互联网这样的需求变化极快的场景，更高纬度的组件抽象往往性价比很低，不建议大家去做。
三.基础层
基础层包含两个部分，第一是接口定义，第二是技术组件。
1.接口定义
接口定义是按照不同的技术框架，同时结合业务需要，设计出合理的接口，对于业务组件来说，它们只会感知技术接口，而不会去感知技术实现，我们也不应该将具体的技术细节向上暴露，
这也就是所谓的面向接口编程。技术接口往往是业务与技术之间的桥梁，接口本身是含有业务含义的，最常见的就是DAO接口，我们设计DAO接口的时候，
不会设计成insert、update、query这样业务无关的接口，而是设计成insertUser，updateUserById等等和业务相关的接口，
同样的道理，设计缓存接口的时候，也不能设计成put、get这样的接口，而应该设计成cacheUser，deprecateUser这样的接口。
2.技术组件
单机系统的技术组件一般来说分两种，一种是通用的技术组件，比如：数据存储、缓存、消息和调度任务、事务、锁。一种是基础设施，比如spring容器，tomcat容器。
下面稍微谈谈通用技术组件。
数据存储：数据存储包括关系型数据库、非关系型数据库以及文件存储系统。关系型数据库，比如MySQL，适合存放绝大部分业务数据。非关系型数据库，
比如hbase，可以存放历史日志，也可以对历史的MySQL数据进行归档。文件存储系统，一般都是基于Linux文件系统，比如图片、html文件等等，也有基于HDFS的，用于大数据分析。
缓存：缓存按响应时间分，可以分为纳秒级缓存，毫秒级缓存和百毫秒级缓存。纳秒级缓存就是一般的基于本地内存的缓存，
比如encache，毫秒级缓存一般是集中式的内存缓存，比如memcache，由于访问时远程调用，因此响应时间会延长到几毫秒，百毫秒级缓存一般是集中式可持久化的缓存，
比如redis，由于存在远程访问以及缓存击穿导致的读取持久化记录，它的响应时间会更长些，到几十甚至上百毫秒。单机系统一般用本地内存缓存就够了，当缓存被击穿的时候，直接访问数据库。
消息和调度任务：消息和调度任务本质都是一种异步化的手段，区别在于消息无法控制异步的时间，而调度任务可以。一般，消息发送出去后，监听消息的系统会立即收到消息，
从而立即触发业务逻辑的执行，而调度任务则会按照调度规则，一次或者多次的执行业务逻辑。单机系统中消息和调度任务用到的比较少，在做日志监控的时候可能会用到消息，在进行数据报表统计的时候可能会用到调度任务。
事务：事务本质都是基于数据库去实现的，单机系统的事务就是依赖数据库的事务，我们可以使用spring-tx的事务模板进行事务操作，
在业务逻辑开发中，一定要把握事务的大小，建议把业务比较紧密的一堆数据库操作放在一个事务里，不要随意的为每个方法都开启事务。
锁：单机系统中主要用到两种锁：乐观锁和悲观锁。乐观锁依靠在数据库的业务表加版本字段来实现，每次更新都会去判断版本是否变化，
如果变化则需要重试，这种锁的粒度比较小。悲观锁是基于JDK的Lock接口的，对一个业务流程进行加锁和释放锁的操作，锁的粒度比较粗。