概述
可能我最早了解到建模，是在IEC61970-CIM模型，那个时候在搞电力调度系统，曾经操作过建模工具，却不知道这个模型是怎么在系统中起作用的…也只是猜测这是一种领域模型…
你不能用你狭隘的项目经验，幻想着去理解DDD，那只会产生较大的无用功！你对更高一层技术的理解需要你的实践经验来同步支撑。
领域模型
领域模型，你真的理解的了吗？，其中提到了，存在两种领域模型，一种是来源于最初的传统软件开发过程，一种来源于领域驱动设计，两种领域模型的侧重点是不同的！
业务逻辑
这是从对充血模型的学习和理解过程中来的问题思考。构架充血模型的困难点在于：如何划分业务逻辑，即如何做到把业务逻辑正确的放在领域层和应用层。
啥是佩奇
百科里有一个关于业务逻辑层的定义，它的关注点主要集中在业务规则的制定、业务流程的实现等与业务需求有关的系统设计，也即是说它是与系统所应对的领域（Domain）逻辑有关。
学习DDD有一周了，回到自己的项目中，“业务逻辑”这个名词回旋在脑海中，却突然发现不知道什么啥是MyTP系统的业务逻辑？在不知道这个答案的情况下，竟然分析了一天的如何将业务逻辑划分到领域层和应用层，脸红啊！
赶快来补下：什么是业务逻辑？ 业务逻辑是指一个实体单元为了向另一个实体单元提供服务，应该具备的规则与流程。就像你家的规矩–“吃饭前必须洗手”“有客人来要起立”“睡觉前各自说晚安”-就是业务逻辑的生活化实例。业务逻辑的内容可以包括四个部分：
- 领域实体：定义了业务中的对象，对象有属性和行为；
- 业务规则：定义了需要完成一个动作，必须满足的条件；
- 数据完整性：某些数据不可少；
- 工作流：定义了领域实体之间的交互关系。
得承认，小白阶段的博主对写业务逻辑代码有过偏见，现在对业务逻辑的设计处理一跃成了系统架构中体现核心价值的部分，嗯，得缓缓！来看看小白要认真坚持写好逻辑代码这件事情，大道至简，玩出新花样。如，在处理业务逻辑之前，应该去思考如何设计这个架构，可以让代码更好的扩展和维护，告诉自己在写DDD的核心，O(∩_∩)O哈~待到博主成为大白，留作教育小白…
两只佩奇
这个问题的主要目的是，消除纠结“是不是只有Web应用程序才适合谈业务逻辑”，像我的TP桌面应用是不是不配叫佩奇！这是个大问题，完全回答这个问题，需要等待博主个人能力更上一层塔！慢慢来分析 - -
http://www.360doc.com/content/18/0820/20/42594168_779792799.shtml
其实这个地方应该是两个疑问：
1> Web应用与C++桌面应用关于应用层和领域层的问题？
2> Web应用与C++桌面应用关于表现层和应用层的问题？
业务逻辑放哪
先明确一点：好的代码，应该是简单的、漂亮的、应该是能解决问题而不是制造问题的，不要为了面向对象而面向对象。也就是说，到底应该采用贫血模型还是充血模型，应该视场景的相对问题？
https://www.cnblogs.com/NewBigLiang/p/4971513.html
https://www.cnblogs.com/xdot/p/5151700.html
微服务架构和领域驱动设计
https://my.oschina.net/matieli/blog/2986348
分离UI层
先讲下在此之前的一个纠结：由于对Web应用程序的设计与实现，了解甚少，感觉上Web应用的UI与业务逻辑是天然分离的；而C++桌面应用中的UI与业务逻辑却难拆的很？
不管是DDD还是纯粹的讲分层架构风格，UI层都是独立的。所谓独立，是说不管谈论应用层还是领域层，它们都不应和具体的UI控件扯淡！
将UI界面和功能逻辑混写在一起，确实会显得混乱，不利于团队开发和产品迭代，它们需要尽可能的分离。一个简单的判断它们解耦程度的办法：离开了UI界面，业务逻辑是否可以正常调用和运行，否则，此处架构欠妥。同时，对UI界面和业务逻辑的每个模块，是否能够被替换，而不影响整个项目的功能，也是判断架构解耦性的一个指标。
用户界面与业务逻辑的分离-简单思路
https://blog.csdn.net/qq_39654127/article/details/81046240
要想形成规范统一的接口，第一步是业务逻辑分类得！
如何划分业务逻辑和界面的问题
https://blog.csdn.net/kaifeng2988/article/details/48251495?locationNum=3&fps=1
关于业务原语，没有找到其具体的概念定义。但是有原语的定义、服务原语的定义，基于上述参考，业务原语可以理解为：用户和业务逻辑实体对象间的的一段接口代码，通过业务原语能实现UI层和业务逻辑层的交互，且这段代码具有不可分割性，其执行必须是连续的。可以将其理解为功能单一的函数接口。
DDD与架构
关系
DDD并不要求采用特定的架构风格，因为它是对架构中立的。你可以采用传统的三层式架构，也可以采用REST架构和事件驱动架构等。但是在《实现领域驱动设计》中，作者比较推崇事件驱动架构和六边形（Hexagonal）架构。
六边形架构
六边形架构是Alistair Cockburn在2005年提出，解决了传统的分层架构所带来的问题。在领域驱动设计（DDD）和微服务架构中都出现了六边形架构的身影。这篇文章不错，有理有据的对比分析了传统分层架构与六边形架构，并进行了较深入的内涵分析。
参考
https://blog.csdn.net/cws1214/article/details/52388408
很好的参考
https://www.jdon.com/ddd.html