戏说领域驱动设计（十五）中，内核元素有哪些特点？

本文共计4476个文字，预计阅读时间需要18分钟。

前端详细介绍了基于CQS的四层架构，其中领域模型层也是六边形架构中的核心。在开发流程中，领域模型层的工作占比最大，也是工程师最需要关注的方面。那么，这里的东到底包含什么呢？

　　前面细讲了基于CQS的4层架构，其中的领域模型层也就是六边型架构中的内核在整个开发流程中工作占比最大，也是需要工程师最需要关注地方。那么话说回来了，里面到底包含了什么东西需要投入如此高的关注度。答案还用说？必然是领域模型啊，比如实体、值类型、业务服务等，您别忘了咱们讲的是领域驱动设计。具体可参看如下图所示的领域模型层（后续简称BO层）中的元素。这里面东西较多，基乎每一种都可以开一章来讲，也就是可以水好多的文字。

一、业务模型层中的特色元素 1、业务异常

　　BO层中元素比较多，但这里面最具特色应该是“业务异常”。您说把领域模型、领域服务归结为BO中的元素这本是无可厚非的，因为它们本来面向的就是业务实体、业务逻辑。把异常也归结为BO中的元素是几个意思呢？而且，书上都没这么讲过，我这是不是故意的哗众取宠骗流量？这话不能这么说，书上没讲过的东西多着呢，人家写书的时候都会站在一定的前提之上，比如读者应该会一门开发语言，应该做过实际的项目，应该有具备哪些基本知识等。咱这种博客什么样的受众都有，内容本身也是个人经验的总结，有点特殊的东西很正常，而且我不仅要讲书上没有的东西，还会讲得很细，您就踏实的看吧。

　　回到业务异常这个事情上来，在软件的分析设计过程中，那些有形的物体（一般是名词）可以建成实体，比如订单、账户、商品等；还有一些是无形的但在需求过程中也隐晦的提到了，最典型的就是“事件”，这是对动词进行建模的经典案例。而异常则是典型的、经常被隐晦提及的需要被建模的实体，由于其隐蔽性所以在建模时很容易被忽略。举个例子，需求中可能会这样描述：下单失败时应该告知用户失败的原因。这个场景中提及了“失败原因”这个名词，那应该用什么东西来描述它呢？这时就需要业务异常来发挥热量了。显性的提及失败的处理逻辑还好一些，还有一种常见的需求形式比如：下单成功后，给用户发送短信通知。