刚才有个朋友问我，博主发生什么事了，给我发了几张截图，我一看，哦，原来是有个大帅哔看了文章，说是，博主，我能白嫖你的文章，我说年轻人，点个赞再走，他说不点，我说点一个，他说不点，我说点一个，他说不点，我说我这文章对你有用，他不服气，说要先看看。我说可以，很快啊，看完后，就是一个复制，一个粘贴，一个网页关闭，我大意了啊，没有删除文章。按传统博客的有用为止，他说已经输了啊。 后来他说他是乱点的，这可不是乱点的啊，训练有素。我劝年轻人好好点赞，耗子尾汁，谢谢朋友们
转载请标明出处：http://blog.csdn.net/xx326664162/article/details/53406933    文章出自：薛瑄的博客
所谓系统程序就是system/app目录中的程序，普通应用转换成系统程序后有稳定、减少内存（DATA）空间占用、恢复出厂设置后不会消失、修改系统时间、调用隐藏方法、系统关机重启、静默安装升级卸载应用等等等等优点，想知道怎么操作？接下来我们介绍三种方法。
#第一种：使用ADB命令将app安装在system/app目录下
参考：android 将自己的应用改为系统应用
##这种方法的原理就是：

1、把apk文件移动到system/app目录，

2、.so文件移动到system/lib目录。

3、修改相应的权限
##操作步骤：
1.     将你的手机数据线，插上，把你的设备设置为允许usb调试
2.     打开命令终端cmd
3.     输入命令        adb shell
4.     确定能进入系统

5.  输入命令 mount

6.   因为system默认是只读文件夹，所以根据上面的提示输入下面命令，使其变为可读写
mount  -o  remount  /dev/block/nandd /system   （图）

再出输入 mount 查看system和上面的不一样了，说明正确

7.     输入 exit 退出android系统终端
8.  解压你的apk文件，进入查看lib/armeabi文件夹下有没有 .so文件，如果没有这种库文件的话，直接跳到第10步，（因为有些apk文件是要调用动态链接库的，你不拷贝的话，就没有办法运行！会报错）如果有的话， 将这些.so文件都拷贝到/system/lib文件夹下：*
命令：adb push libiReader_txtparser.so system/lib

9、拷贝完了之后呢，要给这些库文件添加权限，看看别的库文件权限是几
chmod   644  xxxxx.so


10.  将你的apk文件拷贝进入/system/app（该文件夹里存放着所以系统级别的apk），图中我是将iReader.apk拷贝过去的

11.  再次进入android终端  adb shell
12.  进入system/app文件夹   cd system/app
13.  查看其他apk的权限   ll   能看出区别

14.  修改iReader.apk权限使其和其他的一样 chmod 644 iReader.apk

15.  搞定这些之后，重启设备 reboot
16.  看看系统里面是不是安装好了该应用，点击一下，看是否正常运行，可以的话，再检测是否无法卸载！
#第二种：借助工具把app转为系统应用（原理和方法一一样）
转载：安卓进阶教程：怎样把应用转换成系统程序
RE管理器转换和LINK2SD都可以实现，任选其一即可
##使用RE管理器转换
1、首先我们把需要转换的程序在电脑上用压缩软件打开 ，看有没有lib这个目录。如果有，再把lib目录打开，直到出现以.so结尾的文件，把文件都拖出来备用。

2、把需要转换的应用（apk文件）连同刚拖出的.so文件（如果有），放到手机内存卡，

3、用RE管理器复制到system目录，把权限更改如图，

4、把更改权限后的apk文件移动到system/app目录，.so文件移动到system/lib目录。

5、完成后重启手机，应用就转换成系统程序了。
##使用LINK2SD转换

如果感觉以上方法麻烦，也可借助工具来操作，LINK2SD、钛备份等软件都可以把普通程序转换为系统程序，以LINK2SD为例，打开LINK2SD，找到需要软件的程序，点击，再点操作，选择转换系统应用，接着会有个确认窗口，确认后，重启手机程序就转换好了。
#第三种：使用signapk打包成系统应用
参考：
android之使用signapk打包成系统应用，获取系统权限
使用platform密钥来给apk文件签名的命令
Android安全开发之通用签名风险
关于android:sharedUserId="android.uid.system"这个系统级权限
安装APK 时, 提示" 共享用户权限不完整" , 不能安装成功, 如何解决?

https://github.com/android/platform_build/tree/master/target/product/security
为了更好地理解下面介绍的两种方法的原理，先来学习几个概念：
##Android应用签名机制

Android系统要求安装的应用必须用数字证书进行签名后才能安装，并且签名证书的私钥由应用开发者保存。签名证书的生成也由开发者自己生成。在应用安装时会校验包名（package name）和签名，如果系统中已经存在了一个相同的包名和签名的应用，将会用新安装的应用替换旧的；如果包名相同但是签名不同，则会安装失败。
为什么需要数字签名？
数字签名是防止要保护的内容被篡改，用非对称加密算法。先对要保护的内容进行消息摘要，用私钥对消息摘要进行加密，生成数字签名，将数字签名和要保护的内容一起分发出去。 内容接收者用公钥对数字签名解密得到发送者给的消息摘要A，内容接收者对接收到的内容进行用相同的消息摘要算法处理得到消息摘要B，对比A和B是否相同，来判定传送的内容是否被篡改。 正常的APK文件是个ZIP压缩文件，除了应用的可执行文件、资源文件，还包括这些可执行文件、资源文件的摘要信息，数字证书的公钥信息等。并且通过这些签名信息可以确定APP和其开发者的关系。
进行签名需要的工具有哪些？
对apk进行签名需要用到签名证书和签名工具。Android系统要求对APP进行签名的数字证书可以由开发者自己生成。签名工具有jarsigner和signapk。jarsigner是Java本身自带的一个工具，他也可以对jar进行签名的；而signapk是专门为了Android应用程序apk进行签名的工具。二者的区别是：jarsigner工具签名时使用的是keystore签名文件，signapk工具签名时使用的是pk8，x509.pem文件。
签名后的文件都有哪些？
应用签名完后在应用的META-INF目录下会有三个文件：
CERT.RSA、CERT.SF和MANIFEST.MF。
MANIFEST.MF中保存了所有其他文件的SHA1摘要并base64编码后的值。
CERT.SF文件 是对MANIFEST.MF文件中的每项中的每行加上“rn”后，再次SHA1摘要并base64编码后的值（这是为了防止通过篡改文件和其在MANIFEST.MF中对应的SHA1摘要值来篡改APK，要对MANIFEST的内容再进行一次数字摘要）。
CERT.RSA 文件：包含了签名证书的公钥信息和发布机构信息。
对安装包的校验过程在源码的frameworks/base/core/java/android/content/pm/PackageParser.java类中可以看到
什么是通用签名？
搭建好Android开发环境后（使用Eclipse或Android Studio），对APK签名的默认密钥存在debug.keystore文件中。在linux和Mac上debug.keystore文件位置是在**~/.android路径下，在windows目录下文件位置是C:\user\用户名.android**路径下。
除了debug.keystore外，在AOSP发布的Android源码中，还有以下几个证书是公开的，任何人都可以获取，在源码的build/target/product/security目录中：

这几个证书的作用：
testkey
Generic default key for packages that do not otherwise specify a key.
platform
Test key for packages that are part of the core platform.
shared
Test key for things that are shared in the home/contacts process.
media
Test key for packages that are part of the media/download system.
verity
Test Key for verifiedboot system imagein Android Lollipop. Sign boot.img,sign verity metadata in system.img.
通用签名风险：
（1）如果攻击者的应用包名与目标应用相同，又使用了相同的密钥对应用进行签名，攻击者的应用就可以替换掉目标应用；
（2）另外目标应用的自定义权限android:protectionlevel为“signature”或者“signatureOrSystem”时，保护就形同虚设；
（3）如果设备使用的是第三方ROM，而第三方ROM的系统也是用AOSP默认的签名，那么使用如果使用系统级签名文件签名过的应用，权限就得到了提升。
##具体的实现方法：
###第一种是需要在Android系统源码的环境下用make来编译：
在应用程序的AndroidManifest.xml中的manifest节点中加入android:sharedUserId="android.uid.system"这个属性。
修改Android.mk文件，加入LOCAL_CERTIFICATE := platform这一行
使用mm命令来编译，生成的apk就有修改系统时间的权限了。
###第二种：
下面着重介绍一个这个方法：
1. 加入android:sharedUserId="android.uid.system"这个属性。
<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
          package="com.example.jant.addview"
          android:sharedUserId="android.uid.system" >
    <application
       ...（省略若干代码）
    </application>

</manifest>

2. 使用自己的签名文件，生成apk
3. 使用通用签名来重新给apk文件签名。
3.1 .准备好platform.pk8、platform.x509.pem和签名工具signapk.jar（3个文件的下载地址），还有自己的apk，放在同一个文件夹下。
3.2  在cmd下进入到该文件夹后，使用如下命令：

3.3 回车后我们的文件夹下已经多了一个new.apk文件了，这就将我们的应用打包成系统应用
你也可以在github中去下载，但是下载的是SignApk.java，需要进行一些处理，如下
1.1.进入\build\target\product\security,找到【platform.pk8】和【platform.x509.pem】系统密钥。

1.2.进入\build\tools\signapk找到SignApk.java，运行 javac编译成SignApk.class

1.3.执行命令java com.android.signapk.SignApk platform.x509.pem platform.pk8 input.apk output.apk
##最后解释一下原理

首先加入android:sharedUserId="android.uid.system"这个属性。通过Shared User id,拥有同一个User id的多个APK可以配置成运行在同一个进程中。那么把程序的UID配成android.uid.system，也就是要让程序运行在系统进程中，也就是系统应用。
只是加入UID还不够，如果这时候安装APK的话发现无法安装，提示签名不符，原因是程序想要运行在系统进程中还要有目标系统的platform key，就是上面第二个方法提到的platform.pk8和platform.x509.pem两个文件。用这两个key签名后apk才真正可以放入系统进程中。第一个方法中加入LOCAL_CERTIFICATE := platform其实就是用这两个key来签名。
这也有一个问题，就是这样生成的程序只有在原始的Android系统或者是自己编译的系统中才可以用，因为这样的系统才可以拿到platform.pk8和platform.x509.pem两个文件。要是别家公司做的Android上连安装都安装不了。试试原始的Android中的key来签名，程序在模拟器上运行OK，不过放到小米四上安装uibl，如下图，这样也是保护了系统的安全。

  最后还说下，这个android:sharedUserId属性不只可以把apk放到系统进程中，也可以配置多个APK运行在一个进程中，这样可以共享数据，应该会很有用的。

你在Manifest.xml里声明使用了shareuserid 或者一些特殊permission，比如你shareuserid到uid.system，就必须使用系统platform签名来签你的apk，否则是不能安装的，同理share到其他用户id或者其他process上也是得用跟那个process运行的apk一样的签名

一般签名肯定是厂商私有的，你肯定是没办法了，除非机器烧的是开发版本(eng)
#检验app是否已经是系统应用
查看应用的进程属性，如果是system用户组，说明已经是系统应用。


关注我的公众号，轻松了解和学习更多技术

目录

领域驱动实践总结二:架构分析与代码设计

一、微服务架构模型的对比与选择

（一）整洁架构

（二）六边形架构

（三）DDD 分层架构

1.用户接口层

2.应用层

3.领域层

4.基础层

5.从三层架构向 DDD 分层架构演进

（四）三种微服务架构模型的对比和分析

二、领域驱动设计分层架构与微服务代码模型

（一）代码模型总目录结构

1.微服务一级目录结构

2.用户接口层目录结构、职能和代码形态

3.应用层目录结构、职能和代码形态

4.领域层目录结构、职能和代码形态

5.基础层层目录结构、职能和代码形态

（二）应用层的领域对象分析

1.实体方法的封装

2.领域服务的组合和封装

3.应用服务的组合和编排

（三）领域层的领域对象分析

1.设计实体

2.找出聚合根

3.设计值对象

4.设计领域事件

5.设计领域服务

6.设计仓储

（四）代码模型强调内容

第一点：聚合之间的代码边界一定要清晰。

第二点：你一定要有代码分层的概念。

三、正确理解微服务的边界

（一）逻辑边界

（二）物理边界

（三）代码边界

四、正确认识服务和数据在微服务各层的协作

（一）正确认识服务的协作

1. 服务的类型

2. 服务的调用（三类主要场景）

微服务内跨层服务调用

微服务之间的服务调用

领域事件驱动

3. 服务的封装与组合

（二）正确认识服务数据的协作

1.基础层数据协作

2.领域层数据协作

3.应用层数据协作

4.用户接口层数据协作

5.前端应用数据协作

参考书籍、文献和资料

领域驱动实践总结二:架构分析与代码设计

领域驱动设计DDD是一种设计思想，它可以同时指导中台业务建模和微服务设计(中台本质是业务模型，微服务是业务模型的系统落地)，领域驱动设计强调领域模型和微服务设计的一体性，先有领域模型然后才有微服务，而不是脱离领域模型来谈微服务设计。

微服务拆分困境产生的根本原因:不知道业务或者微服务的边界到底在什么地方。

DDD 核心思想:通过领域驱动设计方法定义领域模型，从而确定业务和应用边界，保证业务模型与代码模型的一致性。

对于领域驱动设计的学习做的总结主要写三篇博客，主要包括三部分:基本理论总结与分析、架构分析与代码设计、具体应用设计分析，主要参考的资料为极客时间的欧创新架构师的《DDD》实战，其他参考书籍在文章下方的参考书籍中。

本次主要总结DDD架构分析与代码设计：

一、微服务架构模型的对比与选择

微服务架构模型现有的选择模型包括：整洁架构、CQRS 和六边形架构、DDD 分层架构等。

（注：CQRS架构之前博客中有讲，本次不做分析）

每种架构模式虽然提出的时代和背景不同，但其核心理念都是为了设计出“高内聚低耦合”的架构，轻松实现架构演进。

DDD 分层架构的思想使架构边界变得越来越清晰，它在微服务架构模型中，占有非常重要的位置。建议选择DDD 分层架构。

（一）整洁架构



在整洁架构里，同心圆代表应用软件的不同部分，从里到外依次是领域模型、领域服务、应用服务和最外围的容易变化的内容，比如用户界面和基础设施。

整洁架构最主要的原则是依赖原则，它定义了各层的依赖关系，越往里依赖越低，代码级别越高，越是核心能力。外圆代码依赖只能指向内圆，内圆不需要知道外圆的任何情况。

（二）六边形架构



六边形架构的核心理念是：应用是通过端口与外部进行交互的。

也就是说，在下图的六边形架构中，红圈内的核心业务逻辑（应用程序和领域模型）与外部资源（包括 APP、Web 应用以及数据库资源等）完全隔离，仅通过适配器进行交互。它解决了业务逻辑与用户界面的代码交错问题，很好地实现了前后端分离。

六边形架构各层的依赖关系与整洁架构一样，都是由外向内依赖。

六边形架构的一个端口可能对应多个外部系统，不同的外部系统也可能会使用不同的适配器，由适配器负责协议转换。这就使得应用程序能够以一致的方式被用户、程序、自动化测试和批处理脚本使用。

（三）DDD 分层架构

从上到下依次是：用户接口层、应用层、领域层和基础层。



1.用户接口层

用户接口层负责向用户显示信息和解释用户指令。

这里的用户可能是：用户、程序、自动化测试和批处理脚本等等。

2.应用层

应用层是很薄的一层，理论上不应该有业务规则或逻辑，主要面向用例和流程相关的操作。

位于领域层之上，领域层包含多个聚合，所以它可以协调多个聚合的服务和领域对象完成服务编排和组合，协作完成业务操作。

应用层也是微服务之间交互的通道，它可以调用其它微服务的应用服务，完成微服务之间的服务组合和编排。

注意：

在设计和开发时，不要将本该放在领域层的业务逻辑放到应用层中实现。因为庞大的应用层会使领域模型失焦，时间一长你的微服务就会演化为传统的三层架构，业务逻辑会变得混乱。
	
应用服务是在应用层的，它负责服务的组合、编排和转发，负责处理业务用例的执行顺序以及结果的拼装，以粗粒度的服务通过 API 网关向前端发布。
	
应用服务还可以进行安全认证、权限校验、事务控制、发送或订阅领域事件等。
3.领域层

领域层的作用是实现企业核心业务逻辑，通过各种校验手段保证业务的正确性。

领域层主要体现领域模型的业务能力，它用来表达业务概念、业务状态和业务规则。

领域层包含聚合根、实体、值对象、领域服务等领域模型中的领域对象。

注意：

领域模型的业务逻辑主要是由实体和领域服务来实现的，其中实体会采用充血模型来实现所有与之相关的业务功能。
	
实体和领域服务在实现业务逻辑上不是同级的，当领域中的某些功能，单一实体（或者值对象）不能实现时，领域服务就会出马，它可以组合聚合内的多个实体（或者值对象），实现复杂的业务逻辑。
4.基础层

基础层是贯穿所有层的，它的作用就是为其它各层提供通用的技术和基础服务，包括第三方工具、驱动、消息中间件、网关、文件、缓存以及数据库等。比较常见的功能还是提供数据库持久化。

基础层包含基础服务，它采用依赖倒置设计，封装基础资源服务，实现应用层、领域层与基础层的解耦，降低外部资源变化对应用的影响。

5.从三层架构向 DDD 分层架构演进

DDD 分层架构中的要素其实和三层架构类似，只是在 DDD 分层架构中，这些要素被重新归类，重新划分了层，确定了层与层之间的交互规则和职责边界。



三层架构向 DDD 分层架构演进，主要发生在业务逻辑层和数据访问层。
	
DDD 分层架构在用户接口层引入了 DTO，给前端提供了更多的可使用数据和更高的展示灵活性。
	
DDD 分层架构对三层架构的业务逻辑层进行了更清晰的划分，改善了三层架构核心业务逻辑混乱，代码改动相互影响大的情况。
	
DDD 分层架构将业务逻辑层的服务拆分到了应用层和领域层。应用层快速响应前端的变化，领域层实现领域模型的能力。
	
在数据访问层和基础层之间：三层架构数据访问采用 DAO 方式；DDD 分层架构的数据库等基础资源访问，采用了仓储（Repository）设计模式，通过依赖倒置实现各层对基础资源的解耦。仓储又分为两部分：仓储接口和仓储实现。仓储接口放在领域层中，仓储实现放在基础层。原来三层架构通用的第三方工具包、驱动、Common、Utility、Config 等通用的公共的资源类统一放到了基础层。
（四）三种微服务架构模型的对比和分析



重点关注图中的红色线框，它们是非常重要的分界线，这三种架构里面都有，它的作用就是将核心业务逻辑与外部应用、基础资源进行隔离。
	
红色框内部主要实现核心业务逻辑，划分了应用层和领域层，来承担不同的业务逻辑。
	
领域层实现面向领域模型，实现领域模型的核心业务逻辑，属于原子模型，它需要保持领域模型和业务逻辑的稳定，对外提供稳定的细粒度的领域服务，所以它处于架构的核心位置。
	
应用层实现面向用户操作相关的用例和流程，对外提供粗粒度的 API 服务。它就像一个齿轮一样进行前台应用和领域层的适配，接收前台需求，随时做出响应和调整，尽量避免将前台需求传导到领域层。应用层作为配速齿轮则位于前台应用和领域层之间。
二、领域驱动设计分层架构与微服务代码模型

DDD 并没有给出标准的代码模型，不同的人可能会有不同理解。这里我们在使用的时候还是建议按照欧创新架构师总结的来进行适用，具体如下：

（一）代码模型总目录结构



根据 DDD 分层架构模型建立了标准的微服务代码模型，在代码模型里面，各代码对象各据其位、各司其职，共同协作完成微服务的业务逻辑。它包括用户接口层、应用层、领域层和基础层，分层架构各层的职责边界非常清晰，又能有条不紊地分层协作。

用户接口层：面向前端提供服务适配，面向资源层提供资源适配。这一层聚集了接口适配相关的功能。
	
应用层职责：实现服务组合和编排，适应业务流程快速变化的需求。这一层聚集了应用服务和事件相关的功能。
	
领域层：实现领域的核心业务逻辑。这一层聚集了领域模型的聚合、聚合根、实体、值对象、领域服务和事件等领域对象，以及它们组合所形成的业务能力。
	
基础层：贯穿所有层，为各层提供基础资源服务。这一层聚集了各种底层资源相关的服务和能力。
业务逻辑从领域层、应用层到用户接口层逐层封装和协作，对外提供灵活的服务，既实现了各层的分工，又实现了各层的协作。

1.微服务一级目录结构



微服务一级目录是按照 DDD 分层架构的分层职责来定义的。从下面这张图中，我们可以看到，在代码模型里分别为用户接口层、应用层、领域层和基础层，建立了 interfaces、application、domain 和 infrastructure 四个一级代码目录。

2.用户接口层目录结构、职能和代码形态

主要存放用户接口层与前端交互、展现数据相关的代码。前端应用通过这一层的接口，向应用服务获取展现所需的数据。这一层主要用来处理用户发送的 Restful 请求，解析用户输入的配置文件，并将数据传递给 Application 层。数据的组装、数据传输格式以及 Facade 接口等代码都会放在这一层目录里。

具体如下：



Assembler：实现 DTO 与领域对象之间的相互转换和数据交换。一般来说 Assembler 与 DTO 总是一同出现。
	
Dto：它是数据传输的载体，内部不存在任何业务逻辑，我们可以通过 DTO 把内部的领域对象与外界隔离。
	
Facade：提供较粗粒度的调用接口，将用户请求委派给一个或多个应用服务进行处理。
3.应用层目录结构、职能和代码形态

主要存放应用层服务组合和编排相关的代码。应用服务向下基于微服务内的领域服务或外部微服务的应用服务完成服务的编排和组合，向上为用户接口层提供各种应用数据展现支持服务。应用服务和事件等代码会放在这一层目录里。

具体如下：



Event（事件）：这层目录主要存放事件相关的代码。它包括两个子目录：publish 和 subscribe。前者主要存放事件发布相关代码，后者主要存放事件订阅相关代码（事件处理相关的核心业务逻辑在领域层实现）。为了实现事件的统一管理，建议你将微服务内所有事件的发布和订阅的处理都统一放到应用层，事件相关的核心业务逻辑实现放在领域层。通过应用层调用领域层服务，来实现完整的事件发布和订阅处理流程。
	
Service（应用服务）：这层的服务是应用服务。应用服务会对多个领域服务或外部应用服务进行封装、编排和组合，对外提供粗粒度的服务。应用服务主要实现服务组合和编排，是一段独立的业务逻辑。你可以将所有应用服务放在一个应用服务类里，也可以把一个应用服务设计为一个应用服务类，以防应用服务类代码量过大。
4.领域层目录结构、职能和代码形态

主要存放领域层核心业务逻辑相关的代码。领域层可以包含多个聚合代码包，它们共同实现领域模型的核心业务逻辑。聚合以及聚合内的实体、方法、领域服务和事件等代码会放在这一层目录里。

具体如下：



Aggregate（聚合）：它是聚合软件包的根目录，可以根据实际项目的聚合名称命名，比如权限聚合。在聚合内定义聚合根、实体和值对象以及领域服务之间的关系和边界。聚合内实现高内聚的业务逻辑，它的代码可以独立拆分为微服务。以聚合为单位的代码放在一个包里的主要目的是为了业务内聚，而更大的目的是为了以后微服务之间聚合的重组。聚合之间清晰的代码边界，可以让你轻松地实现以聚合为单位的微服务重组，在微服务架构演进中有着很重要的作用。
	
Entity（实体）：它存放聚合根、实体、值对象以及工厂模式（Factory）相关代码。实体类采用充血模型，同一实体相关的业务逻辑都在实体类代码中实现。跨实体的业务逻辑代码在领域服务中实现。
	
Event（事件）：它存放事件实体以及与事件活动相关的业务逻辑代码。
	
Service（领域服务）：它存放领域服务代码。一个领域服务是多个实体组合出来的一段业务逻辑。你可以将聚合内所有领域服务都放在一个领域服务类中，你也可以把每一个领域服务设计为一个类。如果领域服务内的业务逻辑相对复杂，建议将一个领域服务设计为一个领域服务类，避免由于所有领域服务代码都放在一个领域服务类中，而出现代码臃肿的问题。领域服务封装多个实体或方法后向上层提供应用服务调用。
	
Repository（仓储）：它存放所在聚合的查询或持久化领域对象的代码，通常包括仓储接口和仓储实现方法。为了方便聚合的拆分和组合，我们设定了一个原则：一个聚合对应一个仓储。（特别说明：按照 DDD 分层架构，仓储实现本应该属于基础层代码，但为了在微服务架构演进时，保证代码拆分和重组的便利性，把聚合仓储实现的代码放到了聚合包内。）
5.基础层层目录结构、职能和代码形态

主要存放基础资源服务相关的代码，为其它各层提供的通用技术能力、三方软件包、数据库服务、配置和基础资源服务的代码都会放在这一层目录里。

具体如下：



Config：主要存放配置相关代码。
	
Util：主要存放平台、开发框架、消息、数据库、缓存、文件、总线、网关、第三方类库、通用算法等基础代码，你可以为不同的资源类别建立不同的子目录。
（二）应用层的领域对象分析

应用层的主要领域对象是应用服务和事件的发布以及订阅。

在事件风暴或领域故事分析时，我们往往会根据用户或系统发起的命令，来设计服务或实体方法。为了响应这个命令，我们需要分析和记录：

在应用层和领域层分别会发生哪些业务行为；
	
各层分别需要设计哪些服务或者方法；
	
这些方法和服务的分层以及领域类型（比如实体方法、领域服务和应用服务等），它们之间的调用和组合的依赖关系。
在严格分层架构模式下，不允许服务的跨层调用，每个服务只能调用它的下一层服务。服务从下到上依次为：实体方法、领域服务和应用服务。建议采用服务逐层封装的方式，服务的封装和调用主要有以下几种方式：



1.实体方法的封装

实体方法是最底层的原子业务逻辑。

如果单一实体的方法需要被跨层调用，你可以将它封装成领域服务，这样封装的领域服务就可以被应用服务调用和编排了。
	
如果它还需要被用户接口层调用，需要将这个领域服务封装成应用服务。
经过逐层服务封装，实体方法就可以暴露给上面不同的层，实现跨层调用。

封装时服务前面的名字可以保持一致，你可以用 *DomainService 或 *AppService 后缀来区分领域服务或应用服务。

2.领域服务的组合和封装

领域服务会对多个实体和实体方法进行组合和编排，供应用服务调用。

如果它需要暴露给用户接口层，领域服务就需要封装成应用服务。

3.应用服务的组合和编排

应用服务会对多个领域服务进行组合和编排，暴露给用户接口层，供前端应用调用。

多个应用服务可能会对多个同样的领域服务重复进行同样业务逻辑的组合和编排。当出现这种情况时，就需要分析是不是领域服务可以整合了。可以将这几个不断重复组合的领域服务，合并到一个领域服务中实现，这样领域模型将会越来越精炼，更能适应业务的要求。

应用服务类放在应用层 Service 目录结构下。领域事件的发布和订阅类放在应用层 Event 目录结构下。

（三）领域层的领域对象分析

事件风暴结束时，领域模型聚合内一般会有：聚合、实体、命令和领域事件等领域对象。

在完成故事分析和微服务设计后，微服务的聚合内一般会有：聚合、聚合根、实体、值对象、领域事件、领域服务和仓储等领域对象。

1.设计实体

大多数情况下，领域模型的业务实体与微服务的数据库实体是一一对应的。

但某些领域模型的实体在微服务设计时，可能会被设计为多个数据实体，或者实体的某些属性被设计为值对象。

在分层架构里，实体采用充血模型，在实体类内实现实体的全部业务逻辑。这些不同的实体都有自己的方法和业务行为，比如地址实体有新增和修改地址的方法，银行账号实体有新增和修改银行账号的方法。

实体类放在领域层的 Entity 目录结构下。

2.找出聚合根

聚合根来源于领域模型，聚合根是一种特殊的实体，它有自己的属性和方法。聚合根可以实现聚合之间的对象引用，还可以引用聚合内的所有实体。

在个人客户聚合里，个人客户这个实体是聚合根，它负责管理地址、电话以及银行账号的生命周期。
	
个人客户聚合根通过工厂和仓储模式，实现聚合内地址、银行账号等实体和值对象数据的初始化和持久化。
聚合根类放在代码模型的 Entity 目录结构下。聚合根有自己的实现方法，比如生成客户编码，新增和修改客户信息等方法。

3.设计值对象

根据需要将某些实体的某些属性或属性集设计为值对象。值对象类放在代码模型的 Entity 目录结构下。

在个人客户聚合中，客户拥有客户证件类型，它是以枚举值的形式存在，所以将它设计为值对象。

有些领域对象可以设计为值对象，也可以设计为实体，我们需要根据具体情况来分析：

如果这个领域对象在其它聚合内维护生命周期，且在它依附的实体对象中只允许整体替换，我们就可以将它设计为值对象。
	
如果这个对象是多条且需要基于它做查询统计，建议将它设计为实体。
4.设计领域事件

如果领域模型中领域事件会触发下一步的业务操作，我们就需要设计领域事件。

首先确定领域事件发生在微服务内还是微服务之间。
	
然后设计事件实体对象，事件的发布和订阅机制，以及事件的处理机制。
	
判断是否需要引入事件总线或消息中间件。
领域事件实体和处理类放在领域层的 Event 目录结构下。领域事件的发布和订阅类建议放在应用层的 Event 目录结构下。

5.设计领域服务

如果一个业务动作或行为跨多个实体，我们就需要设计领域服务。

领域服务通过对多个实体和实体方法进行组合，完成核心业务逻辑。可以认为领域服务是位于实体方法之上和应用服务之下的一层业务逻辑。

按照严格分层架构层的依赖关系：

如果实体的方法需要暴露给应用层，它需要封装成领域服务后才可以被应用服务调用。
	
如果有的实体方法需要被前端应用调用，我们会将它封装成领域服务，然后再封装为应用服务。
领域服务类放在领域层的 Service 目录结构下。

6.设计仓储

每一个聚合都有一个仓储，仓储主要用来完成数据查询和持久化操作。

仓储包括仓储的接口和仓储实现，通过依赖倒置实现应用业务逻辑与数据库资源逻辑的解耦。

仓储代码放在领域层的 Repository 目录结构下。

（四）代码模型强调内容

第一点：聚合之间的代码边界一定要清晰。

聚合之间的服务调用和数据关联应该是尽可能的松耦合和低关联，聚合之间的服务调用应该通过上层的应用层组合实现调用，原则上不允许聚合之间直接调用领域服务。

这种松耦合的代码关联，在以后业务发展和需求变更时，可以很方便地实现业务功能和聚合代码的重组，在微服务架构演进中将会起到非常重要的作用。

第二点：你一定要有代码分层的概念。

写代码时一定要搞清楚代码的职责，将它放在职责对应的代码目录内。

应用层代码主要完成服务组合和编排，以及聚合之间的协作，它是很薄的一层，不应该有核心领域逻辑代码。

领域层是业务的核心，领域模型的核心逻辑代码一定要在领域层实现。

如果将核心领域逻辑代码放到应用层，你的基于 DDD 分层架构模型的微服务慢慢就会演变成传统的三层架构模型了。

三、正确理解微服务的边界

微服务设计的重点，就是看微服务设计是否能够支持架构长期、轻松的演进。

在事件风暴中，我们会梳理出业务过程中的用户操作、事件以及外部依赖关系等，根据这些要素梳理出实体等领域对象。

根据实体对象之间的业务关联性，将业务紧密相关的多个实体进行组合形成聚合，聚合之间是第一层边界。
	
根据业务及语义边界等因素将一个或者多个聚合划定在一个限界上下文内，形成领域模型，限界上下文之间的边界是第二层边界。
为了方便理解，我们将这些边界细分为：逻辑边界、物理边界和代码边界。

（一）逻辑边界

逻辑边界主要定义同一业务领域或应用内紧密关联的对象所组成的不同聚类的组合之间的边界。

微服务内聚合之间的边界就是逻辑边界。一般来说微服务会有一个以上的聚合，在开发过程中不同聚合的代码隔离在不同的聚合代码目录中。它是一个虚拟的边界，强调业务的内聚，可根据需要变成物理边界，也就是说聚合也可以独立为微服务。

微服务的架构演进并不是随心所欲的，需要遵循一定的规则，这个规则就是逻辑边界。微服务架构演进时，在业务端以聚合为单位进行业务能力的重组，在微服务端以聚合的代码目录为单位进行微服务代码的重组。

来看一个微服务实例，在下面这张图中，我们可以看到微服务里包含了两个聚合的业务逻辑，两个聚合分别内聚了各自不同的业务能力，聚合内的代码分别归到了不同的聚合目录下。



那随着业务的快速发展，如果某一个微服务遇到了高性能挑战，需要将部分业务能力独立出去，我们就可以以聚合为单位，将聚合代码拆分独立为一个新的微服务，这样就可以很容易地实现微服务的拆分。

另外，我们也可以对多个微服务内有相似功能的聚合进行功能和代码重组，组合为新的聚合和微服务，独立为通用微服务，有点做中台的感觉！

（二）物理边界

微服务之间的边界是物理边界。它强调微服务部署和运行的隔离，关注微服务的服务调用、容错和运行等。

物理边界主要从部署和运行的视角来定义微服务之间的边界。不同微服务部署位置和运行环境是相互物理隔离的，分别运行在不同的进程中。这种边界就是微服务之间的物理边界。

举例：



有些项目团队在将集中式单体应用拆分为微服务时，首先进行的往往不是建立领域模型，而只是按照业务功能将原来单体应用的一个软件包拆分成多个所谓的“微服务”软件包，而这些“微服务”内的代码仍然是集中式三层架构的模式，“微服务”内的代码高度耦合，逻辑边界不清晰，这里我们暂且称它为“小单体微服务”。

而随着新需求的提出和业务的发展，这些小单体微服务会慢慢膨胀起来。当有一天你发现这些膨胀了的微服务，有一部分业务功能需要拆分出去，或者部分功能需要与其它微服务进行重组时，你会发现原来这些看似清晰的微服务，不知不觉已经摇身一变，变成了臃肿油腻的大单体了，而这个大单体内的代码依然是高度耦合且边界不清的。

这种单体式微服务只定义了一个维度的边界，也就是微服务之间的物理边界，本质上还是单体架构模式。微服务设计时要考虑的不仅仅只有这一个边界，别忘了还要定义好微服务内的逻辑边界和代码边界，这样才能得到你想要的结果。

（三）代码边界

不同层或者聚合之间代码目录的边界是代码边界。它强调的是代码之间的隔离，方便架构演进时代码的重组。

代码边界主要用于微服务内的不同职能代码之间的隔离。

微服务开发过程中会根据代码模型建立相应的代码目录，实现不同功能代码的隔离。由于领域模型与代码模型的映射关系，代码边界直接体现出业务边界。

代码边界可以控制代码重组的影响范围，避免业务和服务之间的相互影响。

微服务如果需要进行功能重组，只需要以聚合代码为单位进行重组就可以了。

四、正确认识服务和数据在微服务各层的协作

（一）正确认识服务的协作

1. 服务的类型

按照分层架构设计出来的微服务，其内部有 Facade 服务、应用服务、领域服务和基础服务。之前都有提到，这里可以回忆一下！

2. 服务的调用（三类主要场景）

微服务的服务调用包括三类主要场景：微服务内跨层服务调用，微服务之间服务调用和领域事件驱动。




	
微服务内跨层服务调用
	
前端应用调用发布在 API 网关上的 Facade 服务，Facade 定向到应用服务。应用服务作为服务组织和编排者，它的服务调用有这样两种路径：

第一种是应用服务调用并组装领域服务。此时领域服务会组装实体和实体方法，实现核心领域逻辑。领域服务通过仓储服务获取持久化数据对象，完成实体数据初始化。
	
第二种是应用服务直接调用仓储服务。这种方式主要针对像缓存、文件等类型的基础层数据访问。这类数据主要是查询操作，没有太多的领域逻辑，不经过领域层，不涉及数据库持久化对象。
 


	
微服务之间的服务调用
	
微服务之间的应用服务可以直接访问，也可以通过 API 网关访问。

由于跨微服务操作，在进行数据新增和修改操作时，你需关注分布式事务，保证数据的一致性。


	
领域事件驱动
	
领域事件驱动包括微服务内和微服务之间的事件。

微服务内通过事件总线（EventBus）完成聚合之间的异步处理。
	
微服务之间通过消息中间件完成。异步化的领域事件驱动机制是一种间接的服务访问方式。
当应用服务业务逻辑处理完成后，如果发生领域事件，可调用事件发布服务，完成事件发布。

当接收到订阅的主题数据时，事件订阅服务会调用事件处理领域服务，完成进一步的业务操作。

3. 服务的封装与组合

微服务的服务是从领域层逐级向上封装、组合和暴露的。基本如下图体现：



（二）正确认识服务数据的协作

在 DDD 中有很多的数据对象，这些对象分布在不同的层里。它们在不同的阶段有不同的形态：

数据持久化对象 PO(Persistent Object)，与数据库结构一一映射，是数据持久化过程中的数据载体。
	
领域对象 DO（Domain Object），微服务运行时的实体，是核心业务的载体。
	
数据传输对象 DTO（Data Transfer Object），用于前端与应用层或者微服务之间的数据组装和传输，是应用之间数据传输的载体。
	
视图对象 VO（View Object），用于封装展示层指定页面或组件的数据。
微服务各层数据对象的职责和转换过程如下：



1.基础层数据协作

基础层的主要对象是 PO 对象。

我们需要先建立 DO 和 PO 的映射关系：

当 DO 数据需要持久化时，仓储服务会将 DO 转换为 PO 对象，完成数据库持久化操作。
	
当 DO 数据需要初始化时，仓储服务从数据库获取数据形成 PO 对象，并将 PO 转换为 DO，完成数据初始化。
大多数情况下 PO 和 DO 是一一对应的。但也有 DO 和 PO 多对多的情况，在 DO 和 PO 数据转换时，需要进行数据重组。

2.领域层数据协作

领域层的主要对象是 DO 对象。

DO 是实体和值对象的数据和业务行为载体，承载着基础的核心业务逻辑。

通过 DO 和 PO 转换，我们可以完成数据持久化和初始化。

3.应用层数据协作

应用层的主要对象是 DO 对象。

如果需要调用其它微服务的应用服务，DO 会转换为 DTO，完成跨微服务的数据组装和传输。

用户接口层先完成 DTO 到 DO 的转换，然后应用服务接收 DO 进行业务处理。如果 DTO 与 DO 是一对多的关系，这时就需要进行 DO 数据重组。

4.用户接口层数据协作

用户接口层会完成 DO 和 DTO 的互转，完成微服务与前端应用数据交互及转换。

Facade 服务会对多个 DO 对象进行组装，转换为 DTO 对象，向前端应用完成数据转换和传输。

5.前端应用数据协作

前端应用主要是 VO 对象。

展现层使用 VO 进行界面展示，通过用户接口层与应用层采用 DTO 对象进行数据交互。

 

参考书籍、文献和资料

1.极客时间课程《DDD实战》，欧创新，2019.

2.郑天民. 微服务设计原理与架构. 北京：人民邮电出版社，2018.

3.陈超、秦金卫、张逸等. 高可用可伸缩微服务架构. 电子工业出版社. 2019.

4.Eric Evans. 领域驱动设计-软件核心复杂性应对之道。 人民邮电出版社. 2018.

政务区块链对于电子证照共享的应用场景

区块链电子证照系统场景，所解决的是证照共享的问题。

在预防各部门自己的证照被批量的被盗用或被篡改。采用区块链证照模式，将各个部门的证照共享。

解决的问题

证件被批量盗取

证件被他方恶意修改

证件共享难

 

实现模式

各个部门将证件的哈希值、关联主键（身份证等）、获取地址、摘要保存到区块链中，通过区块链同步到各个部门。

在各个部门中如果需要用到证照信息，通过关联主键获取单张证件。



 

 

 

电子证明共享的应用场景

 

通过构建政务区块链电子证照共享平台，以解决以上的难题。

 

      先来描述一个场景，当A部门需要提供给B部门证明，用以证明办证人员的有效性来说。来B部门办证的人员选要去A部门开具有效证明。然后那这A部门开具的纸质盖章证明来B部门办证。

通过以上场景会出现几种问题：

证明丢失

证明作假

证明格式不正确

证明无效

那么上了政务区块链以后会发生什么变化呢？

1、场景一 二维码哈希值确认证明

          从上图看出办事人员的操作步骤并没有减少，但是其中一个无纸化和防丢失优化的整个办证的流程。



 2、场景二 网上申请开具证明，部门之间自动同步。

从上述场景优化出第二个场景。

            在新的过程中，需办证人员值需要在B部门等待办理，并不需要去A部门多跑一趟。



3、场景三 证明验证和历史证明追溯

在某种情况下，B部门办理了有效证件，但是在办理过程中其实没有拿到A部门的证明。或者B部门因为办理某个有效证件并没保存A部门的证明。

在以上情况下，两个部门都无法追溯这个事情的具体真想。那么通过调用区块链中的历史记录就可以还原整个事情的过程。

想要把APP上架到应用市场都要先注册开发者账号才可以。这里的方法包括注册帐号和后期上架及一些需要注意的问题。注意：首次提交应用绝对不能随便删除，否则后面再提交会显示应用APP冲突，会要求走应用认领流程，那个时候就会相当麻烦啦。

1、腾讯应用宝

腾讯开放平台地址：http://open.qq.com
注册开发者帐号地址：https://ssl.zc.qq.com/v3/index-chs.html
重要提示：开发者QQ号码一旦注册不能变更，建议使用公司老板或法人的QQ号码而不是员工私人号码注册，以免遇到员工离职等情况造成不必要的麻烦。2017年9月18日以后应用上架要提交软件著作权证明（原件扫描）或者该应用PC官网ICP备案截图+官网地址+2个以上的应用宝以外市场上线后台状态截图代替，软著后续补上。如果APP在应用宝搜索不到（不能外显），则必须提供软著+版号。
注册开发者帐号方法：
http://wiki.open.qq.com/wiki/注册开发者帐号
应用提交方法：http://wiki.open.qq.com/wiki/创建新应用

2、360手机助手

360开放平台地址：http://dev.360.cn
注册开发者帐号地址：http://dev.360.cn
重要提示：开发者帐号，建议使用公司老板或法人的邮箱或手机，而不是员工私人邮箱或手机注册，以免遇到员工离职等情况造成不必要的麻烦。企业操作人要进行实名认证，要提供身份证号，银行卡号及预留的手机验证码验证。应用上架必须要提交360的保证函。
注册开发者帐号方法：http://dev.360.cn/wiki
应用提交方法：http://dev.360.cn/wiki/index/id/21

3、百度手机助手/安卓市场/91助手

百度开发者平台地址：http://app.baidu.com
重要提示：百度手机助手、91助手 和安卓市场是联盟平台，在百度开发平台中上传APP通过审核后，在其它两个平台也可以搜索到自己的APP。这里只需要注册一个百度开发者帐号即可。开发者帐号，建议使用公司老板或法人的邮箱或手机，而不是员工私人邮箱或手机注册，以免遇到员工离职等情况造成不必要的麻烦。应用上架必须要提交百度的保证函。
注册开发者帐号方法：http://app.baidu.com/docs?id=2&frompos=401003
应用提交方法：http://app.baidu.com/docs?id=5&frompos=401007

4、小米应用商店

小米开放平台网站：https://dev.mi.com
注册开发者帐号地址：https://account.xiaomi.com/pass/register
重要提示：开发者帐号，建议使用公司老板或法人的邮箱或手机，而不是员工私人邮箱或手机注册，以免遇到员工离职等情况造成不必要的麻烦。企业操作人要进行实名认证，要提供身份证号，银行卡号及预留的手机验证码验证。该认证将调用“小米支付”服务，在该小米账号下绑定银行卡进行实名认证。
注册开发者帐号方法：https://dev.mi.com/docs/appsmarket/distribution/account_register/
应用提交方法：https://dev.mi.com/docs/appsmarket/distribution/app_submit/

5、华为应用市场

华为开发者联盟地址：http://developer.huawei.com/consumer/cn
注册开发者帐号地址：https://hwid1.vmall.com/CAS/portal/userRegister/regbyphone.html
重要提示：开发者帐号，建议使用公司老板或法人的邮箱或手机，而不是员工私人邮箱或手机注册，以免遇到员工离职等情况造成不必要的麻烦。应用上架必须要提交华为的免责函。
注册开发者帐号方法：
http://developer.huawei.com/consumer/cn/wiki/index.php?title=注册登录
应用提交方法：
http://developer.huawei.com/consumer/cn/wiki/index.php?title=创建并管理应用

6、阿里应用商店/豌豆荚/PP助手

阿里开发者平台地址：http://open.uc.cn
重要提示：阿里应用分发 整合了 豌豆荚、阿里九游、PP助手、UC应用商店、神马搜索，并联合YunOS应用商店等应用分发平台，实现全流量矩阵布局。这里只需要注册一个阿里开发者帐号即可。
注册开发者帐号地址：https://reg.taobao.com/member/reg/fill_mobile.htm
重要提示：开发者帐号，建议使用公司老板或法人的邮箱或手机，而不是员工私人邮箱或手机注册，以免遇到员工离职等情况造成不必要的麻烦。企业操作人要进行实名认证，用支付宝扫描二维码进行实名认证。应用上架必须要提交阿里的保证函。
注册开发者帐号方法：http://aliapp.open.uc.cn/wiki/?p=35
应用提交方法：http://aliapp.open.uc.cn/wiki/?p=40

7、三星应用商店

三星开发者平台地址：http://support-cn.samsung.com/App/DeveloperChina/Home/Index
重要提示：全球开发者:只有当您与 Samsung Electronics Co. 有合作关系，才应选择全球开发者类型。完成卖家注册后：请联系您的三星对手方以批准三星应用商店的合作伙伴关系请求。如果无法确认您的合作关系，您必须重新注册会员资格。
主题开发者: 主题开发者类型的卖家只能使用三星SDK注册应用程序，但可以将应用程序销售到所有国家/地区。
中国开发者: 中国开发者类型的卖家可注册不使用三星SDK的应用程序，但只可将应用程序出售到中国。
注册开发者帐号地址：https://seller.samsungapps.com/join/joinNow.as
重要提示：开发者帐号，建议使用公司老板或法人的邮箱或手机，而不是员工私人邮箱或手机注册，以免遇到员工离职等情况造成不必要的麻烦。法人和联系人要双手持身份证拍照，要露出双臂，照片不能用软件处理。
注册开发者帐号方法：
http://support-cn.samsung.com/App/DeveloperChina/home/list?parentid=11&newsid=38
应用提交方法：（需要下载三星应用商店上传手册）
http://support-cn.samsung.com/App/DeveloperChina/home/list?parentid=11&newsid=11

8、OPPO应用商店

OPPO开发者联盟地址：http://open.oppomobile.com
注册开发者帐号地址：http://open.oppomobile.com/newuser/signup
重要提示：开发者帐号，建议使用公司老板或法人的邮箱或手机，而不是员工私人邮箱或手机注册，以免遇到员工离职等情况造成不必要的麻烦。必须要软件著作权，没有软著则可以试着在后台补交（华为、小米、应用宝）三家中的两家后台上架截图作为辅助依据上架，碰碰运气。应用上架必须要提交OPPO的免责函。
注册开发者帐号方法：http://open.oppomobile.com/doc/index?idx=0&item=39
应用提交方法：http://jingyan.baidu.com/article/d169e186656065436611d897.html

9、ViVO应用商店

ViVO开发者联盟地址：https://dev.vivo.com.cn
注册开发者帐号地址：
https://id.vivo.com.cn/?callback=http://dev.vivo.com.cn&registerSource=1&_201707171541#!/access/register
重要提示：开发者帐号，建议使用公司老板或法人的邮箱或手机，而不是员工私人邮箱或手机注册，以免遇到员工离职等情况造成不必要的麻烦。要记得填写联系人信息。
注册开发者帐号方法：https://dev.vivo.com.cn/doc/document/info
应用提交方法：https://dev.vivo.com.cn/doc/document/info?id=52

10、联想应用商店

联想开发者联盟地址：http://open.lenovo.com
注册开发者帐号地址：https://passport.lenovo.com/wauthen2/wauth/jsp/register.jsp
重要提示：开发者帐号，建议使用公司老板或法人的邮箱或手机，而不是员工私人邮箱或手机注册，以免遇到员工离职等情况造成不必要的麻烦。应用上架必须要提交联想的免责函。
注册开发者帐号方法：http://open.lenovo.com/developer/adp/helpData/database_detail.jsp?url=http://open.lenovo.com/sdk/zhzc/
应用提交方法： http://open.lenovo.com/developer/adp/helpData/database_detail.jsp?url=http://open.lenovo.com/sdk/?p=796

11、魅族应用商店

魅族开发者联盟地址：http://open.flyme.cn
注册开发者帐号地址：https://i.flyme.cn/register
重要提示：开发者帐号，建议使用公司老板或法人的邮箱或手机，而不是员工私人邮箱或手机注册，以免遇到员工离职等情况造成不必要的麻烦。应用上架必须要提交魅族的免责函。
注册开发者帐号方法： http://open-wiki.flyme.cn/index.php?title=新手指南
应用提交方法： http://open-wiki.flyme.cn/index.php?title=应用发布

12、金立应用商店

金立开发者联盟地址：https://open.appgionee.com
注册开发者帐号地址：https://open.appgionee.com/cp/register
重要提示：开发者帐号，建议使用公司老板或法人的邮箱或手机，而不是员工私人邮箱或手机注册，以免遇到员工离职等情况造成不必要的麻烦。应用上架必须要提交金立的承诺书。
注册开发者帐号方法： https://open.appgionee.com/cp/help
应用提交方法： https://open.appgionee.com/cp/help
这些都是主流的应用市场，操作流程其实在各自开发者平台官网上都可以找到，还有需要注意的是，不同类型的APP在不同应用市场需要提供的证书都会有所不同，需要上传前留意下具体需要哪些证明材料，特别是软件著作权证明或免责函。感觉华为、小米对资料的要求是最严格的；然后是360、魅族、阿里，如果你的应用程序是批量制作的，使用单一或几个模板生成的，或用简单文字、图片打包而成的话，它可以检测出来，并且不会让你通过审核。联想和vivo应该算是最好通过的。百度、小米、华为、魅族的开发者帐号审核相对慢一点，阿里、360跟腾讯还算比较快的，上架应用审核时间也相对比较快。只要资料全，其实很容易通过的。应用审核，OPPO要求要软著，审核上架不易。