我们有一个旧的和大的PHP应用程序，具有复杂的业务逻辑。现在该项目几乎完全由意大利面条代码组成。我计划使用Symfony进行平滑迁移，例如使用Symfony重写一些功能。同样看来DDD对于像这样的项目是一个很好的选择。所以主要的想法是重写一些功能，使其更干净，更易于维护。有什么建议吗？
感谢。
答案 0 :(得分：4)
实际上，DDD原则可以应用于遗留代码库重构的上下文中。这就是我们的做法（并且仍然在做着），但不要把它当成银弹：
第1阶段 - 战略准备：
1。）使用上下文映射来识别有界上下文及其集成。尝试与当前架构无关。由于偏见，这实际上是非常困难。如果您与那些不是旧系统的常用用户的人一起使用它会派上用场。
2。）按战略价值对上下文进行排序并确定您的核心域（钱在哪里？），最终找到支持子域（系统的一部分）支持实现您的战略目标）和通用子域（绝对必要的事情，即合规和会计）。
3。）将利益相关者，开发者和产品所有者聚集在一起，形成一种共同语言，即在不同域中的无所不在的语言，以捕捉业务的意图和能力。 如果您在讨论过程中听到含糊不清的内容，请对这些术语的中心词典进行教条，解决它并将其添加到词典中。这是任何DDD项目不可或缺的一部分，因为我们正在建模业务的能力，这意味着代码和利益相关者语言应该具有相同的语义。
4.。 OTPIONAL ：根据您单位的规模和工作方法，您可能需要对其进行重组。让康威定律为您工作，并通过将团队和个人重新分配到您之前已确定为最佳价值流的不同域中来创建某个特征重力最聪明的人应该在核心领域上工作。实现开发人员和利益相关者之间的直接通信接口，以便在规范上紧密合作，并不断提取模型。
第2阶段 - 实施：
0。）如果您没有经历过如此复杂的重构，请获得外部帮助（顾问）或聘请经验丰富的工程师。相信我，你需要它（我自己也很难学会）。
1。）创建泡泡上下文，您可以在其中重新设计模型并将其与旧系统集成。有很多集成模式（你可以找到这些模式的一个很好的总结here和here。总是问问自己，所讨论的上下文是否具有足够的战略价值，并且必然会随着时间的推移而发展并具有很好地回应未来的变化。最后，它是关于创建易于更改和重构的软件。迭代，冲洗和重复。始终在重新获得新代码时重构新代码来自企业的见解。
注意：请勿尝试做太多事情。 Bounded Context 非常适合作为微服务边界，但很多时候人们低估了分布式系统的复杂性。如果您不具备需要此架构的可用性和性能要求，那么精心设计的模块化整体块可能只是完成这些工作的正确工具。
修改
如果您对DDD的战略部分感兴趣，那么必须观看Paul Rayner在DDDEU 16 here的演讲。
答案 1 :(得分：0)
DDD是一套促进团队沟通的方法。它与重构无关，而与架构有关。
答案 2 :(得分：-1)
我不知道这是否有资格获得SO，无论如何解释都是巨大的。这里没有“银弹”方法。我个人会尝试隔离组件，并逐个迁移到一个或几个新的Symfony应用程序。
DDD在那里不相关。您可以在Martin Fowler书籍中找到许多有用的模式/方法，尤其是“重构”和“企业架构模式”。