我天生很兴奋在我目前的项目上练习DDD，所以我开始认识和修饰我们无处不在的语言，并为几个子域创建了实验域模型。但是，当我尝试实现某些setter和存储库时遇到了困难。
我希望我的域模型封装业务逻辑，但我限制在一个数据API上执行大部分业务逻辑，包括在另一台服务器上执行不变量。 API也不会在普遍存在的语言所建议的粒度级别上公开模型和操作。业务逻辑所需的一些数据甚至不会被API公开。
这些基础设施问题有可能污染我的领域模型并使其变得贫血。构建反腐败层将是一项艰巨的任务，可能需要对API进行攻击。似乎我必须放弃DDD，而是建立一个带有服务类的贫血模型。这种情况应采用哪些原则，模式或做法？
我能找到的最好的是＆＃34;顺从者＆＃34;在Eric Evans＆＃39; 领域驱动设计：解决软件核心的复杂性。他将我的情况描述为上游/下游关系，其中上游没有动力提供下游团队的需求＆＃34;以及其中＆＃34;根据需要定制的界面下游团队不在卡片中。＆＃34;他建议，＆＃34;通过盲目地坚持上游团队的模型来消除[反腐层]的复杂性。＆＃34;
埃文斯继续承认顺从主义方法的陷阱。它：我希望得到进一步的了解，特别是对于这种符合性的有用代码/设计技术。