1、有效的软件是与业务挑战相一致的软件
我们所说的一致，是指软件从领域中借用正确的术语，正确阐述业务的关键概念，并尽可能少地避免技术问题带来的意外的复杂性。
2、康威定律不是一个可以选择不接受的选项。
它的作用有点像某些物理定律，如重力的吸引力。我们可以尝试对抗它;-)但它在地球上仍然有效。康威法则是1967年的那个法则，它指出
"任何组织设计一个系统（广义的定义）都会产生一个设计，其结构是该组织的通信结构的副本"。
换句话说，一个软件的结构必然是参与设计的人的交流模式的结果。例如，一个由3个团队开发的编译器很可能分3次工作或有3个不同的模块。
逆向康威手法（ICM）可以让你利用康威法则的优势。这个逆向演习建议根据你想得到的软件架构来定义组织（例如团队的数量）。
3、领域驱动设计并不强加任何组织。
它提供了生存的关键，包括在功能失调的组织中（团队之间相互争斗或相互忽视）。DDD帮助我们理解权力问题和团队之间的社会问题。因此，它是一个解放我们的决定论的工具（因此我认为是一个左翼的工具;-)
4、另一方面，DDD为我们提供了一些工具，使我们能够设计出高效的软件，尽可能地与领域保持一致。其中，限界上下文（BC）的概念建议我们为用途设计模型，并将其包围起来，防止因其他上下文而产生的混淆/假朋友/误解。
5、为了更加协调和高效，DDD还强烈建议我们定期挑战我们的愿景和我们对解决方案的建模。
这也意味着在一个eureka 时刻（称为设计突破）之后，不时地革新和改变模型。这就是为什么我们在这里定期举行Context map会议，与产品人员一起不断完善我们对该领域的愿景。
6、开发团队有脆弱的平衡。
一个开发团队需要大约6个月的共同生活和人际关系，才能真正有效。你从这个团队中增加或删除一个人，它就不再是同一个团队了（见动态重新组队）。就效率而言，我更喜欢那些呆在一起并改变主题的团队，而不是那些只是根据主题进行爆炸/重新分配的团队。当然，如果有人厌倦了他们的团队或他们的主题，应该尽一切努力使他们有可能改变团队（个人的良好状态对我们的集体效率更加重要）。
我们目前的组织和我们在Agicap的团队都相当地隶属于一个或多个Bounded Contexts，以便考虑到问题的复杂性，并将我们各自的业务专长发挥到最小。不时地，一些团队可能有太大的范围，我们需要更好地切割和分配我们的Bounded Context。另一方面，这种BC的划分必须与业务概念保持联系（记住DDD）。
7、只要每个人都尊重Bounded Context的边界，没有什么能禁止在一个做DDD的组织中拥有功能团队。
8、目前，我们更倾向于采用Swarming的做法：一种由几个团队的人组成的工作队，但从一开始就定义了最终产品（工具、api、库）的责任和所有权。它有助于避免 "很好，我们一起做了一些事情，但现在谁来维护它？。
除了在让合适的人根据主题进行合作方面的有效性之外，swarming 通过暂时促进跨团队的人际关系，给我们的组织带来了大量的社会资本（对未来每个人回到自己的团队时超级有用）。
我们目前的产品组织被设定为每个开发团队有一个产品经理（PM），但也许让PM与业务主题有更多联系而不是与他们的团队有联系会很有趣？