在NORBIT，我们处理SRM解决方案。今天，我们将向您介绍我们团队的一个特殊项目-NBT BPMS平台的开发。我们不仅为客户创建了业务解决方案，而且还从头开始开发了自己的产品-所有这些都意味着采用完全不同的方法来进行设计，开发，团队管理，变更交付流程的组织和发布计划。
通常，本文不仅涉及美观的KDPV。您还将学到：
- 关于我们在设计微服务架构方面的经验（工具的选择，使用这些工具的方法，即对其使用的抽象）；
- 关于解决方案中业务对象设计者的开发和业务流程设计者的实现，以确保低代码开发的方法；
- 关于我们如何组织该项目的工作，以及如何在系统上工作时使开发人员从一些常规或分散注意力的方面解救出来（抽象的服务间交互，代码自动生成，团队氛围）；
- 以及在困难时期帮助我们的模因。
我们在NORBIT公司的部门主要从事采购流程的自动化，为此在.Net平台上创建各种解决方案。
此类解决方案的开发始于ASP.NET WebForms，然后在ASP.NET MVC的基础上创建了这些解决方案的新版本。除了.NET的开发之外，我们已经并且仍然有其他项目和解决方案，但是.NET的开发约占该部门所有项目的80％。
ASP.NET WebForms和ASP.NET MVC的局限性表明，要使这些解决方案在这些平台上起作用，就需要在Windows Server家族的OS上进行部署，而在DB（数据库）端，要实现大量的逻辑，因此无法快速轻松地进行过渡。在MS SQL Server以外的DBMS上。在向家用软件的大规模过渡开始之前，这没有提供任何障碍和困难。
从2014年到2015年，IT市场开始非常认真地朝着替代进口的方向发展，而将我们的系统部署在符合新要求的操作系统和DBMS上的问题就非常迫切。实际上变成了问题编号1我们需要解决的问题，以便我们的解决方案可以长期满足潜在客户的需求。
同时，由于拥有强大的能力和相当庞大的.NET开发人员团队，因此开始开发不在.NET上的新跨平台内核似乎并不合理。开源.NET Core平台的发布对我们非常有帮助，包括因为它与Windows，Linux和macOS等操作系统兼容。 我们需要解决的
问题2是，大多数先前创建的解决方案都假定必须进行编程才能添加业务对象的属性或更改系统中的业务流程。
它与两个方面有关。
- ( ) - , , , . , , - , , -.
- Low-code development, , , « » - -.
和题号3，这是我们一直面临很多年了，是正在创建的系统架构的缺陷，不允许迅速重写一些部分，而无需重新编写单独的模块，或者创造了程序员，分析师和连接到当测试者足够高的进入门槛项目。
在项目的入口处还有很多问题，将在后面讨论。但是这三个方面（导入替代和开放源代码，低代码，较低的进入门槛和新团队成员的快速沉浸率）我们考虑了必须解决的关键问题。
设计
对这些问题的思考使我们意识到，我们需要一种构造函数，分析师可以根据客户的需求“玩”并设计一个系统（业务对象和业务流程）。听起来很勇敢，但是比为客户编写另一个系统要有趣得多。实际上，我们决定以构造函数的形式制造我们的产品并进行开发。
我们绝对没有提出任何革命性的东西，市场上有很多类似的产品，但是对我们来说，解决累积的问题对我们至关重要，尤其是因为由于前面概述的原因，我们很难轻率地说很难遵循重构现有系统的道路。
在设计阶段，我们不得不重新考虑以下事实：我们并不总是事先知道谁是潜在客户，无论大小，要求或忠诚，他拥有什么业务流程，什么样的基础架构。未来系统的一些要求开始独立出现：您需要扩展，需要跨平台，需要灵活，快速地自定义业务对象/业务流程，接口，可能是集成的“手推车”。它变得可怕，非常可怕。
但是，正如我们的一位团队负责人所说，“大象需要从脚开始一点一点地被吃掉。” 在这个阶段，我们为自己设定了两个任务：选择微服务架构和选择工具。是的，马上就进行微服务（Martin Fowler建议使用MonolithFirst，但我们决定不服从他），因为使用Monoliths我们长期以来一直在“您”上，现在该接受继续前进的挑战了。但是，严重的是，我们认为仅对系统进行水平缩放就足够了。
选择架构和工具
在设计架构时，我们追求以下几个目标：
- 对所用工具的抽象化，以便能够随时用另一种工具替换不合适的工具；
- ( , );
- , .
由于我们的团队专门研究Microsoft技术，因此选择了.NET Core 2.1版作为实现平台。在开始开发产品时，此版本是LTS（长期支持），对我们来说这是一个重要的标准，因为某些家用操作系统（我们可能在其上部署系统）仅支持.NET Core LTS版本。 ...
由于易于学习，他们决定在React + TypeScript中制作Frontend。我们决定推广开发人员的全栈方法。
我们决定使服务间通信同步，因为我们的呼叫链应该很短，并且服务间通信仍然是抽象的。服务通过抽象代理调用另一个服务。任何逻辑都可以包含在其中。在我们的情况下，这是通过服务发现通过http调用另一个服务。这样的设计一方面使我们能够简化开发人员的工作（他们可以简单地使用服务接口来调用它，但是实际上，在ASP.NET Core服务容器中，该接口的注册实现是相同的Proxy），另一方面-自动提供系统的水平扩展，因为我们总是询问Service Discovery如何调用服务，从而可以提供该服务的一个正在运行的实例。
在某种程度上，服务结构已成为标准，我们对Visual Studio进行了扩展，当将新项目添加到解决方案中时，Visual Studio会再次生成具有最少服务实现的项目结构，从而使开发人员不必执行此例程。除此之外，我们还制作了一些脚本，只需稍稍动一下就可以启动整个系统（后来，我们考虑从开发人员那里快速部署轻量级的编排器）。
选择过程也很有趣。我们必须决定自己编写哪些功能以及“开箱即用”（谈论现有工具），但是，当然，要抽象出所有与之交互的功能，以便在必要时可以用另一种实现替换此工具或库。我们需要以下工具：搜索引擎，业务流程引擎（BPMN引擎），服务发现协议（服务发现），调度程序。标准是不同的：许可证，工作速度，项目团队的沉浸速度等。结果是以下列表：Elasticsearch，Camunda，领事，Hangfire。
他们立即放弃了对至少PostgreSQL和SQL Server的支持，但主要关注PostgreSQL和Linux下的部署。您知道免费软件。在这方面，发生了一个奇怪的故事。我们在早期阶段就停止了对SQL Server的支持，但是并没有真正期望我们的某些潜在客户会对在Windows + SQL Server上进行部署感兴趣，因此我们将测试此配置推迟到以后（毕竟，始终事先知道该客户所处的环境是什么！！） ...然后有一天，我们为潜在客户提供了另一个测试平台，我们已经准备好像往常一样部署AltLinux + PostgreSQL，但是突然我们发现客户仍然改变了主意，决定在Windows + SQL Server上进行部署，我们有两天的时间要做所有事情准备。幸运的是，长期编写且被遗忘的代码派上了用场，他们通过一些小的改进就为我们提供了此支持，并且我们设法按时准备了一切，并且该系统正常工作，好像什么都没发生（.NET Core的荣耀）。
实施经营理念
我们通过准备好的工作阶段清单来进行实施，其中最重要的是在不久的将来获得MVP（最小可行产品）。几乎从第一次迭代开始，我们就开始着重于尽快获取原型，并通过可视化部件定期向客户（最初是我们的领导者）进行演示。正如所期望的，这种方法有助于重新思考一些先前构想的概念。我设法抓住了一些矛盾并提前进行了斗争。这是关于设计用于前端和后端通信的Web API。
业务对象构造函数
上面已经提到该产品的关键思想之一是配置者可以创建业务对象结构的能力。我们实际上从业务对象的构造函数的实现开始。当然，第一个版本更具概念性，但随后为我们提供了丰富的思考空间。曾经朴素的业务对象具有几个简单的领域，后来演变为具有各种设置的多层多功能单元。我们学习了如何不仅自定义简单字段，而且还自定义字段，这些字段可以从分层目录，具有过滤功能的对象的相关集合等中进行选择。
通过配置器的鼠标生成的业务对象具有足够的元数据，以能够收集自定义可搜索注册表和不同的表示形式。
验证业务对象的问题也没有使我们幸免。我们很快发现，验证必须伴随着用数据填充业务对象阶段所需的业务逻辑。“如果“字段1”具有“值1”，则“字段2”需要隐藏”或“字段1是字段2和字段3的总和”只是可以给出的两个最简单的示例。这有多短，我们现在有了一个事件引擎，可以在其中配置这种行为。也可以使用鼠标配置事件。已经实施了许多选项，包括复杂的计算。但这是另一个对话的主题。如果您解决了类似的问题，请在评论中写下内容，以交流感情将很有趣。
业务流程设计师
正如我们要重复的那样：“谁需要没有业务流程的业务对象？”
结果
自项目开始以来已经一年半了。团队人数增加了十倍，
的第一件事是，我们拥有的功能越多，我们得到的想法就越多。感觉好像我们不是从项目的开始到完成，而是从头开始，甚至更进一步-这是一个重要方面。经过多年的支持现成的解决方案（这在IT专家的生活中经常发生），这种状况非常有启发性。
第二超级感觉是观看这样一个有动力的团队并加入其中。创建新产品的过程不仅是一系列任务和阶段。首先，这是气氛。尽管您参与了许多项目，但您经常会做从未有过的事情，这一事实的氛围。每个团队成员都将其呼吸，并在某时意识到他在第一次呼吸后离开了舒适区。而最困难也是最主要的任务是使这种气氛清新，舒适和有趣。我们无法躲避错误，截止日期等，但是缺乏一个大家都能发现自己的支持性环境的破坏力更大。
我们尝试特别注意我们产品的开发过程。此过程不是静态的。如有必要，他可以进行一些更改，但是他可以轻松地解决自己的问题并帮助他的同事。
PS很难在一篇文章中详细描述所有内容，因此事实证明它是更多概述。我们真的希望您能从中找到一些有趣的东西，我们很乐意在评论中回答您的问题，或者在另一篇文章中更详细地描述系统的某些方面。