Why DevPrime

DevPrime® is a product to support the modernization of applications and the development of Event-driven, Cloud-Native Microservices and APIs, providing a Stack with accelerators, ready-made functionalities, software architecture strategies and application engineering, making the development of complex software scenarios and Digital Transformation accessible.

DevPrime® is made up by DevPrime® Stack, DevPrime® Middleware, DevPrime® Pipeline, DevPrime® Foundation, DevPrime® CLI, DevPrime® Startup that together make it possible to develop Cloud-Native Microservices in 30 minutes, following the best practices in software development, High-Performance and High Availability Applications.

New projects based on DevPrime® technology natively incorporate the Event-Driven Architecture (EDA), non-blocking and Stateless approaches, including Standardization, Decoupling, Maintainability, Reuse and Testability practices, promoting a new culture of excellence in software development.

For each new project, the software developer will have at his disposal a Microservice application ready as an initial project. DevPrime® Stack provides several Adapters (Web, Security, Observability, Heath Check, Services, Stream, State and App Center) with common resources leading to savings of about 60% to 70% of the investment in the foundation of the software project, as shown in Figure 01, increasing productivity in software development teams and reducing project delivery time.



1aa94cfe77491c80f15bd4f1c98ea2d4_html_9c188dff

Figure 01 – An initial view of DevPrime® and its features.


To support the common Event-Driven Architecture scenario in the Microservices universe, DevPrime® Stack provides the Stream Adapter, which offers connectivity with major Stream / MessageQueue platforms such as Kafka, RabbitMQ, Azure Service BUS, AWS SQS, and more, simplifying the adoption of the Event-Driven Architecture strategy and making it possible to change the Stream with a simple configuration parameter.

New challenges in applications require a modern approach to data persistence following the "Polyglot persistence" strategy, according to the business context of the application. In this scenario, DevPrime® Stack provides the State Adapter, which connects to database platforms such as SQLServer, MongoDB, Redis, and others.

When exposing the APIs using the Web Adapter, either by gRPC, HTTP or GraphQL, it is vital to worry about the security of access externally, internally and between Microservices. The Security Adapter simplifies security by integrating with identity providers such as Identity Server, Azure AD, Amazon Cognito, among others.

DevPrime® Stack offers in Adapters Stream, State and Services Retry, Resilience and Automatic Circuit Breakers mechanisms, as shown in Figure 02, preparing applications for failure without any need for additional code implementation, and enabling for a "Distributed Systems" context.



1aa94cfe77491c80f15bd4f1c98ea2d4_html_eb876d53

Figure 02 – A view of native DevPrime features


Another common challenge in distributed applications is the availability of a structured and standardized Log that allows tracking a distributed transaction among all Microservices. The Observability Adapter on DevPrime® Stack automatically offers Logs, Tracing, and Metrics pillars together with DevPrime® Pipeline and DevPrime® Middleware standardizing information exposure to Site Reliability Engineering (SRE) teams to ensure service availability.

Traditional projects have a hard time switching people due to the absence of a strategy in the development of business rules. It is common for a professional who has switched projects to waste weeks to understand how the new project is structured.


In DevPrime® Domain, we offer a structural approach involving software strategy, design standards and Software Architecture with the objective of defining the organization of the source code making it common to everyone in the project.

The acceleration of Digital Transformation and popularization of Cloud Computing services has propagated strategies such as Cloud-Native, which aims to enable transparent portability of applications between cloud providers. Applications based on DevPrime® are Cloud-Native by default and can be published in On-Premises environments with Docker/Kubernetes or Cloud (Microsoft Azure, Google Cloud, Amazon AWS, SAP Cloud, among others).


DevPrime® Stack

DevPrime® Stack is the core component of DevPrime®, it provides a foundation with resources that support the structure of software projects by accelerating the modernization of applications. The technology is based on the standard in SOLID, Clean Code, Hexagonal Architecture, and Event-Driven Architecture, providing decoupling, testability and maintenance cost reduction, in addition to a number of features made available through Adapters, as shown in Figure 03.



1aa94cfe77491c80f15bd4f1c98ea2d4_html_6fd4acee

Figure 03 – A view of all the layers available on DevPrime® Stack


The Domain and Application layers focus on business rules and exposure by the application service, providing predictable behavior by using the Domain Driven Design (DDD) approach and its transformation into DevPrime Foundation native classes source code. The Domain project compiles and operates independently from other projects in order to ensure maintainability and testability.

DevPrime® Middleware is responsible for the integration of the developer's code with DevPrime® Stack and related services such as Resilience, Retry and Circuit breaks that are executed in a scenario of failure in the application's execution flow, automatic logs, error handling, and other DevPrime® features.

Adapters provide a set of services for the foundation of the application (Web, Security, Observability, Heath Check, Services, Stream, State and App Center) and are responsible for the technology aspects offering accelerators with intelligence and autonomous behavior as detailed below: Web Adapter This feature provides exposure of APIs, Web Views and static files with support for gRPC, HTTP, GraphQL communication. The APIs follow the OpenAPI Specification and are exposed using the Swagger standard and are ready for direct integration with the Gateway API of choice.


Security Adapter

This feature supports Open ID and OAuth 2 protocols, ensuring security in APIs exposure and internal communication between Microservices, making transparent the integration with identity providers such as Identity Server, Azure AD and Amazon Cognito.

Observability Adapter

This feature automatically supports the three Logs, Tracing and Metrics pillars used by Site Reliability Engineering (SRE) teams. Logs are structured to be easily indexed in tools such as ELK (Elasticsearch, Logstash and Kibana). Trace follows the Distributed Tracing / Open Telemetry pattern, allowing visualization in tools like Jaeger, among others. It is also possible to provide customized metrics to support the business in Prometheus format.

Health Check Adapter

This feature checks the availability of the application, allowing container orchestrators such as Kubernetes to monitor the health of the container and restart it if necessary.

Services Adapter

This feature simplifies communication with external services using gRPC, HTTP or GraphQL standards, making it easier for software developers to work with automatic Retry and Circuit Break routines, preventing integration failures from damaging the application by aggregating process resilience, standardization and the best use of resources.

Stream Adapter

This feature provides support to the major Stream services for issuing and receiving events with the main technologies on the market, such as Kafka, RabbitMQ, Azure Service BUS, AWS SQS and automatic mechanisms of Retry, Circuit Break and Resilience that come into action in case of failure. No additional implementations are required, just modify the settings and choose the Stream of preference.

State Adapter

This feature supports modern approaches to persistence following the "Polyglot persistence" concept such as SQLServer, MongoDB, Redis and others. The software developer may choose to use native database code, EF (Entity Framework) or Dapper. Retry and Circuit Break routines are automatically triggered in case of failures.

AppCenter Adapter

This feature provides integration with DevPrime AppCenter to obtain information from Microservices, modify distributed real-time settings, and application statistics.

DevPrime® Domain DevPrime offers a structured approach, allowing the development of business rules in the Domain Driven Design (DDD) standard and defining a predictable behavior in the understanding of the business rules, decomposition and structuring of the source code.

By adopting this strategy, it is possible to switch people between different projects with ease, collaborating with the scalability of development teams and SQUADs.

After the business analysis and identification of the Bounded Contexts, Context Map in a "Strategic DDD" journey, the project team, together with the business representatives, conduct a "Tactical Design" journey defining the Aggregate roots, Value Objects, Entities, Domain Events, Handlers, Domain Services and Application Services that are standard terms of Domain Driven Design (DDD) and available at DevPrime® Foundation for use in the development of business rules as presented on Figure 04.



1aa94cfe77491c80f15bd4f1c98ea2d4_html_dea1dcc7

Figure 04 – Transparent compliance with Domain Driven Design (DDD)


In practice, regardless of the application, the business context (Bound Context) will be developed as standard in the project called "Domain", allowing to isolate the business rules and simplify maintenance and testability.
This approach favors the practice of Test-driven development (TDD), allowing the development of unit tests and its use in Continuous Integration (CI) and DevOps scenarios.
Another important benefit in the organization of business rules is the structuring of a service stoppage, contributing to the reuse of resources that are made available through APIs and/or components, increasing productivity and reducing rework.
DevPrime® Pipeline Applications developed with the technology provided by DevPrime® are natively based on Event-Driven Architecture and receive external events (Driving Adapter), issue internal events in the "Domain Events" business layers, and propagate events externally (Driven Adapter) to other applications as demonstrated in Figure 05 .

With each new event in the application (Request/Event), DevPrime® Pipeline runs in an independent, parallel and controlled flow propagating between the layers of the application. This process occurs in stages, allowing it to be tested in an isolated way and, in case of failure, it does not jeopardize the processing of other events.



1aa94cfe77491c80f15bd4f1c98ea2d4_html_b2f6f79

Figure 05 – Demonstration of simultaneous flows in DevPrime® Pipeline


Any application flaws generated by business or technology errors are automatically intercepted by DevPrime® Pipeline and returned without the need for additional implementation or failure in the main process.

DevPrime® CLI

DevPrime® CLI (Command Line Interface) or "dp" is a tool that provides accelerators for common routines in software development, providing a huge productivity gain in projects based on DevPrime®.

To start a new Microservice, just run the command "dp", as the example in Table 01 and create a new application based on the DevPrime® Startup model. In this example, we're informing the name of the new application, the type of Stream service as "Kafka" and State as "MongoDB" for the database.


dp new Order --stream kafka --state mongodb

Table 01 – Creating a new Microservice Every new project created by CLI follows the DevPrime® Startup model. In Figure 06, it is possible to follow the excursion of the command "dp" by the CLI for the creation of a new Microservice application project. New Microservice applications created using DevPrime® already receive a complete and functional foundation, speeding up software development.



1aa94cfe77491c80f15bd4f1c98ea2d4_html_444d66f6
Figure 06 – Creating a new application

After the CLI is completed, you can open the project shown in Figure 07 and view the features of DevPrime® Stack and its accelerators. Stack allows to activate new functionalities from the application configuration file and the CLI if necessary.



1aa94cfe77491c80f15bd4f1c98ea2d4_html_9ba6a9b4

Figure 07 – New project created through the CLI.


The new Microservice "Orders" application is a finished project and can be executed even without the business rules, according to the Log presented in Figure 08 and will follow the Log automatically generated by the Observability Adapter, demonstrating the start-up of the application. In the context of Microservices, the Log is the screen of your application.



1aa94cfe77491c80f15bd4f1c98ea2d4_html_f72751ee

Figure 08 – New project created by the CLI.


The new Microservice created earlier already natively has a "HealthCheck" API exposed in the OpenAPI / Swagger standard by the HealthCheck Adapter as shown in Figure 09 .



1aa94cfe77491c80f15bd4f1c98ea2d4_html_d3a3ccdb

Figure 09 – Running Microservices and viewing the API.


The next step is to include the business rules in the Domain layer and use a DevPrime® CLI accelerator, according to the example shown in Table 02 to read the business rules in the "Domain" project and automatically build the code components in the architecture, such as Application Services in Application, Handlers in Application, Domain Services in Domain, Domain Events in Domain, Repositories in State, Controllers in Web, and Unity Tests in Test, as shown in Figure 10 .



dp init

Table 02 – Using the command “dp init”.



1aa94cfe77491c80f15bd4f1c98ea2d4_html_317775f8

Figure 10 – Analyzing the business rules of "Domain".


By completing the implementations provided by DevPrime® CLI, it is possible to advance many stages in the development of the application and have a direction in the software architectural standards by following the best practices. The source code presented in Figure 11 and made available in the layers (Web, State, Services, Application, Domain, and Tests) communicates with DevPrime® Stack and is available to be evolved by the software developer according to the project needs.



1aa94cfe77491c80f15bd4f1c98ea2d4_html_11f1c4fe

Figure 11 – Source code provided by DevPrime® CLI.


DevPrime® CLI also provides suggested unit tests created as shown in Figure 12. The testing model reflects the business rules represented in the Domain and the various layers of the application, characterizing the basic life cycle of the domain objects, acting as a reference for software developers to complement with new Unit Tests, considerably increasing the quality of the software developed.



1aa94cfe77491c80f15bd4f1c98ea2d4_html_2df33612

Figure 12 – Unit tests project.

When running the application again it is possible to see the new endpoints representing the Bounded Context "Orders", as shown in Figure 13. This application can already be tested locally or transformed into a container image published in Docker/Kubernetes. DevPrime® APIs are exposed in a Gateway API preferably following the Open API standard.



1aa94cfe77491c80f15bd4f1c98ea2d4_html_5a6fe84e

Figure 13 – Viewing the APIs displayed in the Web.


Adapter By performing a post in the API on /v1/Orders, the application will process the related business rule and generate an internal "OrderCreated" event that will be intercepted by Handle, as shown in Figure 14. This strategy in the architecture is critical to maintain the decoupling of business rules.



1aa94cfe77491c80f15bd4f1c98ea2d4_html_4c1a16c8

Figure 14 – Running a Domain Event


The example source code presented in Figure 14 also demonstrates the use of DevPrime® Stack to include an additional Log, persist the business object using Adapter State (MongoDB), and issue an external event called "OrderCreated" using the Adapter Stream (Kafka).

The complete request flow is automatically logged by DevPrime® Stack, as demonstrated in Figure 15, providing a unified Observability experience across all applications. The entire application flow is recorded via automatic Logs without the need for implementation.



1aa94cfe77491c80f15bd4f1c98ea2d4_html_8f3e02fe

Figure 15 – Processing a Request, persisting and issuing an event.


The CLI offers other additional features that can be viewed directly from the command line. This tool was created to support the common routines in the daily life of the software development professional. Retry, Resilience, and Circuit Breakers In the current context of Microservices involving Distributed Systems, it is vital to adopt strategies to make applications resilient to possible failures. In all DevPrime® applications, Retry, Resilience and Circuit Breakers services are automatically triggered according to the context, with no need for additional implementations.

In the example shown in Figure 16, the Stream Adapter, using its own intelligence, detected a connection failure with the Kafka service and automatically executed a Retry service. As the attempts failed, a Circuit Breaker was generated and right after, the automatic resilience process preserved the event in a Storage to be retrieved later after Kafka's recovery. In case of new events during Circuit Breaker "ON" they follow the same process, ensuring resilience at a time of failure.



1aa94cfe77491c80f15bd4f1c98ea2d4_html_96eb5aec

Figure 16 – Demonstrating the Circuit Break strategy.


Upon realizing the connection feedback with Kafka, the Stream Adapter changed the Circuit Break to "Off" and the resilience process issued the pending events without the need for any additional coding. The Circuit Break is an intelligent mechanism to protect your application from failure scenarios of a given resource, allowing you to protect it from failures, so, you have time to improves its availability.

Observability (Log, Trace, Metrics)

DevPrime® offers an automatic structured and distributed Log approach between different applications, as well as Trace distributed in the Open Telemetry standard. In this scenario presented in Figure 17, it is possible to visualize the Microservice "Orders" emitting the event "OrderCreated" that will be propagated by Stream using Kafka.



1aa94cfe77491c80f15bd4f1c98ea2d4_html_39601586

Figure 17 – "OrderCreated" event issued at Microservice "Orders".

On the other side, in Figure 18, is the Microservice "Payment" that hosts the event through Stream and is also connected to Kafka. The event is processed internally by "Payment", following the usual business flow.




1aa94cfe77491c80f15bd4f1c98ea2d4_html_3f18cf2f

Figure 18 – "OrderCreated" event received at Microservice "Payment".


The DevPrime Logs, even in different applications, communicate with each other, allowing the indexing of the entire transactional flow. This same distributed view can be followed by the Distributed Trace, as shown in Figure 19, with the view of the Jaeger tool that supports the Open Telemetry protocol.



1aa94cfe77491c80f15bd4f1c98ea2d4_html_53fa5bf1

Figure 19 – Visualization of Distributed Trace in Jaeger Tool.


A great challenge in the scenario of distributed applications is precisely the monitoring of applications. In this new context, you will have to deal with one or thousands of replicas and you need to have the resources to identify a problem quickly and respond with a solution, ensuring the availability of the service.


DevPrime® Distributed Services (DDS)

A common scenario in Microservices and distributed systems is the concept of asynchronous applications, issuing events and independently processing. By using DevPrime® Distributed Services (DDS) it is possible to create a transactional flow between the Microservices involved, allowing to control the distributed transaction with simplicity and transparency. DevPrime® Distributed Services (DDS) simplifies the management of distributed transactions between Microservices, using the SAGA Pattern (Orchestration / Choreography) approach in the orchestrated standard. This orchestration model ensures decoupling between Microservices and control of the Rollback process, allowing you to trigger transaction compensation in case of failure and view the entire transaction flow. To include the Microservices in the orchestration process it is enough to change the management flow in Distributed Services and relate the events that this new application must interact. Each participating Microservices implements its internal transaction process and, when necessary, compensation. DevPrime® Distributed Services (DDS) is an Event-driven, Cloud-Native Microservices application developed using DevPrime® technology and works as an optional plugin, simplifying distributed transaction orchestration in the context of Microservices. DevPrime® AppCenter DevPrime® AppCenter provides a dashboard for viewing services such as DevPrime® Distributed Services (DTS), allowing you to observe information from transactions distributed among Microservices, as shown in Figure 17 . AppCenter also provides a config server service to centralize the application settings, analytic dashboards with important business data and technical information obtained from the applications.



1aa94cfe77491c80f15bd4f1c98ea2d4_html_d5ed54e7

Figure 17 – Distributed Services Panel.


DevPrime® AppCenter is an Event-driven, Cloud-Native Microservices application developed using DevPrime® technology and works as an optional plugin complementing the management of implemented Microservices.

TITLE