在本文中，我将以我的项目的演变为例，向您介绍合同编程的过渡历史和愿景。
首先，我想命名为“合同编程”，因为所使用的方法是将所有业务逻辑划分为数据合同和使用这些合同并通过这些数据结构进行交互的服务客户端。该结构已在不同服务中成功处理。
我会用自己的语言来描述。
我过渡到合同编程的故事始于我在同一个业务领域中拥有一个杂草丛生的旧项目，该项目具有大量不同功能。 另外，所有这些仍然是针对不同客户端的多线程和自定义。 具体来说，业务领域是在会计系统，文件和云服务之间交换与法律相关的电子文件。
在开发系统的过程中，出现了新的业务需求，结果，该项目迅速发展，并因新功能而变得复杂，这在某个阶段导致项目的体系结构开始类似于具有相关功能的多个独立应用程序。 仅从非通用元素而是从不同程序集和名称空间中相似但实现不同的结构中实现了此功能。
在视觉上，这样的架构可以表示为功能的多个垂直方向
这种体系结构的一个特征是，如果出现任何其他要求或错误，则需要在系统的所有“功能模块”中而不是在一个区域中实施这样的任务。 另一个特征是项目中存在大量的建设者，这导致了业务领域的这种垂直划分。 开发人员在构建者的代码中实现了针对新业务需求的新算法，这导致了针对同一业务对象具有不同结构的新实体的出现。 诚然，与使用意大利面条式代码的简单代码隐藏方法相比，可以认为该方法更面向对象。 因此，如果您在项目中看到大量的构建者，那么过渡到联系方式将简化支持并加速项目的开发。
有一次，在公司，我们面对这样一个事实，即与我们一起实施的客户开始表示，我开发的系统经常会产生错误。 我不能对此表示怀疑，尽管错误会定期出现，但是它们已得到修复，并且某些客户端已安装并使用了该系统。 我必须说谢谢您，客户是有害且挑剔的，并且在实施期间非常仔细地测试了我们的系统。
我自己也不喜欢这样的事实，尽管付出了很多努力，但我没有足够的时间进行开发和支持，而且在某个时候，我根本不知道还有什么可以改进该系统并使它更稳定。
这个决定是突然而出人意料的。
我很好地理解，同一业务对象在系统的不同模块中以不同的方式实现-不同类型的文档，收据，工作人员，服务客户端，数据库客户端，文件客户端，并且能够以各种格式存储文档（为不同的客户端定制）。 ）
逻辑的一部分在实体中实现，这阻止了在不同算法中使用相同的实体。
然后我决定-有必要创建一个像单个构造函数这样的东西，并带有详细信息，从中可以组装系统中实现的所有算法。 这是合乎逻辑的，因为它减少了相似类的数量，并简化了支持。
我决定严格将申请的“宇宙”划分为
- 数据合同 -包含且仅用于数据存储的数据结构
文件
信封
收据
FL
...
- clients-services-我专门写来客户就是服务，因为当实现在业务领域中交互的每个系统时，我将其表示为该系统的信封，在其中实现了处理日期合同的方法。 除了这些类是服务的包装程序外，它们还包含必要的绑定逻辑，转换和转换，以简化业务逻辑
此外，记录器还坚持使用这些客户端。 这样您就可以通过日志快速找到错误点。 （将来，当日志记录使用户自己开始了解错误的地方-文件系统，网络，会计系统或运营商的Web服务时，许多呼叫消失了）
举个例子
CloudClient-向其发送和处理文档的云服务的客户端
-下载
-发送
-获取
-下载
-同意
...
FileSystemClient-文件系统客户端
ERPClient-客户会计系统
客户在所有模块中实施了以前在算法中使用的所有方法，从而可以快速，轻松地从同一部分实施新实施的算法。
并且在各个客户端中分配相似的功能方法导致了代码的更大专业化和重用。
现在的架构就像图中的示意图
在SDK（软件开发人员工具包）的末尾，我将设计人员的所有基本对象分配给了程序集，从而使工作变得更容易，最重要的是更加愉悦。 我的工作已经不再是创建拐杖和临时解决方案了，现在，由于我现在看到了大量的可伸缩性和竞争性架构，因此从内部对项目的态度变得更加认真。 这是因为这样的事实大大增加了动力并开辟了新的专业视野。
在创建的SDK的基础上，我移交了一层业务逻辑，以实现直接执行直接业务任务的自动化。 由于所有技术细微之处都被带到了位于客户端的较低层，因此简化了相同算法的实现，并开始显得更加令人愉悦。
该方法很简单，并且可以简化进一步的开发，非常重要的是增加体系结构的灵活性。 是的，这将需要大量的重构。 就我而言，以狂热的方式花了2周的开发时间。 但是在那之后，我几乎没有编写代码，因为一切都稳定进行。
并且由于职责分离（SPR）和日志的分离，我得以迅速抑制第三方服务的错误，这也使我感到错误。 以前，这需要占用大量时间的分析。
这种方法很好地用于某些层。 在应用程序的更高层上，贫血模型可能更方便，只有更好地实现基于合同方法的贫血模型。