DDD设计何时适可而止？
source link: https://www.jdon.com/59951
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
DDD设计何时适可而止？
无论是敏捷和瀑布，软件开发都有一个设计过程，实际也是了解知识准备过程，属于坐而论道，那么什么时候动手开干？
1. 首先，动手开干的标志是什么？见这篇文章：
按技术职责还是按领域职责来构建代码？
文章里谈了代码如何组织包模块，也就是com.jdon.XXX的设计，这个XXX设计不是拍脑袋想出来的，而是基于你对领域的理解，如果你对业务领域不理解，你会直觉按照技术职责划分，或者按照团队划分，如果你业务领域理解了，那么会按照领域职责划分。
2. 那么理解业务领域的标志是什么？见这篇文章：
如何实现软件设计中的高凝聚和松耦合？
你如果能找出业务领域的高内聚和低耦合的划分，基本说明你已经对业务领域理解了，那么com.jdon.XXXX的包层次结构就大概出来，可以分工开干了。
3. 但是，关键是在内聚和耦合了，这个问题是否好解决呢？
不一定，因为这取决于上下文环境：
远看一只虎，近看一条狗！
没有上下文的数据就是噪音！ 上下文为王
这是数据科学领域的格言，那么同样适合在人对世界的认知中。
高聚合和低关联是依据上下文不同而不同的，也就是根据上下文环境做判断的，这是难点，因为如果你没有发现上下文的相关性，如同上图中，你没有发现铁栅栏投影到狗身上引起的条纹，这个上下文因素忽视了，那么内聚模型就建模建错了。
4. 那么到这里有什么诀窍吗？如果有，机器学习就战胜人类了，变成通用人工智能了。
所以，这就到艺术边缘，能子领域能聚合在一起就好了，单一功能职责划在一起就可以了，不必精益求精，因为已经到了艺术地步，不属于数学，再死磕就过了。
而且灵感不是死磕中出现，而是少做并学习后才出现：
程序员应该少做些"工作"
5. 好了，我们也死磕到此为止，话题一转，回到按照领域职责划分上：
com.jdon.xxxx.xxx.xxx.xxx的子包出来后，团队就要对齐这个领域划分包，每个团队承包一个子包，这就是：
DDD与团队拓扑以及微服务之间的关系图
6. 最后，再次提醒：
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK