大部分传统行业、一些技术能力偏向于业务层的互联网企业、和一些不希望因受制于后端而影响业务快递迭代的创业公司，大多都会倾向于 PaaS 形态的产品，抛开企业属性，PaaS 类的服务在处理以下场景更具交付优势：
或者在送餐
的路上。那这个例子就告诉我们一个业务流程如果我们不分割为多个领域的话
我们几乎无法完成一整套的操作。
这期间其实也涉及到了一个上下文或者数据流的变化，比如从订单上看用户订
单到商家订单，再到外卖送餐订单。这个订单如果是一个的话其实是需要多个
角色一起完成的。
从上面 --times的定义可以看到，参数的定义跟命令逻辑的定义（即这里的 Run）是分离的，当我们有大量子命令的时候，我们更倾向把命令的定义放到不同的文件甚至目录，这就会出现命令的定义是分散的，而所有命令的参数定义却集中在一起的情况。
这些定义是 cobra 的核心设计来源，要想解决我上面提到的两个问题，我们需要重新审视这些定义。为此，我们从头开始一步步分析何为一个命令行。
命令行只是一个可被 shell 解析执行的字符串
$ cmd arg1 arg2 arg3
命令行及其参数，本质上就是一个字符串而已。字符串的含义是由 shell来解释的，对于 shell来说，一个命令行由命令和参数组成，命令和参数以及参数和参数之间是由空白符分割。
还有别的吗？ 没了，没有什么父命令、子命令，也没有什么持久参数、本地参数，一个参数是双横线(--) 、单横线（-）还是其他字符开头，都没有关系，这只是字符串而已，这些字符串由 shell 传递给你要执行的程序，并放到 os.Args （Go 语言）这个数组里。
DO （Data Objec，数据对象）：一般都是使用 PO 作为持久化的数据对象，但是笔者习惯使用 DO，因为我觉得数据对象当然要和数据库中的字段相对应的。因此从名称来说，DO 作为持久化对象我想更加合适一点。
上文中分别说到了领域分层结构以及各个数据对象的不同含义和用途，那么我们接下来就看下各个数据对象在 DDD 的各个领域分层中是怎么进行数据流转的吧。
在用户接口层，它需要接收来自 WEB 端、APP 端以及其他的外部数据请求，并将请求通过 DTO 向应用层进行传递，根据应用层返回的 DTO 数据，再将 DTO 转化为页面需要呈现的 VO 数据，进行最后的页面展示。
