从DDD开始说起

前言

从13年接触DDD之后开始做应用架构已经整整四个年头.

四年里关于DDD的感触良多,慢慢有了一些心得.

关于DDD的介绍已经有很多的文章和书籍,这里我推荐三本最重要的书籍.

《领域驱动设计-软件核心复杂性应对之道》（DDD）

《实现领域驱动设计》(IDDD)

《领域驱动设计模式,原理与实践》(PPPDDD)

具体的DDD介绍这三本书已经很清楚了,但是学完这些之后我认为DDD才刚刚开始.

DDD给我更多的是一种设计启发,无论是里面的战术设计,还是战略设计都可以展开到很多点.

书籍里面很多时候只是一些设计原则,和一些简单的demo,但是基于这些原则作为出发点,可以展开很多的设计.

架构有时候就是一个生长的,当我基于DDD为起点,不断演进架构.这时候架构仿佛也有了生命力,不断地成长,到最后可能是最开始完全想想不到的样子,我想这大概就是架构的魅力.但是无论如何,DDD都是一个起点.

下面是我总结的基于DDD发散的一些知识体系

下面会有简单的描述

---

仓储

DDD中仓储将持久化这个技术复杂性保持在领域模型之外.

具体来说有以下在具体实践中有以下几点：

1. 隔离领域模型和数据模型：衍生出来就是隔离内存里面的模型和持久化模型.这个点会在EAV的设计中体现的淋漓尽致.
2. 技术复杂度的封装：仓储负责如何组织模型存储.

静态分库:按照领域上下文(或者模块)分库,所谓纵向分库,在程序启动的时候就决定了某个实体该放到那个数据库,所以称之为静态.

动态分库:当某个库的数据量很大时候,这时候要对表数据做切割,所谓横向分库.在程序运行时候,针对某个实体的某条数据才能决定放到那个库,所以称之为动态.

1. 规则横切. 将一些面向切面编程的逻辑放到仓储中.具体来说仓储主要控制的就是CRUD

软删除:那么只要在删除和查询的时候稍作处理即可实现软删除.

数据权限:只要在操作的时候判断,查询时候拼接条件即可实现数据的筛选.

---

应用程序服务

应用程序在我设计的时候我倾向于把契约和实现放到不同的项目中,基于这个偏好.慢慢演化出了如下思路

1. Abp中有个方式直接把应用程序服务暴露出可以http访问的api
2. 客户端用动态代理的方式+ioc即可实现访问契约,但是实际通过http请求调用
3. 实现几个host方式,例如 IIS,Owin的Windows Service
4. 基于Host动态加载程序集

从1-4是一个递进的过程,并非一簇而就或者一次性想到,而是不断重构优化产生的结果.

基于以上四步就已经接近一个应用程序容器.

PS: 这里其实还是刚刚起步 ,后续还有很多工作要做 ,目前还在实践演化中.

PS：应用程序容器是从单体架构到微服务的一个重要的重构手段.

---

领域上下文

在DDD中涉及到领域上下文这部分,是在宏观战略层面的部分,偏重于业务架构层面.

在微观中,涉及到的时候对某个类,或者某几个类的抽象和设计.

在宏观中,有时候需要把部分通用的功能进行抽离,即DDD中的支撑域.

另外上下文之间的通信也是这里要解决的问题.

1. 微服务:这部分网上很多资料不细说
2. 微应用:如果一个应用既有界面又有服务,我称之为微应用.
3. 上下文通信:这部分涉及内部消息总线,外部消息队列,另外结合之前应用服务容器中的动态代理部分的通信方式.
4. 战略设计： 其实就是部分支撑域的设计.虽然DDD中说更加看重核心域,但是在实际工作中发现,其实让团队成员集中精力
   
   对业务进行设计,抽离一部分公有业务会减轻程序员很大一部分负担.

---

战略设计

ACS

这部分重点有就是ACS(权限控制系统).其中按照不同层级分为

1. 应用级别权限:控制应用和应用之间的访问权限
2. 用户级别权限:控制用户账户对系统的访问权限
3. 功能级别权限:控制用户对某个功能的访问权限
4. 数据级别权限:控制用户对某条数据的访问权限

基于功能级别的权限又演化出来一个逻辑应用的概念,实际应用是隔阂的,逻辑应用将多个系统功能合并成一个新的应用.

统计系统

基于每个系统都会产生统计的需要,这里引用CQRS的思想,将部分复杂的统计作为查询统一设计.

这个里面最核心的部分就是动态查询的设计.具体点就是将SQL和数据结构关联.作为SQL设计器的基础.

组件服务

1. 计划任务:有部分定时任务会用windows service的方式host.并用调用应用的接口来实现定时触发.
2. 通知中心:将站内,短信,邮箱,微信,移动端,推送做抽象.
3. 附件:将附件的存储和获取与具体技术做隔离,并提供断点续传的功能.

---

聚合

其实这一部分发散开就是对业务逻辑的理解和设计.今年年初公司开始导入敏捷,感觉又打开一片新的天地.

DDD说领域驱动设计,很多时候只是提了一个原则,但是具体该如何来.慢慢接触到如下切入点：

1. BDD(行为驱动设计)
2. 实例化需求
3. 用户故事

在宏观的业务需求梳理和分析的时候接触到《用户故事地图》.

基于敏捷接触到持续集成,慢慢接触到DevOps.

基于DevOps还设计了一个自动化测试工具.

敏捷和devops,是今年一年重点在学习的地方,也在不断的实践.

当然目前还是有很多问题急需解决.

---

总结

距离上一次发文已经很久了,有些知识经常不用就会忘记.

从这篇开始,会陆续有以上心得的分享,权当自我总结复习,欢迎大家讨论拍砖.

因为很多是源于公司的经验和业务,可能不会有全部的源码,但是重点部分会有的.

我一直觉得现并不重要,重要的是设计.

但是现在很多人都是更加注重某行代码怎么写.

现在互联网这么发达,这些具体技术点一般都很容易找到解决方案.

但是创新的设计思路却是找不到的,这些我觉得才是一个程序员的灵魂.