DDD设计何时适可而止？

无论是敏捷和瀑布，软件开发都有一个设计过程，实际也是了解知识准备过程，属于坐而论道，那么什么时候动手开干？

1. 首先，动手开干的标志是什么？见这篇文章：

按技术职责还是按领域职责来构建代码？
文章里谈了代码如何组织包模块，也就是com.jdon.XXX的设计，这个XXX设计不是拍脑袋想出来的，而是基于你对领域的理解，如果你对业务领域不理解，你会直觉按照技术职责划分，或者按照团队划分，如果你业务领域理解了，那么会按照领域职责划分。

2. 那么理解业务领域的标志是什么？见这篇文章：

如何实现软件设计中的高凝聚和松耦合？
你如果能找出业务领域的高内聚和低耦合的划分，基本说明你已经对业务领域理解了，那么com.jdon.XXXX的包层次结构就大概出来，可以分工开干了。

3. 但是，关键是在内聚和耦合了，这个问题是否好解决呢？
不一定，因为这取决于上下文环境：

远看一只虎，近看一条狗！
没有上下文的数据就是噪音！ 上下文为王
这是数据科学领域的格言，那么同样适合在人对世界的认知中。
高聚合和低关联是依据上下文不同而不同的，也就是根据上下文环境做判断的，这是难点，因为如果你没有发现上下文的相关性，如同上图中，你没有发现铁栅栏投影到狗身上引起的条纹，这个上下文因素忽视了，那么内聚模型就建模建错了。

4. 那么到这里有什么诀窍吗？如果有，机器学习就战胜人类了，变成通用人工智能了。
所以，这就到艺术边缘，能子领域能聚合在一起就好了，单一功能职责划在一起就可以了，不必精益求精，因为已经到了艺术地步，不属于数学，再死磕就过了。
而且灵感不是死磕中出现，而是少做并学习后才出现：

程序员应该少做些"工作"

5. 好了，我们也死磕到此为止，话题一转，回到按照领域职责划分上：
com.jdon.xxxx.xxx.xxx.xxx的子包出来后，团队就要对齐这个领域划分包，每个团队承包一个子包，这就是：

DDD与团队拓扑以及微服务之间的关系图

6. 最后，再次提醒：

简单软件架构的一些好处