我目前有一个客户端希望我从现有代码中“抽象”出一个域模型，但他们明确表示我不应该重构现有代码本身。我的问题是1）这是否可取; 2）如果您不能重构代码但是他们希望您为它提出一个模型，那么您将在这种情况下应用哪些技术？
（编辑：我不能完全指责它，但不知何故，在这种情况下无法重构只是感觉不对。还有其他人遇到过这种情况吗？）
答案 0 :(得分：1)
这听起来几乎不可能实现。
你能做到的唯一有限的事情可能就是满足他们想要的东西，就是重组你的项目/集会，以引入适当的大家庭。
根据您的描述，我想象一个大型代码库，其中包含一个程序集中的所有内容，可能是业务逻辑类与数据访问类并列，如果您真的不走运，甚至可能是UI代码。
通过将所有业务逻辑移动到引用数据访问逻辑的自己的程序集中，您可以引入（非常差）域模型的近似值。
这样做，您只需要更改类的引用方式，而不是更改现有代码。 然而你没有域模型......你有一个组件，其中包含域逻辑。
如果没有重构，引入正确有用的域模型是不可能的。该过程的重点是识别您正在表达的实际业务实体，然后在域模型中反映这些实体。这将需要引入新的类，提取方法，摆弄你的抽象。 （这只是过程的开始）
在看到您的评论之后，我认为值得一提的是两种方法明确地处理不断发展的代码库中的遗留代码问题。
这两种方法都可以帮助您实现客户所要求的目标。我仍然支持我的主要答案 - 你没有介绍域模型，但这可能是创建一个有用的域模型的第一步，不需要对遗留代码进行重大改写。
这里的想法是你在一个现有的应用程序上构建你的新应用程序，就像藤蔓一样，慢慢地围绕着它，然后在替换原始应用程序时将其删除。
故意这是一个缓慢的过程，降低风险并逐步淘汰遗留系统是可以理解的。
有反腐败层here的说明。主要思想是在遗留代码上创建一个界面，管理并保护您的域模型免受复杂性的影响。