认识达内从这里开始

无论是进行服务器开发还是网页框架结构设计都是需要掌握不同的开发编程语言的，今天我们就其中一项给大家做一个简单的介绍，希望大家通过对本文的阅读，能够对服务器开发有更多的了解，下面就开始今天的主要内容吧。

领域模型

领域模型的分析可以说是DDD当中最为核心的部分，因为你整个系统的业务逻辑代码都是基于领域模型而构成的。

而要将业务逻辑转换成领域模型除了对业务的熟悉外还需要极高的抽象能力，所以一般需要业务专家和建模专家共同完成。

怎样提炼一个好的领域模型是一个非常大的话题，推荐你阅读以下书籍：

《领域驱动设计：软件核心复杂性应对之道》Eric Evans

《实现领域驱动设计》Vaughn Vernon

《领域驱动设计与模式实战》Jimmy Nilsson

另外微软架构电子书上还有推荐其他几本DDD的书籍，遗憾的是，JD和TB都没搜到。

在团队刚开始分析领域模型时，对所有相关者都是一个极大的挑战，我这里分享几点经验帮助团队更好地度过这段时期：

不要想着能够一次提炼出完美的领域模型(除非团队中有着经验丰富的DDD实践者)，通常来说，我们会在会议上决定一个粗略的模型，然后在开发过程中你会发现有一些不自然的地方，比如某些上下文频繁地与其他上文通信，或者某个实体的行为不是很恰当，这个时候再去修正领域模型，这样演进式的过程可以大大降低你们在初期的压力。

如果你的团队整体能力不足以支撑领域模型的推行，或者他们在初期的配合度不高时，你可以选择把你的项目中业务逻辑最为复杂的部分使用弱化的领域模型拆解，比如仅使用充血模型和领域服务，这样至少你可以对最为复杂的部分引入一些DDD战术模式或设计模式。

就算你的团队能力够了，但大部分人都没有DDD的经验的话，我也建议先只引入部分模式(比如只引入实体，值对象和仓储这类比较容易理解的模式)来提高团队的敏感度之后再采用完整的领域模型。

领域模型会对查询带来一定的复杂性，这种时候你可以采用CQRS来分离Query和Command，只有在Cammand的时候你才需要发挥领域模型的威力，至于Query，SQL语句显然是更好选择。

基础架构

了解DDD的同学都应该知道，DDD当中最为重要的部分就是限界上下文(BoundedContext)，在领域模型中我们区分好了上下文之后，下一步就是选择一种技术手段来确保每个上下都是低耦合高内聚且自治的。

在分布式应用中，多数设计者和包括微软架构的电子书都会推荐使用一个上下文对应一个微服务的方式来实现(确实微服务和上下文的设计需求不谋而合)。

但单体应用该怎么办呢?

有同学说，我们可以通过命名空间来隔离它们啊。

不错，我们可以这样做，但是有以下几个缺点

在使用IDE的智能引用时，你得确认你引用的实体究竟是位于当前上下文之内还是之外。

会导致你的项目结构层次过深，不便于查看。(至于过深的标准是多少，看个人了，对于我来说，5层是可以接受的上限，理想是控制在4层以内)

不便于向微服务架构迁移

所以我们选择了使用程序集(java是使用jar包)的方式来隔离每个上下文，这样做克服了以上的缺点，但却带来了新的问题：动态加载这些上下文。

不过这种程度的问题比起带来的收益几乎可以忽视。

我们团队使用一个基础平台来动态加载这些上下文，

我们采用了 Abp 框架提供的插件功能来实现，如果你也是.net 的使用者，也可以采用 Abp 来构建这个应用。

当然自己写一个动态加载功能也并不困难。

可是我们的平台要承担很多功能，比如开放RESTful的API与Webservice(为了兼容老的接口), 同时还要提供授权(使用了基于Oauth2.0协议的三种模式)、数据库初始化、处理请求上下文等等，我就不一一列出来了。

我们希望BC(BoundedContext，后文都会简写为BC)里不需要关注网络层面的东西而只聚焦于应用，所以很多通用的事情都由平台来承担， 而且有时还会有一些交互，比如在验证权限时你得跟用户权限上下文通信。

在推行DDD过程中，总会有一些成员会问我，DDD给我们带来的好处是什么。

我总会不厌其烦地告诉他们，为了降低系统的维护成本和更合理地去解决系统业务的复杂性。

但后来我渐渐发现，实现DDD本身就不是一件容易的事情，它会对项目引入新的复杂性，有时候你会发现你团队花上大量时间去建模之后，在开发过程中却依然需要不断修正模型。

这很容易让整个团队士气变低，并且让开发人员有挫败感，这种时候我经常会怀疑DDD对我们而言是否真的有价值。

不过坚持下去，在你使用DDD完成一到两个项目之后，你会发现建模是一件非常有意思的事情——提炼业务并将其转换为一个无关技术的模型，这就跟搭积木一样。

最后给所有希望通过DDD来改善项目，并且提升自己的同学说以下两点：

1，不要奢望光通过阅读就能充分地理解DDD，你需要真正去实践(当然，框架和架构设计也是一样的，不要做象牙塔里的架构师)

2，实践的过程你总会碰见疑惑和挫折，比如完全不知道如何拆分上下文，也不知道该如何使用那些战术模式，这个时候再把那几本书拿出来翻翻，你就会发出“啊，原来这种场景还可以这样处理”的感概。

作者：ShiningRush

来源：博客园

【免责声明】：本内容转载于网络，转载目的在于传递最新信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。