Pisces的由来

自我介绍

我从业大约有14年，早年从事C#已经各类前端技术的开发，从2013年起专注java后端的开发。

曾经在公司A，从0到1研发了一套低代码开发平台，对于企业级应用有教深刻的理解；
作为架构师，对于常规的分布式应用的架构设计能力，至少也是合格的水准；
现在公司B从事工业数字化软件的研发，转而在【数据密集型应用】的技术领域不断积累。

pisces是什么

这么多年，那个在公司A低代码框架是我个人最得意的作品，在研发过程中，投入了巨大的精力，也有不小的成果。在离开公司后，我将其核心技术又融入了一些微服务框架的技术和具有DDD特点的一些框架,再次编写了一份，命名为pisces——因为自己是双鱼座。

pisces是个人在业务时间整理和编写的，而该框架也用于一公司实际开发，至少从可用性等方面是经过考验的。

现在想沉下心，写一份专栏，记录下该框架的点点滴滴，主要是成果和思考过程，代码也会在合适的时间点开放出来。

核心价值

pisces-orm

最大的核心价值是一套自研的ORM框架。彼时的产品要求，无论mybatis还是hibernate都无法支持——需要以配置的方式定义业务对象，并支持其CRUD，所以它的诞生多少有点被逼出来来的感觉。
pisces-orm里有很多原创技术，个人以为对于常规OLTP系统的开发，其感觉与实际效果是好于mybatis的。
当然，因为最近3年几乎不从事和关系型数据库有关的研发，所以我也不太清楚如今的mybatis和mybaits-plus演进到如何程度了，所以后文当我阐述彼时的思考时，也请读者站在彼时的技术背景条件下，给予理解，在此谢谢各位看客。

我会在下一遍博文里阐述pisces-orm的设计与思考。

pisces-domain

在离开公司A后，我读了几本关于【DDD】的书籍，在理解了几个核心概念后，我发现pisces在通用业务组件和服务的模块和【DDD】的理解是有契合之处的，这让我感到些许兴奋。

在有了pisces-orm基础上，pisces-domain提供了一些常规的业务组件，以满足常规的业务需求。优点是，可以支持配置的方式使用它们，缺点是，目前仅支持java代码的配置方式，当然逻辑上是支持其他配置方式的，如xml、json、最理想的自然是在线的表单或图形设计器。

但核心的要点是——支持配置，我们可以高度复用通用组件，而不是机械性的代码赋值粘贴，这正式低代码框架的最关键之处。

pisces-servie

名字还有待商榷，这个模块主要封装了一些基础功能点、对spring-cloud的一些组件做了增强，以降低开发成本。这块内容主要是产品和开发人员提出的一些通用的非功能性需求提炼而来。