引言
上一篇文章介绍微服务的领域驱动设计，微服务中被独立成单个领域服务。每个领域内都有特定领域能力。这样就可以使得在单个服务内的逻辑是比较纯粹单一的，最终由业务模块层完成各个领域的能力的整合。这是最理想的结果。然而在实际很多企业项目级开发中会出现较多的问题：
- 业务能力耦合严重，领域之间通信频繁，常见的是业务模块层有一些细微逻辑处理不了，需要到领域层去调用其他的领域嫩能力。
例：在做订单业务的时候需要访问用户的信息直接在订单中访问用户服务，同时用户的信息的时候也会去访问订单的相关信息。
- 领域层逻辑频繁变动：很多业务在初期时候是可以满足业务功能，但是经过几次迭代之后就发现需要逻辑重写，甚至有的时候直接导致线上bug。复盘也发现代码按照当时的功能写也并没有问题。
例：在做流程性业务的时候，把很多流程性逻辑直接写在了领域层，导致领域层提供的能力就比较笨重，当后续有迭代l流程变更的时候只得去修改整个代码，最后发现这个能力还被其他服务引用，最后只能重写，如果没发现就会引起他业务的bug
以上的问题只是在我们工作中项目中经常会发现的，绝大部分企业肯定都会出现这种境况，只要你用我写的《职业人做事方法论》去做项目必然发现的。
针对逻辑编程
问题已经存在了，那么为了保持领域驱动设计所带给我们的好处，并进行扩大战果，我们应该怎么避免产生上述的问题呢？根据我的总结分析我觉得是我们编程的一个习惯问题，我提出的一个核心理论就是改变我们的编程习惯，去针对逻辑编程。下面我一步步讲述为何要针对逻辑编程，以及如何针对逻辑编程。
为何要针对逻辑编程
原因其实很直接也很简单，就是抽象事物。其实抽象思维很大程度上就是忽略了主语和宾语的特性以及修饰语，保留谓语以及主语和宾语的简单个体。这样下来就是比较接近一个逻辑的描述。如描述：一个拥有一百万的富豪在杭州的4S店买了一台非常豪华漂亮的奔驰车，抽象就是一个人买了一个商品。如果你的代码领域能抽象成整个逻辑，那么买商品整个动作是通用的，至于什么样的人，买了什么样的商品都是业务模块场景要赋予的内容。这样服务的能力才是单一纯粹的。
如何针对逻辑编程
例子： 一个拥有一百万的富豪在杭州的4S店买了一台非常豪华漂亮的奔驰车
软件实现：很多软件开发设计者在最初的时候就是定义购买人就是百万富翁，车子就直接写成了奔驰，购买地点就是4S店。
后期迭代：当需要完成另外的一类人也要在其他地点购买车子之后，那这个功能基本需要重写了
从以上的例子中我只是举了一个例子，例子只是为了方便理解，人，车子只是我们较容易理解的对象。在项目中我们的对象的设计至关重要（对象的分解设计我其他博文有介绍）。对象设计完之后，进行逻辑抽象，去掉表格，补语，定语等。最后剩下的主要的主谓宾就是我们想要的描述的逻辑。我们在领域层只要完成这个能力即可。
结语
本篇文章内容较为简单，总而言之提升我们的抽象能力，把这个能力应用到编程中，就是针对逻辑编程。关联的能力对象设计，领域驱动设计在其他博文介绍。个人觉得针对逻辑编程另外也就是要提升我们面对复杂问题的时候的聚焦能力,只关注核心逻辑。
另外附上例子的正解，希望对各位看官有所启发，如下：
例子： 一个拥有一百万的富豪在杭州的4S店买了一台非常豪华漂亮的奔驰车
抽象分析：
对象：人，车子
属性：
人的属性： 百万富豪
商品属性：宝马，车，豪华
事件属性：
地点：杭州，4S店面
- 核心逻辑：人买了商品
- 属性内容赋予
代码实现：
- 订单中心-人购买商品
- 商品中心-创建定义商品
- 用户中心-创建购买人
业务层通过调用这个三个领域的能力完成最终功能。后期有其他的购买交易都只要定义商品和跟商品相关的信息，以及用户维护。就可以实现微服务的各自迭代推进。
方便理解，例子都比较简单，但是针对逻辑编程这个方法是这样，核心方法论：
- 完整的描述功能
- 保留主谓宾，去除表补定
- 分开完成表补定创建
- 完成主谓宾逻辑编程