当前位置: 首页 > 编程学习 > 软件工程 > 领域驱动 > 正文

从零开始使用CodeArt实践最佳领域驱动开发(一)

2018-04-22 来源:博客园/一个人抽烟

目前绝大多数公司依然采用的是传统的项目实施方式——围绕数据库设计做应用程序开发。在这种方式下,程序员的主要工作就是不断的增删改查各种数据表,以数据为核心驱动系统的运行。随着项目进度的推进,系统暴露的问题却越来越多,程序员每天陷入无止境的修复状态中,增加或修改一个功能的代价也越来越大。项目进展看似在推进却好像永远都不会有完成的那一天。

我于2005年的时候就隐约感觉这种方式是错误的,关系型数据库的优势是处理数据的存储而非解决复杂的业务需求,以数据库为核心开发项目必然会导致失败。所以在往后的10多年里不论多么艰难我都坚持摒弃围绕数据库做开发的工作方式,最终我找到了正确的方向,完美的实践了领域驱动设计,在这方面可谓硕果累累。同时,为了降低领域驱动实施的门槛,我一手打造了企业级开发框架CodeArt。现在将其发布出来提供大家免费使用,同时分享大量的实战经验,希望能够帮助各位改善项目实施的过程。

1.CodeArt是什么?

CodeArt(简称CA)是一套完整的创新式企业级开发框架。它将整个业务应用划分为四个层次结构:表现层、应用层、领域模型层和基础设施层。针对这4个层次CA提供了多项特性以满足开发人员的需要,它的特点之一是可以帮助开发人员彻底摆脱以数据库设计为中心的项目实施方式,令程序员不再忙碌于数据的增删改查等枯燥无味的低价值工作,转而专注于系统领域的设计。具体而言,使用CA开发应用程序具备如下特点:

1) 零风险。对,你没有看错,CA可以保证项目始终处在零风险的实施状态。众所周知,软件项目随着需求规模的增加,复杂性会成指数级增长。各种错综复杂的业务关系、少量或频繁的需求变更都会带来开发成本的大幅度提升。类似的经历相信大家都经历过,很多项目在初期开发都很顺利,但是随着完成的功能越来越多,系统暴露的问题也逐渐加剧,开发团队需要不断的修补,可是越是修正它们,它们就会变得越糟糕,最终导致系统彻底瘫痪。然而这一切在CA的开发模式下是不存在的,我们把一个普通程序员能在不犯错的情况下良好完成的需求规模衡量为1,那么无论你项目规模是大还是小,CA始终可以化整为1,令程序员们面对的的需求规模仅仅是最基本的1。

2) 与常规开发模式相比,CA可以提升5至10倍以上的综合开发效率。这里的综合开发效率是指开发新功能和维护、变更已完成功能的效率总和。一方面,CA提供了许多创新型模块来大幅度降低开发过程中遇到的各种问题,这包括不需要写任何JS的前端表现层框架、灵活百变的数据迁移对象DTO、实现了No SQL的领域模型层框架等组件。另外一方面,这些组件也会令你在项目实施中对现有功能的简单或复杂的改动都不会导致有依赖关系的模块的连锁改变。在修改或者新增应用程序功能的时候,需要改动的模块非常少,不会导致程序其他地方出现问题。

3) 100%重用性。使用CA开发项目重用度的目标只有一个,那就是100%。在常规开发中,重用这项特性很容易理解但是却很难实现,我们在许多项目中经常看到的情况是整个系统没有一个业务模块是可以重用的。类似数据库操作、缓存机制等技术模块的重用很容易办到,但是技术模块上的重用控制不了业务的复杂性,也无法降低开发成本。而在CA的开发模式下,我们会利用其提供的各项特性不仅将系统多维度切割成若干可以独立开发的最小单元,更重要的是这些单元可以无缝的协同工作,甚至独立分离出来提供其他项目使用。CA完美的实现了业务级别的重用,被重用的单元可以在不更改、不修改、不增加原有代码情况下,以扩展或继承的方式二次使用。

4) 为程序员增值。CA完美的实践了领域驱动的开发思想,极大降低了领域驱动在项目中实施的门槛。确切的讲,CA对现有领域驱动设计进行了细化和补全,同时提供了各项特性和决策判断的思路以便开发者能轻松的实施领域设计。因此,程序员的工作内容不再是围绕数据库做永无止境的增删改查操作,而是沉醉于领域对象该如何设计、子系统该如何切分、针对需求的变化该如何重构代码等富有创造力的工作,令每一位程序员不再是码农而是领域设计师,用创造力而非蛮力去处理项目中遇到的各类问题。

除了以上特点之外,CA自身是一个永久免费、开源并且终生维护、永不断更的企业级框架。目前CA提供了.Net Framework版,在近期我们还会完成.Net Core和Java版的开发工作,让更多的程序员能享受到CA带来的便利。

2.CodeArt的核心思想

在正式使用CA之前,让我们把注意力放在一个浅显却又深奥的话题上:软件开发的目标是什么?这个问题似乎很容易找到答案——满足用户的需求。可是如果这个目标是对的,那为什么我们在倾听用户的声音之后,按照他们意图开发出来的成果却常常又被他们以各种理由修改甚至推翻呢?这也许是用户犯的小错误,谁叫用户是上帝呢?所以我们每天埋头苦干以确保他们新的想法能落实在项目里,纵使这些想法依然会改变、纵使现有的程序不得不大量修改、纵使我们背负码农之名也义无反顾、勇往直前,这正是程序员价值的体现,对吧?

错。编写程序是一项极富创造力的工作,造成困境的根本原因在于我们的用户并不是他们所在领域里的专家。或者说,他们比我们了解的更多的仅仅是表面需求。满足眼前的表面需求其实很容易。但是要预测他们的都还不知道的本质需求呢?随着项目的推进,用户可以看到的功能越多,他们就越会发觉到更多的贴近本质需求的表面需求让你去满足,如果你始终跟随用户的指挥棒去行动,那么你的项目必定会陷入无止境的实现失败,最终会由于开发成本远高于预算而宣告失败!

因此,我们编写程序的目标是正确的挖掘现实事物在特定领域里的本质特征。这些本质的特征决定了用户需求的导向。也就是说,你编写的程序越贴近用户所在领域里的本质特征,那么你就越能满足用户已知或未知的各种需求,不论是现在还是未来的变化都尽在你的掌握之中!

以领域洞见作为项目开发的基础是CA秉承的一条重要原则。所谓领域洞见并非要求你在当前这个时间点上能预测到未来的变化而做出满足未来需求的程序设计,这听起来很美好但绝非人力所能及。恰恰相反,我们要做的不是虚无缥缈的过度设计,而是根据眼前已知的表面需求,在遵循一系列的设计原则下去构建领域模型。确保这些模型是健壮的、是容易更改的、是能满足当前需求的即可。当一旦需要修改现有模型时,我们能轻松、灵活的去更改现有的代码,甚至能够做到在不破坏原有模型的基础上做出扩展式的补充即可满足新的需求。以迭代式的良性变化拥抱需求的剧变才是领域洞见真正的含义。

所以,在CA的四层架构里,领域模型层是重中之重,它是整个软件项目的基石、是保证项目稳健实施的根本。软件的界面可以简陋、数据存储可以低效,但是你的领域模型一定不能乱。简陋的界面我们可以随时去美化而无须触碰业务代码。随着数据量的增多,数据存储的性能需要提高,我们也可以使用建立索引、分表、分区、甚至分布式部署等各种成熟的技术去优化,你依然无须担心业务代码是否受到牵连。因为在CA的开发模式里,优化数据库不会影响到业务代码的更改,业务的处理全部由领域模型层负责,数据库所处的级别在基础设施层的数据仓储里,与业务代码没有任何交集。只要你的领域模型足够健壮,你完全不必担心系统的安全性、伸缩性、扩展性等常规指标,我们可以轻松的驾驭这一切。即便这些指标在眼前由于时间、成本等原因我们无法做到较高的度量值,但是由于领域模型为我们打下了坚实的基础,就算在项目后期甚至正式发布后再回头来逐一优化这些指标也不会带来任何问题。

然而,设计一个良好的领域模型并非想象中的那么简单,因为探索事物本质的代价是巨大的。物理学发展上百年才得到若干个贴近物理现象的计算公式,而我们要在以月为单位计算的项目开发周期里摸索出符合事物在某类领域里的本质特征也是困难的。为此,CA提供了大量构建领域模型的基础设施,大幅度降低领域设计的门槛。这包括一系列的设计原则和多种基础类库,只要你遵循CA的标准在项目中坚持实践,依然可以踏入软件艺术家的领域,使用创造力赢得项目的成功,这也是CodeArt名称的由来。

在后面的教程里,我们以会议系统作为项目案例,模拟真实的实施情景由浅入深的揭露CA在领域模型中的设计原则和基础类库使用的方法。除了项目本身的实施过程是真实的以外,该案例里涉及到的企业、个人等信息均为虚构,请勿探究。