这篇文章主要介绍了设计面向DDD的微服务知识点有哪些的相关知识，内容详细易懂，操作简单快捷，具有一定借鉴价值，相信大家阅读完这篇设计面向DDD的微服务知识点有哪些文章都会有所收获，下面我们一起来看看吧。
领域-驱动-设计（DDD）提倡基于(用例相关的现实业务)进行建模。
现实问题视为领域;独立的问题描述为有界限的上下文(一个有界上下文对应一个微服务)，并强调通用语言讨论这些问题许多技术概念和模式，例如充血模型(对应我们常写贫血模型)、值对象、聚合和聚合根规则。
有时DDD技术规则和模式被视为障碍/啰嗦，对于实施DDD方法而言，学习曲线比较陡峭。
不要为了实施而实施，最重要的是使用通用语言编写与业务问题一致的领域代码。
此外仅当您要实现具有复杂业务规则的微服务时，才应使用DDD方法，诸如CRUD服务之类的简单职责可以通过更简单的方法进行管理。
DDD模式可以协助划分微服务边界
在已经确定的界限上下文，您可以为领域建模：实体模型、值对象和聚合，DDD与边界有关，微服务也与边界有关。
划分界限上下文，要平衡两个目标：
这两个目标可能彼此矛盾，两者通过演进的方式达到平衡：
尽可能分解系统，直到在下次分解时感到服务通信迅速增加。
例如从数据库中加载的实体，有时候需要做一下修正(截取部分信息、增加信息)才能适配客户端UI。
订单DDD微服务有三层：
三层形成的类库有清晰且明确的依赖关系
负责表达业务概念、业务场景和业务规则。这一层会将技术细节传递到基础设施层，这一层控制、反映业务场景，是业务软件的核心。
领域模型层是表达业务的地方，在编程上体现为捕获数据和行为（具有逻辑方法）的领域实体的类库
遵循持久性无感知和基础设施无感知原则
领域模型层必须完全忽略数据持久性细节，这些持久性任务应由基础设施层执行，因此，此层不应直接依赖基础设施，这意味着一个重要规则是领域模型实体类应为POCO。
领域实体不应直接依赖于任何数据访问基础框架（EF、NHibernate），理想情况下，您的域实体不应继承自或实现任何基础设施中定义的任何类型。大多数现代的ORM框架（例如Entity Framework Core）都支持这种方法，因此您的领域模型不会与基础设施耦合。
持久性无感知原则很重要，但也不应忽略持久性问题理解物理数据模型以及它如何映射到您的实体对象模型仍然非常重要，否则你的设计将会是空中楼阁。而且，大多数时候你将本应该采用关系数据库的设计直接迁移到 NoSQL或面向文档的数据库，领域模型层很可能不适用（基于存储技术和ORM技术，您的实体模型仍然必须遵守一些约束条件）。
定义软件要执行的工作，并引导（充血的领域对象）解决问题。
该层对对业务负责，有时会与其他系统的应用程序层交互。
该层保持薄：它不包含业务规则或知识，而仅协调任务并将工作委托给下一层的域对象协作;
它没有反映业务情况的状态，但是可以具有反映用户或程序的任务进度的状态。
微服务的应用层在.NET中一般表现为WebAPI，webapi实现交互、远程网络连接、为UI/Client app提供的外部请求中转。再次强调webapi不应该包含业务规则或领域知识（尤其是用于事务或更新的领域规则），这些应归领域模型类库所有。
应用层只协调任务，不能保存或定义任何域状态（域模型），它将业务规则的执行委托给领域模型类本身（聚合根和领域实体），这将最终更新这些领域实体中的数据。
总体来看，应用层是为实现前端用例的地方。
基础设施层: 定义如何将最初保存在领域实体中的数据持久化到数据库或者其他存储结构的过程。
一个示例是使用Entity Framework Core代码实现存储库模式类: 该存储库模式类使用DBContext将数据持久存储在关系数据库中。
根据前面提到的持久化无感知和基础设施无感知原则，基础设施层不得“污染”领域模型层。
关于“设计面向DDD的微服务知识点有哪些”这篇文章的内容就介绍到这里，感谢各位的阅读！相信大家对“设计面向DDD的微服务知识点有哪些”知识都有一定的了解，大家如果还想学习更多知识，欢迎关注亿速云行业资讯频道。
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
