从桌面到 Web -- 领域模型

         让我们暂时告别一下 ASP.NET Core 先介绍一下这个虚拟项目。因为我的主要目的是通过一个项目，全面学习一下 ASP.NET Core，所以这个项目时一个很简单的，不具备实际应用价值的虚拟项目，但是项目会尽可能用到 Web 程序设计的常用技术。

         熟悉商品混凝土生产的朋友都知道，在这个领域常用的软件有两种，一个是混凝土生产线的生产控制软件，主要负责监控生产线的运行和按照生产和工艺流程，自动执行生产任务。这个软件一般是厂家自己开发或委托外包开发的。另外一种是生产管理软件，就是混凝土行业中常说的 ERP（名字有点大）,一般是专业软件公司提供。ERP（原谅我使用这个名字）根据生产计划生成生产任务在通过接口（大部分是通过一个中间数据库）把任务推送（存储）到生产控制软件(中间数据库),生产任务软件接收（从中间数据库读取）到任务然后自动运行。

         混凝土生产上有着多个存储仓，存储各种物料，而生产任务中包含着各种物料使用情况的配方。一个混凝土生产工厂，一般有多条生产线，而为了应对不同的生产工艺要求，不同的生产线有时会存储不同的物料。而ERP 在发送生产任务时，是靠人工来确定某个生产线是够存储需要的物料。这个虚拟项目就是在 ERP 的任务推送节后面增加一套管道机制，通过不同的管道过滤掉不适合的生产线，最后在通过各个生产线的等待生产的任务队列，自动负载平衡，选择最适合的生产线。

         这套管道机制应该方便的支持增加和删除管道，达到任务调度的灵活配置。这样我们就可以把新的任务过滤逻辑通过类似中间件的技术添加到整个管道中。

         这个虚拟项目的主要是为了学习 ASP.NET Core，索引领域模型设计的尽量简单，但是为了保证项目与实际的尽量贴近，也值得我们好好思考一下领域模型。  

说到 领域模型就不得不提到分层架构，站在桌面程序员的视角和Web 方面，分层架构没有大的区别，尤其现在微软在 ASP.NET Core提供大量的技术框架支撑分层架构(MVC,EF Core,依赖注入等)。在这个项目里，我们也毫不例外的使用DDD的三层架构。在表示层，因为这个项目设想中要想管道一样可以快速的接入到搅拌站ERP和生产控制之间，所以表示层被设计为时髦的两个部分组成：管理界面和用于接入的服务API。在数据层，主要提供从另两个方面获取数据源：数据库和其他服务的API ，在部署时要根据ERP和生产控制软件的数据发布方式进行选择和配置，当然选择和配置服务层要用到依赖注入。最后是用于封装业务逻辑的领域模型,业务逻辑是个挺操蛋的词(Martin Fowler 语，至少意思差不多).   使用DDD方式时，领域模型和数据层的映射是个麻烦事，这个留在数据访问层在讨论。

尽管业务逻辑是个很操蛋的词，但是不可否认领域模型作为整个软件和核心价值和灵魂值得我们认真去思考。做个项目的朋友都有体会，如果数据映射（ORM）是个技术问题的话，领域模型的设计更像一个哲学问题。 我们经常会碰到下面的问题：

领域模型设计的不合理，这种软件很难真正嵌入到客户的管理流程或价值链中，用户在使用这种软件是就像骑着阿凡提的毛驴或者开着绝地求生里被打爆轮胎的蹦蹦车一样，虽然有载具了，但是它永远不会按你想要的方向行驶。还有就是个别用户会提出特别各奇葩的业务逻辑。这些奇葩的需求或许会转换成你最不想看到的需求清单。但有时这些奇葩的需求有时确实能提升客户价值链上的某个环节，或者适应客户的某些管理流程。在做项目时还会遇到很多各种各样的问题。大部分业务逻辑问题都指向两个方面，一个是对客户的价值链或管理流程理解不清晰，导致领域模型设计的不合理，第二个是领域模型的扩展性不好，不能对模型进行快速的扩展。他不分第二种情况是第一种的扩展，想想如果客户的管理流程确实支持某种扩展和修改，那我们的领域模型为什么不能支持呢。

作为系统设计人员，我们不应该相信或者说依赖市场部门提供的需求清单。很难想想这些需求清单能够清晰的描述客户的领域模型和价值链。我们常说要找到用户背后真正的需求。如果是企业应用程序，用户本身是企业的价值链和流程的一部分，用户的需求不能脱离企业的价值链和流程，他是需求仅仅是在完成企业流程或实现价值链的同事满足一下自己的价值提升，举个例子说，使用财务管理软件的用户的需求不可能脱离这个企业的财务管理制度，他的个人需求可能是在使用这个软件是能更方便更快，或者是显得他更专业，好向老板证明他的价值。实现个人的需求更过的是靠UI 和门面对象(Fact)的支持，而领域模型更应该真实准确的反应企业的流程和价值链。

在完成一个好用的项目后，项目开发人员几乎都能成为至少半个领域专家，这要得益于他在项目开发过程中不断的和用户交流，再把企业的领域模型应代码重构。企业的流程本身就是一个模型，只不过系统设计人员要通过与用户的交流学习它，在通过自己的语言(UML，编程语言)再把他重构。Eric Evans再《领域驱动设计》中提到过可以通过用UML创建的领域模型和用户交流，我重来没尝试过，不过我坚信，如果你能用 UML 图和用户交流，那么你的领域模型设计的十分成功。

PS：写东西真累，这几年深受焦虑症的困扰，身体一直不好，甚至影响到思维能力和语言表达能力，最近身体好转，想通过坚持写博客慢慢锻炼思维能力和语言表达能力，所以文章的条例和语言有些混乱，请见谅！

PS：原创不易，水平有限，内容漏洞百出，请转发的网站和朋友注明出处。