DDD-第一课

来自一名一线研发同学的反馈:

开发一直加班加点,但是业务部门还是感觉技术部门还是支撑不了业务的迭代;

上线之后特别担心出故障,总是有一些测试不到的路径,甚至有些问题并不是新修改引起的。

image-20200712172312940

债务严重影响了组织的生产力

1.严格控制代码评审,及时卡住;

2.质量管控,努力测的更完备。

简单的质量管控无法解决问题。

质量不好,做重构,重构问题越来越多。简单的推动重构,重构不会真正发生。

开发效率提升和业务发展要求存在冲突

image-20200712172651240

1.技术支撑商业发展;

2.技术扩展商业边界;

3.技术引领商业创新。

在不良的业务分析、架构设计基础上,推动中台化或微服务,往往会使矛盾凸显。

在云原生的未来,需求分析、架构设计和实现的能力将重新成为基本能力。

可落地的软件开发技术实践

image-20200712173150935

第一课:领域为核心的高效技术实践:从需求分析到业务上线

1.认知是软件开发的核心任务;

2.领域模型是软件开发的核心载体;

3.不要追求“完美”的模型——用协作和演进来探索领域模型;

4.支持协作和演进的实践方法概览。

image-20200712173822265

image-20200712173927211

image-20200712174106055

image-20200712174133120

image-20200712174235193

地心说和日心说

1.地心说也能在一定范围内解释天体运行,甚至通过修修补补,可以让它支持的范围延长很多;

2.日心说是更接近本质的模型,更有竞争力。

映射到软件开发中

无论对业务领域的认知正确与否,在早期支持业务功能总是没问题的。通过修修补补,还能大大延长软件的生命周期和适用性,只不过代价会越来越高昂;

更好的领域模型能带来更简洁优雅的实现,更快捷的知识传播,更容易地支持业务演进。

点点共乘:基于社区的共享出行服务

无车共乘:用户发起拼车业务,说明费用分摊方式、出发地点、到达地点、计划出发时间等信息,邀请其他用户参与,然后共同打出租车;

image-20200712175113445

顺风车:用户发起拼车业务,本人是车主,邀请其他用户参与

image-20200712175458598

社区巴士:运营方根据过往的共乘数据,规划了一些预定义路线,然后发不到社区,让用户选择和自己匹配的线路。

image-20200712175804239

image-20200712175940627

image-20200712180155716

对领域的认知,是一家企业的根本能力和竞争力。

领域模型的基本概念

领域模型:

1.领域模型是概念模型;

2.领域模型描述的是现实世界的实体和他们之间的关系;

3.领域模型是对问题空间的理解。

缺乏领域模型的一些信号:

1.组织中没有关于概念的共识;

2.沟通误解和不必要的需求变更;

3.看似容易支持的业务涉及到系统的很多改动点;

4.架构可理解性和可维护性不足,容易发生意料之外的问题。

领域模型的表示:

image-20200712180749326

高质量领域模型的特征:

1.建立共识;

2.产生洞察;

3.持续演进。

共识的重要性:

image-20200712181205757

大家说一说什么是产品。

共识产生于协作空间:

image-20200712181454352

在白班上可视化领域模型:

image-20200712181543389

建立统一语言:

除非做到统一语言,否则领域模型并不是真正的模型;

一个简单规则:任何在需求描述中出现的概念,都必须出现在领域模型中。如果需要描述中存在概念之间的关系,领域模型中也必须有这个关系。

产生洞察:

image-20200712182058234

产生洞察的三个基本要素:

1.业务人员的直觉;

2.分解和抽象的能力;

3.持续演进的思维方式。

领域模型是深层模型:

有用的模型很少停留在表面层次上。随着对领域和应用的理解逐步加深,我们往往会丢掉那些最初看起来很重要的表面元素,或者切换他们的角度。

这样,一些在开始时不可能发现的巧妙抽象就会浮出水面,而他们恰恰切中问题的要害。

——Eric Evans

我如何才能找到如此的抽象呢?

会不会陷入过度设计呢?

地心说在今天看起来失败了,但是它真的是一个荒谬的理论吗?

image-20200712183640268

image-20200712183744997

持续演进:并不存在所谓“正确”的领域模型,只是说当前的领域模型经过了场景的检验,而且最为优雅。

建立统一语言:

1.将模型作为语言的中心,确保团队在所有的交流活动和代码中坚持使用这种语言。在画图、写文档和说话时也采用这种语言;

2.试着尝试修改模型以及对应的语言表达来消除不自然的地方(相应的也要修改代码,包括模块名、类名和方法等)。

领域模型不是分析阶段的产物,而是软件开发过程中贯穿始终的核心概念

image-20200712184635211

image-20200712184945390

image-20200712185053952

image-20200712185410292

image-20200712185508672

image-20200712185815133

image-20200712185918217

image-20200712190052648

*1在下列现象中,哪些是不够合理的做法?(可多选)

  • 认为领域建模是一个独立的活动,有特定人员完成
  • 领域模型被定义为面向对象方法的一部分
  • 领域模型被认为是软件开发人员的技能
  • 开发人员从代码视角推动领域驱动设计
  • 把领域建模作为一个单独的阶段

*2下列现象中,哪些可能是因为缺乏高质量的领域模型导致的后果?(可多选)

  • 虽然做了中台,但是并没有建立共享的业务能力
  • 做了微服务,却因为服务间的交互过度密集,最后又被迫把微服务合并了
  • 敏捷方法倡导快速交付,一开始看起来挺好,但是后来系统复杂度越来越高,交付速度变得越来越慢
  • 需求沟通经常误解
  • 在编写的代码中,各种逻辑混杂,真正的业务逻辑并不清晰可见,难以维护
  • 对一个业务的开发影响到了一个看似不相关的业务

*3”统一语言“是指(可多选)

  • 业务人员、开发人员和测试人员应该使用同一种概念交流
  • 需求描述、代码和测试用例应该使用领域模型中的概念
  • 其他

*4“好的领域模型来自于持续演进“这句话,你认为(单选)

  • 正确
  • 错误

*5多人协作建模时,更应该选用(单选)

  • 白板
  • 建模软件

*6在领域模型中,下面的符号可能代表(可多选)

img

  • B是一个A
  • B依赖于A
  • 概念A是概念B的抽象
  • B继承自A

*7下列哪些需求分析实践,是你和你的组织中正在采用的?(可多选)

  • 实例化需求
  • 影响地图
  • 事件风暴
  • 用例分析
  • 用户故事
  • 用户故事地图
  • 其他