对activiti有基本了解的朋友都知道，activiti暴露了七个接口来提供工作流的相关服务，这些接口具体是如何实现的呢？其实activiti中大部分操作都是基于设计模式中的命令模式完成的（这里还使用了职责链模式，构造了命令拦截器链，用于在命令真正被执行之前做一系列操作）。命令模式的本质在于将命令进行封装，发出命令和执行命令分离。职责链模式只需要将请求放入职责链上，其处理细节和传递都不需要考虑。activiti将这两个模式整合在一起，构成了其服务主要的实现方式。其核心只有三个部分：CommandExecutor（命令执行器，用于执行命令），CommandInterceptor（命令拦截器，用于构建拦截器链），Command（命令自身）。这三个接口是整个核心的部分。
RepositoryService是 Activiti的核心API之一。常用于发布流程定义。下面列举若干常用方法。
我们都知道Linus大神在1991年创建了Linux操作系统，并从那时起开始不断壮大，逐渐成为全世界最大的服务器操作系统。这么庞大的系统，在2002年之前，Linus大神本人以手工方式合并代码。后来，BitMover 公司的 CEO Larry McVoy 作为 Linus大神的好友，他说服Linus在内核开发中使用BitKeeper。而BitKeeper在免费使用的许可证中加入很多限制条件，惹恼了内核开发者，社区中开始有人尝试破解BitKeeper的协议，导致了BitMover与Linux社区分道扬镳！绕了半天，总算牵扯出我们的主角了，Git！废弃使用BitKeeper后，Linus大神花了两周时间，自己用C写了一个分布式版本控制系统，这就是Git！从这里开始，Git迅速成为最流行的分布式版本控制系统。2008年，GitHub网站的上线更是让Git火爆全球，许多开源软件和软件公司都开始使用Git。
领域模型是对领域内的概念类或现实世界中对象的可视化表示。又称概念模型、领域对象模型、分析对象模型。它专注于分析问题领域本身，发掘重要的业务领域概念，并建立业务领域概念之间的关系。贫血模型是指领域对象里只有get和set方法，或者包含少量的CRUD方法，所有的业务逻辑都不包含在内而是放在Business Logic层中。而充血模型大多业务逻辑和持久化放在Domain Object里面。
目前架构师这个职位特别火热，程序员的目标都是成为一个令人尊敬的架构师。但是我们真的理解架构师应该做些什么？很多人把架构师和框架师等同起来，认为研究框架多的才是架构师。架构师是技术的使用者而不是信徒，架构师也要深入了解掌握技术，但是更多的是了解技术的优劣和使用场景，而不是简单的生搬硬套。
我们采用了领域驱动的开发方式，使用了充血模型，享受了他的好处，但是也不得不面对他带来的弊端：事务一致性、多个领域多表Join查询。这个弊端在分布式的微服务架构下面又被放大。
领域模型是对领域内的概念类或现实世界中对象的可视化表示。贫血模型是指领域对象里只有get和set方法，或者包含少量的CRUD方法，所有的业务逻辑都不包含在内而是放在Business Logic层中。而充血模型大多业务逻辑和持久化放在Domain Object里面。
本文介绍了微服务和SOA的区别。微服务架构首先要关注的不是技术实现，而是服务的边界、职责划分。划分错误就会陷入大量的服务间的相互调用和分布式事务中，这种情况微服务带来的不是便利而是麻烦。
今天在Intellij IDEA中导入项目时，.properties 配置文件中中文内容是显示的是Unicode 编码，本文介绍了如何设置显示成中文
StarUML是一种创建UML类图，生成类图和其他类型的统一建模语言(UML)图表的工具。本文介绍了StarUML 3.0.1 版本的破解方法。
