从DDD开始提及

前言

从13年接触DDD以后开始作应用架构已经整整四个年头.
四年里关于DDD的感触良多,慢慢有了一些心得.
关于DDD的介绍已经有不少的文章和书籍,这里我推荐三本最重要的书籍.

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

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

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

具体的DDD介绍这三本书已经很清楚了,可是学完这些以后我认为DDD才刚刚开始.
DDD给我更多的是一种设计启发,不管是里面的战术设计,仍是战略设计均可以展开到不少点.
书籍里面不少时候只是一些设计原则,和一些简单的demo,可是基于这些原则做为出发点,能够展开不少的设计.

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

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

下面会有简单的描述

---

仓储

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

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

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

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

3.规则横切. 将一些面向切面编程的逻辑放到仓储中.具体来讲仓储主要控制的就是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,是今年一年重点在学习的地方,也在不断的实践.

固然目前仍是有不少问题急需解决.

---

总结

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

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

由于不少是源于公司的经验和业务,可能不会有所有的源码,可是重点部分会有的.

我一直以为现并不重要,重要的是设计.

可是如今不少人都是更加注重某行代码怎么写.

如今互联网这么发达,这些具体技术点通常都很容易找到解决方案.

可是创新的设计思路倒是找不到的,这些我以为才是一个程序员的灵魂.