软件应用程序设计的现有设计环境

软件应用程序设计的状态目前是主观的。 可以定义一组松散的汇总，例如设计原则，常见问题的设计模式，预定义的体系结构，这些汇总可以汇总到设计应用程序中，但是不存在标准化的设计策略。 通常，软件的弹性和灵活性在很大程度上取决于设计应用程序的架构师。

现有的一些设计策略包括面向对象设计的SOLID，功能设计概念，java结构模式，行为模式，基于流程的设计，基于微服务的设计，MVC设计模式等等。 可以看出，它们中的每一个都应用在应用程序设计的某些部分，并且需要将它们中的多个结合起来以实现完整的应用程序设计。

现有设计景观的缺点

当存在如此高度主观的环境时，很难强制执行可以客观地遵循的标准以防止软件质量随时间流逝。 因此，可以观察到，当应用程序处于起步阶段时，只有少数几个核心架构师在进行设计，因此它可以保持对所制定原则的高度一致性，但是随着应用程序功能和时间的扩展，设计会不断发展。原则被抛弃，添加了快速修复程序，并且很容易违反了模式并将其用于非预期目的，从而快速降低了应用程序的质量。

随着SaaS的引入，当前的软件应用领域正在Swift变化。 该软件的功能需要尽快发生变化，以确保在对该功能进行全面开发之前，可​​以在市场上对其进行测试。 还可以看到，随着产品在市场上的部署，获得了需要快速适应软件以研究功能采用情况并逐步进行修改的知识，以便可以删除较少使用的功能并开发受欢迎的功能。为更容易采用。

仅通过使用WYSWIG工具进行软件开发即可生成如此设计的代码，才能实现这种快速性。 但是，如果设计方法本身不依赖于功能，并且所定义的现有原理和模式是针对面向技术的问题而不是面向功能的，那么开发WYSWIG工具就很遥不可及。

所需要的是在与定义的业务需求相关的各种设计级别上进行软件设计的标准化策略，以便一旦完成这样的设计，就可以自动生成代码，从而缩短上市时间。 因此，对各种功能更改进行试用仅是更改需求的问题，然后生成适当的代码。

使用FSM进行标准化设计

什么是有限状态机？ 来自维基百科：“这是一个抽象机器，在任何给定时间都可以处于有限数量的状态之一。” 我们如何在应用程序设计中使用它？ 应用程序具有多个可以适应有限状态机的业务数据对象。 例如，运输管理系统具有一个称为“运输”的主要业务对象，该对象基于现实生活中发生的事件在应用程序中经历各种状态。

大多数应用程序都固有地嵌入了状态机。 只是它没有以这种方式明确设计为利用状态机的优点。 例如，“运输”对象通常具有“状态”字段，并设置为各种字符串，例如“已创建”，“正在加载”，“在途”等，直到达到“完成”状态。 开发人员在处理程序中为更改对象状态的请求手动设置此设置。 对代码的高级了解并不能清楚地说明“装运”对象将通过的各种状态以及改变“装运”对象状态的各种事件。

那么，当我们不认识业务对象的状态机时，我们会损失什么呢？ 即使在状态机中，我们显然也会添加“状态”列并进行适当的更新？ 业务特征和功能根据业务对象的状态进行操作。 通过将重点从此转移出去，我们已经在接近业务功能的设计和编码与接近技术的设计和编码之间交换了优势。 这使我们花费了将需求从面向业务的设计转换为面向技术的设计所需的时间。 技术设计给我们带来什么优势？ 为什么我们需要这个中间步骤？ 为什么不将业务需求用作编码设计？

PoC It Online基于一个平台，该平台固有地支持基于状态机的设计，这使其易于生成代码。 现在在这里尝试。

翻译自: https://www.javacodegeeks.com/2019/02/software-application-designing.html