453 American Academic Scientific Research Journal for Engineering, Technology, and Sciences ISSN (Print) 2313-4410, ISSN (Online) 2313-4402 https://asrjetsjournal.org/index.php/American_Scientific_Journal/index Domain Driven Development — Changing the Philosophy of Working on a Project Kucheruk Artem* Senior Software Developer,Wells Fargo,Charlotte, North Carolina, USA Email:Artem.Kucheruk@wellsfargo.com Abstract The article examines domain-driven development (DDD) as a shift from technology-first delivery to business- first modeling with enforceable boundaries and contracts. The review integrates recent findings on bounded contexts, aggregate consistency, context mapping, and domain events with empirical results from microservice performance studies, event-driven pipelines, reactive execution, autoscaling, and overload control. In addition, the review positions CQRS as a complementary pattern to DDD: commands validate invariants within aggregate boundaries while queries rely on denormalized read models for independent evolution. The paper provides a decision aid for when CQRS improves throughput, traceability, and change isolation versus when a unified model remains simpler. The analysis consolidates a boundary-discovery workflow that couples collaborative modeling with data-assisted decomposition. A practitioner case with DDD reports shorter onboarding and faster delivery after establishing a stable ubiquitous language and context map. The manuscript includes an evidence-based interaction table, a governance table for documentation and operations, and a figure illustrating data-driven decomposition. The results target architects and leads who need reproducible criteria for partitioning, collaboration, runtime control, and team enablement across complex enterprise portfolios. Keywords:domain-driven design; bounded contexts; microservices; event-driven architecture; CQRS;autoscaling; overload control;context mapping; onboarding; runtime adaptation. ------------------------------------------------------------------------ Received: 9/19/2025 Accepted: 11/19/2025 Published: 11/29/2025 ------------------------------------------------------------------------ * Corresponding author. https://asrjetsjournal.org/index.php/American_Scientific_Journal/index American Academic Scientific Research Journal for Engineering, Technology, and Sciences (ASRJETS) - Volume 103, No 1, pp 453-463 454 1.Introduction Enterprise programs accumulate accidental complexity when service decomposition precedes a shared domain language. DDD reframes work around bounded contexts and contracts that match business semantics, reducing translation overhead between product intent and code. Teams face concrete trade-offs when binding these choices to interaction and execution styles: event-driven vs. synchronous calls, and reactive vs. imperative internals. A practitioner case reports onboarding acceleration and development-throughput gains after standardizing domain language and boundaries across teams. The present study systematizes peer-reviewed evidence from the last five years and relates it to operational controls that stabilize latency tails and preserve autonomy under burst and failure. Goal – to articulate how DDD changes project philosophy and to ground that shift in verifiable decomposition, interaction, execution, and governance practices and to situate CQRS alongside DDD as a disciplined way to separate writes from reads where product semantics and traffic profiles justify it. Tasks: 1) Consolidate a boundary-discovery workflow that combines collaborative modeling with data-assisted decomposition. 2) Derive criteria for selecting interaction (event-driven vs. synchronous) and execution (reactive vs. imperative) styles consistent with workload shape. 3) Specify documentation and runtime governance that sustain autonomy, testability, and onboarding. 4) Clarify when CQRS improves autonomy and scalability of read models without undermining transactional clarity of aggregates. Novelty. The manuscript links socio-technical DDD artifacts (ubiquitous language, context maps, ADRs) to measurable runtime controls (autoscaling, overload control, stream reconfiguration), offering tables and a decomposition figure that translate literature into design-time and run-time checklists, and integrating a CQRS decision aid tied to aggregate boundaries and read-model governance. 2.Materials and methods Sources used. G. Akdur [1] analyzes virtual onboarding dynamics in distributed developer teams and identifies drivers that correlate with retention and integration. L. Bacchiani [2] proposes proactive–reactive global scaling for microservices and evaluates SLO attainment against purely reactive baselines. M. Cabane [3] measures the performance impact of event-driven architecture under realistic workloads. V. Cardellini [4] surveys runtime adaptation in data-stream processing with classifications for elasticity mechanisms and evolution strategies. R. Maharjan [5] presents a case study on monolith-to-microservices decomposition with representation learning and clustering that recovers deployable service cuts. W. Meijer [6] experimentally evaluates architectural performance patterns (e.g., aggregation, pipes-and-filters) in microservices. K. Mochniej [7] compares reactive and imperative microservices, detailing throughput, latency, and memory characteristics. B. Özkan [8] delivers a systematic literature review of DDD practices and documentation needs. R. Bhattacharya [9] introduces client-side overload control with feedback to stabilize latency tails in microservices. S. Zbarcea [10] reports on migration from American Academic Scientific Research Journal for Engineering, Technology, and Sciences (ASRJETS) - Volume 103, No 1, pp 453-463 455 asynchronous multi-threading to reactive programming in Java with quantified resource-latency effects. Methodological approach. Comparative analysis, structured literature synthesis, and evidence mapping were applied to peer-reviewed works from the last five years (English-language journals/conference venues). Inclusion criteria focused on studies reporting measurable outcomes or taxonomies applicable to DDD-aligned decomposition, interaction, execution, and runtime control. Where CQRS is discussed in secondary sources and practitioner reports summarized by recent reviews of DDD practice, we extract criteria rather than tooling specifics and tie them to aggregate design and read-model evolution. 3.Results Domain-driven development (DDD) reorients software work from technology-first execution to business-first modeling and agreement on language, boundaries, and behavioral contracts. Recent syntheses confirm that contemporary DDD practice concentrates on bounded contexts, aggregate consistency, context mapping, and domain events as primary structuring devices, with widespread use in microservice programs and increasing attention to collaborative modeling workshops and documentation that preserve domain language over time [8]. Empirical evidence from microservice studies adds that architecture-level patterns alter runtime characteristics in measurable ways, so the “philosophy shift” must be assessed not only by modularity or comprehension gains but by latency, throughput, and resource profiles under realistic load [6]. Separation by business boundary and its operational effects. Systematic reviews depict DDD adoption as a way to align organizational teams and service ownership with coherent boundaries; results show frequent pairing of bounded contexts with microservice units, context maps to govern inter-service collaboration, and domain event streams to decouple change [8]. Where DDD is paired with event-driven architecture (EDA), controlled experiments report that asynchronous, event-mediated pipelines tend to cut tail-latency and improve elasticity relative to strictly synchronous request/response, while introducing messaging overheads and additional runtime components that affect cold-start behavior and memory footprints [3]. In microservices that apply gateway aggregation/offloading or pipes-and-filters—patterns often used to implement context integration—experimental evaluation finds pattern-specific performance signatures (e.g., bottleneck shifts after aggregation, resource- utilization inflection points under heterogeneous workloads), underscoring the need to treat architecture tactics as measurable interventions rather than generic best practices [6]. Case-study results on automated monolith-to-microservices decomposition using representation learning and clustering provide a concrete path to recover candidate service cuts that often coincide with DDD boundaries. The evaluated pipeline constructs entrypoint co-existence/existence matrices, embeds call-graph structure, and groups functionality into deployable units; authors report successful partitioning with face validity against business functions (Figure 1) [5]. American Academic Scientific Research Journal for Engineering, Technology, and Sciences (ASRJETS) - Volume 103, No 1, pp 453-463 456 Figure 1: Data-driven decomposition pipeline for identifying microservice candidates aligned with DDD boundaries [5] At the portfolio scale, state-of-the-art reengineering surveys consolidate techniques that mix static and dynamic analysis with domain knowledge to plan stepwise extraction, reinforcing the finding that boundary discovery benefits from both code-level signals and domain language [2]. Event-driven vs. synchronous collaboration across contexts. Controlled experiments on EDA quantify when event propagation outperforms direct synchronous calls: workloads with bursty fan-out see more stable response-time distributions and fewer incast-induced stalls under feedback-aware event pipelines, at the cost of extra broker hops and serialization overhead [3]. Complementary work on client-side overload-aware balancing for microservices shows that pushing load-shedding signals into the balancing layer stabilizes latencies and narrows tails without central coordination, supporting DDD’s preference for local autonomy between contexts during overload and failure [9]. The combined result suggests a modeling rule of thumb: define inter-context relationships by domain contracts first, then choose synchronous vs. event-driven interaction based on fan-out, back-pressure needs, and recovery semantics rather than stylistic preference [3, 9]. CQRS for write/read separation across domain boundaries. CQRS complements DDD by keeping command handling and invariant checks inside aggregates while allowing read models to denormalize, precompute, and scale independently. The pattern fits read-heavy products, multi-view UIs, auditability requirements, and long- running reporting where fresh writes do not require synchronous projection of every view. It underperforms when the domain relies on tight, synchronous read-after-write semantics or when the domain model remains small and cohesive enough for a single data model. Effective CQRS practice hinges on explicit contracts for read models (schemas, SLAs for staleness), idempotent projections, and backfills for replays; event publication is a convenient American Academic Scientific Research Journal for Engineering, Technology, and Sciences (ASRJETS) - Volume 103, No 1, pp 453-463 457 transport but not a prerequisite. Run-time adaptation for stream-centric domains. A comprehensive survey of data-stream processing identifies matured mechanisms for elasticity (operator migration, scale-out/in, topology reconfiguration) and classifies control strategies by triggers and objectives; these mechanisms directly support DDD designs that treat domain events as first-class data with isolation of stateful operators per bounded context. Results emphasize combining autoscaling with schema/version evolution and contract testing to curb ripple effects across context boundaries during adaptation [4]. Scaling and resource governance across contexts. Recent experimentation on proactive–reactive global scaling shows that orchestrators combining prediction with feedback reach target utilization with fewer SLO breaches and improved resource efficiency relative to purely reactive baselines; this supplies a runtime complement to DDD’s compile-time boundary contracts by preserving service quality during demand shifts without eroding ownership lines [2]. When DDD systems adopt client-side overload control and hybrid autoscaling together, studies report narrower latency distributions and more stable capacity planning, which simplifies domain-level SLOs associated with each bounded context [2, 9]. Human-centric outcomes: onboarding and model comprehension. A field study of virtual onboarding for distributed developer teams finds that structured knowledge delivery and tool readiness correlate with lower turnover intention and higher perceived integration; the introduced framework formalizes onboarding drivers and obstacles in remote settings [1]. Reactive execution helps when endpoints spend most of the time waiting on external I/O or multiplexing many slow upstreams; in compute-centric flows it rarely pays off. Treat reactive internals as an execution tactic subordinate to aggregate design and interaction contracts rather than as a universal baseline. Clear domain boundaries and stable language reduce support burden by shrinking translation work and unintended coupling across teams. Shared artifacts and explicit ownership structures correlate with higher day-to- day engagement in implementation, since decisions map cleanly to domain terms and are easier to defend in reviews. Synthesis for DDD as a shift in project philosophy. Across the reviewed evidence, the development flow moves from “implement features” to “consolidate domain knowledge, then implement” with measurable architectural consequences: i) boundary-first decomposition guided by domain language, supported by decomposition pipelines where needed; ii) interaction styles chosen to stabilize tail-latency and constrain coupling between contexts; iii) execution models selected per domain workload shape, with reactive pipelines reserved for high- concurrency I/O and imperative paths retained for transactional aggregates; iv) runtime adaptation and autoscaling layered beneath domain contracts to sustain SLOs without breaking ownership. American Academic Scientific Research Journal for Engineering, Technology, and Sciences (ASRJETS) - Volume 103, No 1, pp 453-463 458 4.Discussion The synthesis positions domain-driven development as a governance frame for aligning structural boundaries, interaction styles, and runtime control with the semantics of a business domain. Systematic evidence places bounded contexts, aggregates, and ubiquitous language at the center of successful programs and reports that teams sustain these choices by combining documentation with architectural mechanisms that protect autonomy during traffic and change surges [8]. Studies on microservice performance patterns and event-driven pipelines show that the philosophical shift only yields durable gains when decomposition and interaction tactics are paired with measurement-guided runtime controls; otherwise coupling reappears through hidden queues, ad-hoc gateways, and incidental synchronization [3, 6, 9]. These results justify treating DDD decisions as hypotheses that require both socio-technical validation (language, ownership, onboarding) and empirical verification under realistic load profiles. Within this frame, CQRS supplies a compact way to decouple read evolution from transactional integrity of aggregates, provided that projection lag and schema governance are treated as first-class operational concerns.From an interpretive standpoint, the consolidated evidence points to three clusters of outcomes that are directly relevant for practitioners. First, portfolio structure becomes more stable: services aligned with bounded contexts tend to evolve together, while cross-cutting changes decline as anti-corruption layers and contractual APIs mature [5, 8]. Second, runtime behavior shows narrower latency distributions and higher efficiency when event-driven pipelines, autoscaling, and overload-aware clients are configured in line with domain boundaries and traffic profiles rather than adopted as generic best practices [2–4, 9]. Third, team dynamics and collaboration outcomes improve when ubiquitous language, context maps, and ADRs connect architectural decisions to domain terms: teams report fewer misunderstandings in design discussions and smoother handovers between product and engineering [1, 8]. The practitioner program that motivated this review followed the same pattern: an initial phase of collaborative modeling and documentation was succeeded by gradual refactoring of services and scaling policies, which reduced unplanned cross-team escalations and produced a more predictable delivery cadence. Boundary discovery and the durability of service cuts. Data-assisted decomposition confirms that code-level signals and runtime traces can recover service candidates that frequently coincide with domain partitions. A case study using representation learning over dependency graphs produced groups with face validity against business functions, supporting a practice where exploratory clustering and event co-occurrence are used to challenge or corroborate workshop-derived boundaries before irreversible extraction steps [5]. Portfolio-level reviews argue for combining such analytics with stepwise re-wiring tactics and contract testing to avoid “big-bang” splits that later erode ubiquitous language with translation objects and brittle anti-corruption layers [2, 4]. In short, boundary proposals benefit from a two-pass approach: first by domain workshops and context maps [8], then by quantitative probes that detect cross-cutting hotspots prior to migration [5]. In relation to earlier studies, the present synthesis narrows several gaps that remain in the individual strands of literature. Özkan and his colleagues [8] chart adoption patterns for DDD and stress the need for sustained documentation, but they stop short of linking these socio-technical artifacts to concrete runtime mechanisms such as autoscaling, overload control, or stream reconfiguration. Cardellini and his colleagues [4] and Bacchiani and his colleagues [2] examine adaptation and global scaling for data-stream and microservice platforms yet treat domain modeling only peripherally. Meijer and his colleagues [6], Cabane and Kleinner [3], Mochniej and American Academic Scientific Research Journal for Engineering, Technology, and Sciences (ASRJETS) - Volume 103, No 1, pp 453-463 459 Badurowicz [7], and Zbarcea and his colleagues [10] focus on performance trade-offs for architectural and implementation styles, while Bhattacharya and his colleagues [9] investigate overload-aware load distribution, again without grounding these results in DDD constructs. By aligning these contributions around bounded contexts, aggregates, and CQRS-oriented read models, the present review offers a unifying frame in which findings from performance engineering, adaptive systems, and socio-technical onboarding research reinforce one another instead of remaining isolated observations tied to specific tools or platforms. Interaction styles across contexts: selecting for workload shape. Empirical studies of event-driven architecture (EDA) report more stable tail behavior in bursty workloads and under fan-out, balanced against broker/serialization overhead and operational components that affect cold starts and observability [3]. Pattern- evaluation work for microservices finds signature trade-offs for integration tactics (e.g., gateway aggregation vs. pipes-and-filters), implying that DDD’s context relationships should be mapped to interaction styles only after profiling expected concurrency, request amplification, and back-pressure needs [6]. Client-side overload control with feedback to balancers narrows latency distributions without central coordination, which preserves the local autonomy DDD expects between contexts during partial failures [9]. Reactive execution inside a context tends to reduce memory consumption and 90th-percentile latency for I/O-bound flows, while benefits shrink or invert for compute-bound paths and complex read patterns; migration studies caution against blanket adoption and recommend targeted application where concurrency and waiting dominate [7, 10]. Table 1 summarizes a selection guide grounded in these findings and is intended for design reviews between domain and platform leads. American Academic Scientific Research Journal for Engineering, Technology, and Sciences (ASRJETS) - Volume 103, No 1, pp 453-463 460 Table 1: Interaction style selection across bounded contexts (evidence-based guide) (compiled by the author based on [3, 4, 6-10]) Workload signature in/among contexts Preferred interaction Rationale Caveats Bursty fan-out from one context to many consumers Event-driven publishing with durable broker Smooths bursts, decouples producers/consumers, stabilizes tails Broker hops and serialization overhead; observability complexity Strict transactional workflow within one aggregate Synchronous request/response Simple failure semantics and transactional clarity for a single consistency boundary Coupling if used across aggregates; avoid cross-context ACID High-concurrency, I/O- bound pipelines inside a context Reactive handlers and back-pressure Improved concurrency with lower RAM and narrower p90 latency Debuggability and tooling; not a universal throughput win Read-heavy product areas with multiple views and weak read- after-write coupling CQRS with denormalized read models (optionally event sourcing for audit) Independent scaling and evolution of queries; simpler command path and clearer aggregate invariants Dual-model complexity; projection lag and backfill procedures; governance of read- model schemas Stream processing with stateful operators across events Event streams + elastic DSP operators Operator-aware scale- out/migration; contract-based evolution Requires schema/version discipline and contract testing Overload or partial failure at edges Client-side balancing with overload feedback Narrows latency tails without central coordination Requires fine-tuned shedding/admission signals Autoscaling and adaptation mechanisms provide the operational complement to compile-time boundaries. A proactive–reactive scaling approach synthesizes configuration-level reconfigurations to meet SLOs with fewer breaches than purely reactive baselines, reducing the pressure to widen service contracts during demand spikes Reference [2]. In stream-centric domains, operator migration, elastic state management, and topology reconfiguration give teams a controlled vocabulary for change at runtime, provided that schema and version evolution are treated as first-class contracts between contexts [4]. Combined with overload-aware client balancing, these controls keep bounded contexts operationally independent while still collaborating through durable contracts Reference[2, 9]. Human outcomes and documentation practice. Virtual onboarding research correlates structured knowledge delivery with lower turnover intention and faster role integration for developers [1]. DDD programs operationalize this through a maintained domain glossary, context maps, and decision records that explain why boundaries, American Academic Scientific Research Journal for Engineering, Technology, and Sciences (ASRJETS) - Volume 103, No 1, pp 453-463 461 contracts, and interaction styles exist; the literature review on DDD explicitly highlights the need to institutionalize ubiquitous language to sustain comprehension as teams evolve [8]. Table 2 consolidates evidence- backed documentation and governance practices that support maintainability and onboarding in distributed product teams. Table 2: Documentation and governance practices that sustain DDD outcomes (compiled by the author based on [1, 2, 4-10]) Practice / artifact Intended outcome Evidence-backed notes Ubiquitous language glossary + context map Faster comprehension and consistent naming across teams SLR stresses sustained language and boundary documentation for effectiveness Architecture decision records (ADRs) linking domain contracts to interaction style Traceable rationale during refactors and audits Pattern evaluations show performance signatures vary; ADRs prevent cargo-cult reuse Decomposition analytics (dependency graphs, clustering) used prior to extraction Higher boundary fidelity, fewer cross-cuts Case study shows data-driven clusters align with business functions; use to challenge workshop cuts Proactive–reactive autoscaling policies as part of service SLOs SLO stability without widening contracts Fewer breaches than purely reactive baselines in microservice settings Contract testing and schema/versioning for event streams Safer evolution across contexts Survey classifies runtime adaptation and stresses contract maintenance Onboarding kits that embed glossary, context map, and service playbooks Lower turnover intention and faster time-to- effectiveness Onboarding study correlates structured, tool-ready materials with improved retention indicators Overload-aware client balancing patterns in platform guidelines Latency tail control under burst and imbalance Feedback-driven balancing stabilizes response times without centralized metadata Reactive vs. imperative decision guide per service endpoint Targeted use of reactive where workload benefits are proven Comparative and migration studies caution against blanket adoption Not all components of the evidence base carry the same weight, and several restrictions shape the interpretation of the synthesized results. The primary corpus consists of English-language, peer-reviewed publications from roughly the last five years, complemented by a small number of recent preprints. Studies that report negative American Academic Scientific Research Journal for Engineering, Technology, and Sciences (ASRJETS) - Volume 103, No 1, pp 453-463 462 outcomes or neutral experiences with DDD, CQRS, or related architectural tactics are likely underrepresented, because such work tends to appear less often in archival venues. The empirical foundations are mixed: controlled experiments on performance patterns, targeted evaluations of event-driven pipelines, and single-program migration studies dominate [2–7, 9, 10], whereas long-term longitudinal observations across entire enterprise portfolios remain rare. Quantitative evidence for the practitioner program referenced in this article is based on internal reports and is available only in aggregated form, which limits reproducibility and independent verification. Threats to external validity arise from the technological and organizational scope of the reviewed work. Most measurements concern microservice and data-streaming platforms in cloud-native environments and involve organizations that already operate with a certain level of automation, monitoring, and deployment maturity. Conclusions transfer less directly to monolithic systems, legacy integration landscapes, or teams with limited observability and weak separation of ownership. CQRS-related guidance relies largely on secondary sources and conceptual analyses rather than on head-to-head experiments isolating the effect of read/write separation, so prescriptions for or against CQRS in borderline domains should be treated as hypotheses to be validated through local experiments, canary deployments, and continuous profiling. These constraints argue for incremental adoption of DDD and CQRS with feedback from measurements and incident reviews, instead of one-time redesigns based solely on published results and generalized experience reports. 5.Conclusion Boundary-first thinking anchors the change in project philosophy: ubiquitous language and context maps precede implementation, while data-assisted decomposition validates proposed cuts before extraction. Interaction style selection follows workload shape rather than fashion: event-driven pipelines suit bursty fan-out and decoupling needs; synchronous calls serve narrow, transactional aggregates; reactive execution benefits I/O-bound flows but not every compute-heavy path. Runtime governance complements compile-time design through predictive- reactive autoscaling and overload-aware balancing that preserve autonomy and narrow latency tails during demand shifts. Documentation and onboarding practices—glossary, context map, ADRs, contract tests, and schema/version discipline—sustain comprehension and reduce re-coupling as teams evolve. The combined workflow delivers reproducible criteria for partitioning, collaboration, execution choice, and operational control, aligning day-to-day engineering with business semantics while retaining measurable performance and maintainability in enterprise portfolios. The same artifacts lower support costs and raise team engagement by keeping change localized and language consistent across product areas. References [1]. Akdur, G., Aydın, M. N., & Akdur, G. (2024). Understanding virtual onboarding dynamics and developer turnover intention in the era of pandemic. Journal of Systems and Software, 216, 112136. https://doi.org/10.1016/j.jss.2024.112136 [2]. Bacchiani, L., Bravetti, M., Giallorenzo, S., Gabbrielli, M., Zavattaro, G., & Zingaro, S. P. (2025). Proactive–reactive microservice architecture global scaling. Journal of Systems and Software, 220, American Academic Scientific Research Journal for Engineering, Technology, and Sciences (ASRJETS) - Volume 103, No 1, pp 453-463 463 112262. https://doi.org/10.1016/j.jss.2024.112262 [3]. Cabane, M., Kleinner, F. (2024). On the impact of event-driven architecture on performance: an exploratory study. Advance online publication. 153(C), 52-69. DOI:10.1016/j.future.2023.10.021 [4]. Cardellini, V., Lo Presti, F., Nardelli, M., & Russo Russo, G. (2022). Runtime adaptation of data stream processing systems: The state of the art. ACM Computing Surveys, 54(11s), Article 237, 1-36. https://doi.org/10.1145/3514496 [5]. Maharjan, R., Sooksatra, K., Cerny, T., Rajbhandari, Y., & Shrestha, S. (2025). A Case Study on Monolith to Microservices Decomposition with Variational Autoencoder-Based Graph Neural Network. Future Internet, 17(7), 303. https://doi.org/10.3390/fi17070303 [6]. Meijer, W., Trubiani, C., & Aleti, A. (2024). Experimental evaluation of architectural software performance design patterns in microservices. Journal of Systems and Software, 218, 112183. https://doi.org/10.1016/j.jss.2024.112183 [7]. Mochniej, K., & Badurowicz, M. (2023). Performance comparison of microservices written using reactive and imperative approaches. Journal of Computer Sciences Institute, 28, 242–247. https://doi.org/10.35784/jcsi.3698 [8]. Özkan, B., Babur, Ö., & van den Brand, M. G. J. (2025). Domain-driven design: A systematic literature review. Journal of Systems and Software. Advance online publication. https://doi.org/10.1016/j.jss.2025.112537 [9]. Bhattacharya, R., Gao, Y., & Wood, T. (2024). Dynamically balancing load with overload control for microservices. ACM Transactions on Autonomous and Adaptive Systems, 19(4), Article 22, 1-23. https://doi.org/10.1145/3676167 [10]. Zbarcea, S., Kiselev, V., & Kiselev, A. (2024). Migrating from developing asynchronous multi- threading programs to reactive programs in Java. Applied Sciences, 14(24), 12062. https://doi.org/10.3390/app142412062