Hubbry Logo
Domain (software engineering)Domain (software engineering)Main
Open search
Domain (software engineering)
Community hub
Domain (software engineering)
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Domain (software engineering)
Domain (software engineering)
Domain (software engineering)
View on Wikipedia
from Wikipedia

In software engineering, domain is the targeted subject area of a computer program. Formally it represents the target subject of a specific programming project, whether narrowly or broadly defined.[1] For example, for a particular programming project that has as a goal of the creation of a program for a particular hospital, that hospital would be the domain. Or, the project can be expanded in scope to include all hospitals as its domain.[1]: 352  In a computer programming design, one defines a domain by delineating a set of common requirements, terminology, and functionality for any software program constructed to solve a problem in the area of computer programming, known as domain engineering. The word "domain" is also taken as a synonym of application domain.[1]

Domain in the realm of software engineering commonly refers to the subject area on which the application is intended to apply. In other words, during application development, the domain is the "sphere of knowledge and activity around which the application logic revolves." —Andrew Powell-Morse[2]

Domain: A sphere of knowledge, influence, or activity. The subject area to which the user applies a program is the domain of the software. —Eric Evans[3]

See also

[edit]

References

[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Domain (software engineering)

View on Grokipedia
from Grokipedia
In software engineering, a domain refers to the specific segment of reality or application area for which a software system is developed, serving as the foundational context that includes relevant processes, concepts, entities, and user needs. This encompasses fields such as , healthcare, or , where the software must address domain-specific challenges and . Domains provide the scope for and system design, ensuring that the software aligns closely with the intended real-world usage. Understanding the domain is crucial for effective , as it enables engineers to anticipate requirements, identify reusable elements, and mitigate risks associated with incomplete of the application . Poor domain comprehension can lead to misaligned systems, increased costs, and maintenance difficulties, whereas thorough domain insight accelerates development and improves system adaptability. Key aspects include the domain's boundaries—balancing breadth to cover essential elements without unnecessary complexity—and its unique vocabulary, which forms a shared for communication among stakeholders. Central to leveraging domains are processes like domain analysis and domain engineering. Domain analysis involves systematically identifying, capturing, and organizing , such as common objects, operations, and relationships, to support reusable software artifacts. It draws on expertise from domain specialists to create models that reveal commonalities and variabilities across potential applications within the domain. Domain engineering builds on this by modeling the domain to produce reusable architectures, components, and designs, facilitating the development of software product lines for efficiency and scalability. These approaches promote software reuse, reduce redundancy, and enhance quality in domain-specific projects.

Fundamentals

Definition and Scope

In , a domain refers to the targeted subject area of a computer program, representing a specific area or business , such as or healthcare, that the software addresses. It is formally defined as the segment of reality for which a is developed. This concept serves as the foundational for addressing real-world requirements. The scope of a domain extends to industrial, commercial, governmental, or educational projects, encompassing both the problem space—defined by the environmental and stakeholder-driven requirements—and the initial framing of potential solutions within that space. Examples include , which focuses on transactions and user interactions, and , which addresses and . These domains highlight bounded areas of expertise where software must align closely with domain-specific rules, processes, and constraints to deliver value. The term domain evolved in during the 1970s and , emerging to distinguish application-specific contexts from general-purpose computing amid growing emphasis on software reuse. Early foundations were laid in 1968 with M. Douglas McIlroy's proposal for mass-produced software components to enable systematic reuse across similar problems. By 1980, research programs explicitly outlined reusable , integrating domain concepts to facilitate broader reuse of development artifacts. This evolution was further advanced in the late and through initiatives like the U.S. Department of Defense's STARS program, which emphasized domain analysis for software reuse. Domain modeling represents a subsequent step in this process, used to articulate the structures and relationships within the identified domain. In , the term "domain" refers to the subject area or field of application for which a is developed, encompassing the real-world problem space, entities, rules, and behaviors relevant to that area. This contrasts with "," which denotes the expertise, understanding, and accumulated insights held by stakeholders, experts, or developers about the intricacies of that domain, including its terminology, constraints, and dynamics. While the domain itself is the objective context, is subjective and experiential, serving as a to inform analysis and design but not synonymous with the domain's inherent structure. The concept of an is often used interchangeably with domain, referring to the specific problem space and requirements that the software supports, such as financial transactions in . This ensures that efforts prioritize user-centric elements within the domain while accounting for supportive elements to avoid . A critical separation exists between the problem domain—also known as the domain in its problem-oriented sense—and the solution domain. The problem domain captures user needs, business rules, and environmental constraints independent of implementation details, focusing on what the system must achieve in the real world. Conversely, the solution domain addresses technical choices, such as algorithms, architectures, or technologies, that realize those needs through software artifacts. This bifurcation, emphasized in , prevents conflating stakeholder expectations with decisions, promoting clearer from problems to solutions. Domain concepts in software engineering differ from ontologies in knowledge representation, where the former are pragmatic, project-specific models tailored to software development goals like reusability and implementation feasibility. Ontologies, by comparison, are formal, axiomatic specifications of domain concepts, relationships, and inferences, often aimed at across systems rather than direct . While domain models may borrow ontological elements for precision, they remain implementation-oriented, avoiding the full logical rigor of ontologies to suit iterative practices. Early literature on domain engineering in the 1990s often blurred these terms amid emerging reuse paradigms, leading to ambiguities in scoping problem versus solution spaces.

Domain Analysis

Purpose and Process

Domain analysis serves as a foundational activity in software engineering, aimed at systematically identifying commonalities, variabilities, and requirements across related systems within a specific domain to facilitate the development of reusable software assets. By capturing domain knowledge in a structured form, it enables engineers to build generic solutions that can be adapted for multiple applications, thereby reducing overall development costs and time. This process is particularly valuable in product line engineering, where it supports the creation of scalable architectures that address recurring problems in a family of systems. The process of domain analysis unfolds in a series of structured steps to ensure comprehensive coverage of the domain. It begins with domain scoping, which involves defining the boundaries of the domain by assessing its scope, viability, and alignment with organizational needs and existing systems. Next, information collection gathers relevant data through methods such as stakeholder interviews, of existing , and of legacy systems to build a . This is followed by feature identification, where common elements (shared across systems) and variable elements (points of customization) are delineated, often resulting in models like feature diagrams. Finally, validation engages stakeholders to and refine the findings, ensuring accuracy and before proceeding to subsequent phases. Conducting domain analysis yields significant benefits, including enhanced by clarifying domain-specific needs early, support for product line through reusable components, and minimization of rework in downstream development. In mature domains, it can unlock 30-50% potential, leading to productivity gains of 25-40% by leveraging shared assets across projects. These advantages stem from the proactive identification of reuse opportunities, which mitigates and improves . The practice originated in 1980s research on software reuse, with early contributions from James Neighbors, who emphasized domain analysis as key to capturing reusable software knowledge. NASA's domain analysis methods, developed in 1987 as part of initiatives like the Automated Software Development Workstation Project, further advanced the field by applying it to complex, mission-critical systems. These milestones laid the groundwork for modern approaches, influencing standards in domain engineering.

Techniques and Methods

One prominent technique in domain analysis is the Feature-Oriented Domain Analysis (FODA) method, introduced in 1990 by researchers at the (SEI). FODA emphasizes identifying and modeling features—end-user visible characteristics of software systems—through structured steps including context modeling to define the domain's boundaries and stakeholders, and the creation of feature diagrams to represent hierarchical relationships and variability among features. These diagrams use nodes for features and edges to denote mandatory, optional, or alternative relationships, enabling analysts to capture both common and variant aspects systematically. Several methods support the application of techniques like FODA during domain analysis. Use case analysis involves eliciting requirements by describing interactions between actors and the in form, helping to uncover functional commonalities across domain applications. Scenario-based probing extends this by constructing hypothetical usage scenarios to explore edge cases and variabilities, often through iterative questioning of domain experts to probe assumptions and reveal hidden requirements. Complementing these, commonality/variability analysis (CVA) classifies domain assets by systematically identifying shared elements (commonalities) and differences (variabilities), such as distinguishing core functions from optional extensions, to prioritize reusable components. Tools facilitate the practical execution of these techniques. Orthogonal Variability Modeling (OVM) provides a graphical notation and supporting software, such as the FaMa-OVM prototype, for modeling variabilities independently of other concerns like features or , allowing for constraint checks and model validation. Domain-specific spreadsheets enable lightweight tracking of features and variabilities during early analysis phases, while integration with (UML) tools supports the generation of initial class or diagrams to visualize domain entities and relationships. Evaluation of domain analysis outcomes often relies on metrics assessing the coverage and viability of identified features. For instance, commonality coverage measures the proportion of domain assets that are shared across applications, with a sufficient proportion of commonality, such as over 50%, indicating potential for effective by ensuring sufficient overlap to justify product line development. These metrics guide refinement, ensuring the analysis captures a representative scope without overgeneralization. A practical case example is domain analysis applied to automotive software for engine control systems, where techniques like FODA and CVA identified variable sensor inputs—such as those for timing varying by engine type—while commonalities centered on core ignition logic, enabling reuse across vehicle models. The outputs of such analyses, including feature models, inform subsequent domain engineering phases for asset development.

Domain Modeling

Core Principles

Domain modeling in is underpinned by core principles that guide the creation of accurate, maintainable representations of the problem domain, focusing on essential structures and behaviors while facilitating among stakeholders. These principles—abstraction, consistency with domain experts, iterative refinement, behavioral inclusion, and alignment with established standards—ensure models serve as effective bridges between business requirements and technical implementation, drawing from frameworks like ISO/IEC/IEEE 42010 for architecture descriptions. The principle requires domain models to distill the real-world domain into essential entities, relationships, and behaviors, deliberately omitting implementation-specific details to produce simplified, generalizable representations. This approach emphasizes structural regularities aligned with the model's cognitive purpose, such as communication or problem-solving, thereby enhancing model reusability and reducing cognitive overload for users. By prioritizing ontological commitments to key concepts, prevents models from becoming overly complex or tied to transient technical choices. Consistency with domain experts demands that models adopt business terminology and concepts familiar to subject matter specialists, often via a ubiquitous language that unifies discussions across teams. This alignment minimizes misunderstandings by embedding domain knowledge directly into the model, ensuring it reflects shared mental models and supports seamless collaboration between non-technical stakeholders and developers. Iterative refinement treats domain modeling as an evolving process, initiating with broad overviews of key concepts and attributes, then progressively detailing through stakeholder reviews, feedback incorporation, and strategies to handle . This method allows models to adapt to emerging insights, refining approximations of the domain's reality while maintaining focus on high-impact areas. Behavioral inclusion extends models beyond static elements to capture dynamic aspects, such as state transitions, workflows, and interactions among entities, providing a holistic depiction of domain operations. In practice, this involves defining controller components to orchestrate and coordinate between boundary (interface) and entity (data) objects, ensuring the model accounts for real-time behaviors and lifecycles. Alignment with ISO/IEC/IEEE 42010 ensures domain models conform to standardized practices for conceptual modeling, using to address stakeholder concerns and view components to express aspects within the system's environment. This standard promotes traceability and correspondence rules, enabling domain models to integrate coherently into broader efforts. These principles build on domain analysis outputs for initial model sketches.

Representation and Artifacts

In domain modeling, key artifacts capture the structural, behavioral, and relational aspects of the domain. Entity-relationship diagrams (ERDs) represent data elements and their interconnections, focusing on entities, attributes, and relationships to model the informational structure of the domain. UML class diagrams depict objects and their interactions, illustrating classes, attributes, operations, and associations to provide a static view of the domain's conceptual elements. State machines, often using UML notation, model dynamic behavior by specifying states, transitions, and events that govern how domain entities evolve over time. Representation formats extend these artifacts to formalize more comprehensively. Domain-specific ontologies define concepts, relationships, and axioms within a particular field, enabling and knowledge reuse in modeling. Feature models hierarchically organize domain variations, depicting common and optional features along with dependencies to illustrate product line possibilities. Glossaries compile precise definitions of domain terms, ensuring consistent across stakeholders and serving as a foundation for shared understanding. Tools and notations facilitate the creation and visualization of these artifacts. Enterprise Architect supports UML-based domain modeling through diagramming and simulation capabilities, allowing for integrated representation of structure and behavior. ArchiMate provides a standardized notation for enterprise-level domain views, emphasizing layers from to . Textual descriptions complement visual artifacts by articulating informal narratives or precursors to shared languages, aiding initial elicitation. Validation ensures the integrity of domain models. Model checking verifies consistency by exhaustively exploring state spaces against formal properties, detecting inconsistencies in structural or behavioral specifications. Simulation executes the model dynamically to test behavioral scenarios, confirming alignment with domain requirements through observable outcomes. For instance, in a banking domain model, entities such as Account and Transaction are linked by associations in an ERD or UML , where an Account may have multiple Transactions representing deposits or withdrawals, with state machines capturing lifecycle transitions like "active" to "overdrawn." These artifacts can serve as inputs for building blocks.

Domain Engineering

Overview and Phases

Domain engineering is a systematic discipline in focused on capturing, organizing, and reusing to develop families of related software systems, thereby promoting and in software production. It involves identifying commonalities and variabilities across applications within a specific problem domain, such as telecommunications or automotive systems, to create reusable assets like models, architectures, and components. This approach contrasts with traditional single-system development by emphasizing upfront investment in domain-level artifacts to enable rapid adaptation for multiple products. The origins of domain trace back to the early , pioneered by researchers like James Neighbors through systems such as , which demonstrated reusable analysis and design for domain-specific languages. It was further formalized in the 1990s with influential methods like Feature-Oriented Domain Analysis (FODA), supported by U.S. Department of Defense initiatives such as and DSSA, which aimed to institutionalize reuse practices. These developments built on earlier ideas from Dijkstra and Parnas on program families in the , evolving into a structured process for software product lines. The primary goals of domain engineering are to achieve systematic , thereby reducing development costs and accelerating delivery of software variants. Studies on product line engineering indicate that effective domain engineering can reduce time-to-market to less than 50% and code size by more than 70% compared to ad-hoc development. This is accomplished by minimizing redundant effort across projects, with reported cost reductions exceeding 20% and operational savings of similar magnitude in mature implementations. Overall, it fosters a shift from opportunistic to strategic , enhancing and adaptability. Domain engineering typically unfolds in four structured phases, integrating prior domain analysis and modeling to build a foundation for reuse. The first phase, domain definition or scoping, involves delineating the boundaries of the domain by identifying key stakeholders, common features, and variabilities to establish a clear scope for reusable assets. Next, the domain design phase focuses on modeling assets, such as creating architectural blueprints, feature models, and specifications that capture domain requirements and support variability. The domain implementation phase then develops reusable components, including code libraries, frameworks, and generators, often using techniques like source-to-source transformations to ensure . Finally, the domain realization phase applies these assets to specific products through application engineering, customizing and assembling components to meet individual system needs while validating reuse effectiveness.

Reuse and Variability Management

In domain engineering, reuse focuses on developing shared assets—such as components, architectures, and models—that can be systematically applied across multiple applications to reduce development effort and improve consistency. Variability management complements this by identifying and handling differences among applications, ensuring that reusable assets can adapt to specific requirements without extensive rework. These practices are central to achieving in engineering, where domain assets are proactively designed for broad applicability. Reuse types in domain engineering are broadly categorized as horizontal or vertical. Horizontal reuse involves generic assets applicable across diverse domains, such as common infrastructure functions like , handling, or database connectivity, which provide foundational support independent of . Vertical reuse, conversely, targets domain-specific assets, such as configurable billing rules in systems or simulation models in automotive software, enabling tailored adaptations within a bounded scope. This distinction allows organizations to balance general-purpose efficiency with specialized precision, maximizing asset longevity and applicability. To accommodate variations, domain engineering employs several mechanisms for realizing variability in reusable assets. Parameterization enables dynamic adjustment of behavior through configurable parameters, such as thresholds or formats, without altering core code. Inheritance hierarchies facilitate extension by deriving specialized variants from a base class, promoting hierarchical reuse while preserving common structure. Plug-in architectures support modular extensibility, where optional components can be loaded at runtime or build time to introduce domain-specific features, such as alternative user interfaces or integration adapters. These mechanisms ensure that variability is localized and manageable, supporting both design-time and runtime resolutions. Effective management of variability requires structured strategies to model and resolve options systematically. Decision models, such as feature models originating from feature-oriented domain analysis (FODA), represent variability as hierarchical selections of features with dependencies and constraints, guiding asset configuration. Configuration tools like feature toggles—boolean flags that enable or disable functionality at deployment or runtime—provide fine-grained control, allowing safe introduction of variants without branching codebases. These approaches integrate with domain engineering phases to trace variability from requirements to , minimizing propagation errors. Metrics for evaluating reuse and variability effectiveness include reuse percentage, calculated as the ratio of reused lines of (or equivalent effort units) to total lines of across derived applications, with mature domains typically targeting 50% or higher to justify . This metric highlights , as higher rates correlate with reduced development costs and faster time-to-market; for instance, empirical studies show significant cost reductions in product line contexts. Complementary indicators, like variability resolution time, assess management overhead but prioritize overall asset utilization over granular tracking. A representative example occurs in telecommunications software, where domain engineering creates reusable modules for call routing that handle core logic like number analysis and path selection, while variability mechanisms accommodate protocol differences—such as VoIP's packet-based routing versus PSTN's circuit-switched paths—through parameterization for signaling options and plug-in extensions for network adapters. This approach enables rapid derivation of variants for diverse carriers, achieving high reuse while supporting evolving standards like SS7 or SIP.

Domain-Driven Design

Historical Context

Domain-Driven Design (DDD) emerged as a structured approach to that prioritizes modeling complex business domains through close collaboration between technical and domain experts. It was formally introduced by Eric Evans in his seminal 2003 book, Domain-Driven Design: Tackling Complexity in the Heart of Software, published by . This work synthesized practical insights from Evans' consulting experiences, emphasizing the need to align software models with the core logic of the business domain rather than focusing solely on technical implementation details. The foundations of DDD trace back to the 1990s advancements in , particularly the works of pioneers like and James Rumbaugh, who contributed to the (UML) and promoted domain-centric modeling in complex systems. These efforts were further influenced by earlier practices in and , as developed by figures such as Jim Odell, who advocated for business-oriented object modeling to bridge and software artifacts. DDD built upon these precursors by integrating reuse paradigms and emphasizing iterative refinement of domain models through ubiquitous language shared across teams. Following its 2003 publication, DDD gained traction within agile development communities, where its emphasis on continuous collaboration and adaptability complemented iterative methodologies. A key extension came in 2013 with Vaughn Vernon's Implementing Domain-Driven Design, which provided practical guidance on applying DDD concepts in real-world projects, including tactical patterns for implementation. By the mid-2010s, DDD evolved to address distributed systems challenges, notably through its integration with architectures around 2015, where bounded contexts from DDD helped define service boundaries and manage complexity in scalable, decentralized environments. In the 2020s, DDD principles have further integrated with emerging paradigms like data mesh, a decentralized data architecture that applies domain-oriented ownership to data products, enhancing scalability in analytics and AI-driven systems as of 2021. DDD continues to influence modern practices, including decentralized architecture at organizations like Xapo Bank in 2023 and applications in healthcare platforms discussed at QCon London 2025. This historical progression marked a significant shift in software engineering from code-centric practices to domain-centric design, fostering deeper interdisciplinary collaboration and enabling more maintainable systems in increasingly complex applications.

Key Building Blocks

Domain-Driven Design (DDD) distinguishes between strategic and tactical elements to address complexity in software modeling. Strategic elements focus on large-scale structure and integration, while tactical patterns provide building blocks for implementing the within those boundaries. Bounded contexts serve as modular boundaries that delimit the applicability of a particular , ensuring a clear and shared understanding among team members of what must remain consistent and how it relates to other parts of the system. This strategic pattern partitions the overall domain into subdomains, each with its own cohesive model, preventing the dilution of concepts across unrelated areas. Context mapping then defines relationships and communication protocols between these bounded contexts, such as through patterns like the anti-corruption layer, which isolates a downstream model from unwanted influences of an upstream system by translating foreign concepts into native terms. On the tactical side, entities are objects defined primarily by their unique identity, which persists through changes in attributes, representing elements with a lifecycle in the domain. In contrast, value objects lack conceptual identity and are instead characterized solely by their attributes and behaviors; they are immutable and interchangeable if their properties match, simplifying comparisons and equality checks. Aggregates cluster related entities and value objects into a single unit treated as consistent for data changes, enforced by a entity that guards invariants and serves as the boundary for external interactions. Repositories abstract the persistence layer, offering collection-like access to aggregates without exposing underlying storage details, allowing queries based on domain criteria rather than database structures. The ubiquitous language forms a foundational practice, establishing a shared vocabulary derived from the domain model and used consistently in conversations, documentation, and code to align technical and business perspectives. Domain events capture significant occurrences in the domain that experts deem noteworthy, such as a order placement, enabling decoupling by notifying other parts of the system asynchronously without direct dependencies. For instance, in an domain, an Order might function as an aggregate root—an with a unique identity—encompassing LineItem value objects that describe products without individual identities, ensuring transactional consistency for the entire order while treating line items as replaceable descriptors.

Applications and Challenges

Practical Implementations

Domain modeling integrates seamlessly with Agile and Scrum methodologies by incorporating practices such as during sprint planning to refine ubiquitous language and bounded contexts, ensuring that user stories are explicitly tied to domain events for clearer . In a at a large company, three synchronized agile teams used (DDD) to assign 425 user stories to subdomains, with workshops evolving the iteratively across 1-2 week sprints, fostering cross-functional collaboration and self-managing teams. This approach leverages DDD building blocks like aggregates and entities within team workflows to align development increments with . In architectures, domains are applied by aligning individual services to bounded contexts, which delineate explicit boundaries for models and promote , thereby enhancing system and independent deployment. Bounded contexts serve as linguistic and operational , allowing teams to evolve services autonomously while maintaining semantic consistency across the larger system, as evidenced in systematic reviews of DDD implementations where such decomposition reduced coupling and improved modularity in distributed environments. Industry applications of domain modeling are prominent in finance, particularly for fraud detection domains, where bounded contexts isolate transaction monitoring and risk assessment logic to enable real-time anomaly detection without impacting core banking operations. A global bank's platform restructuring incorporated a dedicated fraud detection domain with AI-driven scoring and automated alerts, resulting in significantly reduced detection times and false positives by aligning domain models with regulatory and operational needs. Similarly, in healthcare, patient record management utilizes domain modeling to define bounded contexts for medical records, ensuring secure handling of demographics, history, and insurance data while complying with privacy standards like HIPAA. One microservices-based healthcare system design employed a "Medical Record Services" context to manage patient data flows, integrating with booking and insurance services for flexible, scalable access to records. Hybrid approaches combine DDD with domain engineering to support software product lines, particularly in automotive platforms where variability in features like sunroof controls requires reusable assets across vehicle variants. Domain engineering identifies common and variable features in the automotive domain, while DDD refines tactical patterns like aggregates for core functionalities, enabling efficient reuse and adaptation in product line development. Metrics of success for domain alignment include improved and fewer bugs due to deeper domain understanding, with empirical studies reporting enhanced that indirectly reduces defect density in complex systems.

Common Pitfalls and Solutions

One common pitfall in domain handling is over-generalization, where developers create overly broad models that attempt to encompass the entire domain in a single, monolithic structure, leading to bloated and unmaintainable artifacts. This often results from insufficient , causing tight and reduced reusability across applications. Another frequent issue is ignoring subdomain complexities, such as treating diverse business areas as uniform, which obscures unique rules and behaviors within . Siloed teams exacerbate this by fostering language mismatches, where different groups use inconsistent , hindering and shared understanding. To address over-generalization and related coupling issues, regular domain walkthroughs—such as sessions—facilitate collaborative validation of models with domain experts, ensuring focused representations. Refactoring bounded contexts periodically helps isolate concerns, allowing teams to refine boundaries as understanding evolves. Employing hexagonal architecture provides a solution for domain isolation by separating core logic from external dependencies like databases or UIs, promoting and adaptability. In large-scale domains, scalability challenges arise from managing intricate interdependencies, often leading to bottlenecks and overhead. A targeted strategy is strategic into core (business-differentiating), supporting (essential but non-unique), and generic (commodity) subdomains, prioritizing investment in the core while or simplifying the others. This approach, rooted in principles, enables modular scaling without overwhelming the overall model. For evolving domains, where business rules and requirements shift rapidly, ad-hoc updates can introduce inconsistencies and technical debt. Continuous discovery workshops, involving iterative interviews and opportunity mapping with stakeholders, support ongoing adaptation by integrating new insights into the domain model systematically. Empirical evidence underscores these risks: The Standish Group's CHAOS Report 2024 indicates project success rates of around 35%, with approximately 65% of projects being challenged or failed, and identifies unclear requirements as a top contributor to these challenges. Similarly, a 2024 BCG analysis found that nearly 50% of executives reported that more than 30% of their technology projects suffer delays or budget overruns, identifying misalignment between business and technology objectives as a leading cause. These findings highlight the need for proactive domain practices to mitigate widespread impacts on project timelines.

References

  1. https://www.sciencedirect.com/topics/computer-science/application-domain
  2. https://www.cs.purdue.edu/homes/cs307/slides/lecture4_2up.pdf
  3. https://dl.acm.org/doi/pdf/10.1145/382296.382703
  4. https://dl.acm.org/doi/pdf/10.1145/217838.217872
  5. https://visuresolutions.com/plm-guide/domain-engineering/
  6. https://www.sciencedirect.com/science/article/pii/S0164121225002055
  7. https://www.cs.dartmouth.edu/~doug/components.txt
  8. https://dl.acm.org/doi/pdf/10.1145/12944.12951
  9. https://ieeexplore.ieee.org/document/667878
  10. https://link.springer.com/article/10.1023/A:1018976708691
  11. https://ieeexplore.ieee.org/document/130660
  12. https://dl.acm.org/doi/pdf/10.1145/63485.63491
  13. https://dl.acm.org/doi/pdf/10.1145/336512.336523
  14. https://dl.acm.org/doi/10.1145/637411.637413
  15. https://link.springer.com/article/10.1007/s10270-022-01021-0
  16. https://www.researchgate.net/publication/228556143_Systems_Engineering_Standards_And_Models_Compared
  17. https://www.sciencedirect.com/topics/engineering/domain-analysis
  18. https://pdfs.semanticscholar.org/d9f6/dabc7c308ab43dd2d73c94b671d009ec208e.pdf
  19. https://apps.dtic.mil/sti/tr/pdf/ADA227058.pdf
  20. https://gee.cs.oswego.edu/dl/oosdw3/ch13.html
  21. https://www.sei.cmu.edu/documents/1889/1990_003_001_15830.pdf
  22. https://arc.aiaa.org/doi/10.2514/6.2021-0787
  23. https://www.dre.vanderbilt.edu/~schmidt/PDF/Commonality_Variability.pdf
  24. https://dl.acm.org/doi/10.1007/s11219-011-9156-5
  25. https://ieeexplore.ieee.org/document/873688
  26. https://www.sciencedirect.com/science/article/pii/S1319157816300246
  27. https://www.uni-ulm.de/fileadmin/website_uni_ulm/iui/Ulmer_Informatik_Berichte/2010/UIB-2010-03.pdf
  28. https://standards.ieee.org/ieee/42010/6846/
  29. http://www.iso-architecture.org/ieee-1471/cm/
  30. https://www.geeksforgeeks.org/software-engineering/software-engineering-domain-modeling/
  31. https://www.sciencedirect.com/science/article/pii/S0950584925000758
  32. https://learn.microsoft.com/en-us/archive/msdn-magazine/2009/february/best-practice-an-introduction-to-domain-driven-design
  33. https://dl.acm.org/doi/10.1145/320434.320440
  34. https://dl.acm.org/doi/10.1007/s10664-021-10015-3
  35. https://dl.acm.org/doi/10.1145/1730874.1730892
  36. https://dl.acm.org/doi/10.1016/j.scico.2012.12.004
  37. https://www.visual-paradigm.com/tutorials/build-glossary-from-domain-class-model.jsp
  38. https://sparxsystems.com/enterprise_architect_user_guide/17.1/modeling_domains/specialized_models.html
  39. https://www.opengroup.org/archimate-forum/archimate-overview
  40. https://stg-tud.github.io/eise/WS11-EiSE-07-Domain_Modeling.pdf
  41. https://ieeexplore.ieee.org/document/4019612
  42. https://www.researchgate.net/figure/Example-of-domain-model-Bank-class-diagram-typically-involves-representing-domain_fig2_385447585
  43. https://dl.acm.org/doi/10.1145/568760.568822
  44. http://www.cs.bilkent.edu.tr/~bedir/CS411/Papers/DomainEngineering.pdf
  45. https://escholarship.org/content/qt5687j6g6/qt5687j6g6.pdf
  46. https://www4.cs.fau.de/Lehre/SS03/V_OSE/Skript/03ose-A5.pdf
  47. https://greg4cr.github.io/courses/fall20tda594/Lectures/Fall-20-Lecture2-DomainEngineering.pdf
  48. https://link.springer.com/chapter/10.1007/978-3-319-48003-9_11
  49. https://dl.acm.org/doi/10.1145/1134285.1134499
  50. https://dl.acm.org/doi/10.1145/3546932.3547009
  51. https://www.jucs.org/jucs_19_2/evaluation_of_a_systematic/jucs_19_02_0254_0280_benitti.pdf
  52. https://apps.dtic.mil/sti/tr/pdf/ADA512389.pdf
  53. https://www.itu.int/rec/T-REC-Q.700/en
  54. https://martinfowler.com/bliki/DomainDrivenDesign.html
  55. https://www.amazon.com/Implementing-Domain-Driven-Design-Vaughn-Vernon/dp/0321834577
  56. https://www.infoq.com/news/2016/07/microservices-ddd-vernon/
  57. https://www.confluent.io/blog/distributed-domain-driven-architecture-data-mesh-best-practices/
  58. https://martinfowler.com/articles/xapo-architecture-experience.html
  59. https://www.infoq.com/news/2025/05/qcon-london-2025-vanderbijl/
  60. https://www.infoq.com/news/2017/09/evans-ddd-relevant/
  61. https://www.domainlanguage.com/wp-content/uploads/2016/05/DDD_Reference_2015-03.pdf
  62. https://www.informit.com/store/domain-driven-design-tackling-complexity-in-the-heart-9780321125217
  63. https://link.springer.com/chapter/10.1007/978-3-319-91602-6_16
  64. https://platformengineering.org/blog/the-need-for-domain-driven-platform-engineering
  65. https://www.researchgate.net/publication/352684920_Designing_Online_Healthcare_Using_DDD_in_Microservices_Architecture
  66. https://www.aasmr.org/liss/Vol.9/JLISS%2520February%25202022%2520%282%29/Vol.9No.01.08.pdf
  67. https://delivery-playbooks.rise8.us/content/practices/domain-driven-design/
  68. https://no-kill-switch.ghost.io/the-failed-promise-of-domain-driven-design-part-1/
  69. https://blog.bitsrc.io/overcoming-domain-driven-design-implementation-challenges-with-components-3bb7f03ebb3
  70. https://dzone.com/articles/10-things-to-avoid-in-domain-driven-design
  71. https://ricofritzsche.me/how-to-implement-domain-driven-design-common-mistakes-you-should-avoid/
  72. https://www.kranio.io/en/blog/de-bueno-a-excelente-en-ddd-errores-comunes-y-anti-patrones-en-domain-driven-design---10-10
  73. https://link.springer.com/article/10.1007/s10664-023-10310-1
  74. https://microservices.io/patterns/decomposition/decompose-by-subdomain.html
  75. https://deviq.com/domain-driven-design/subdomain
  76. https://www.producttalk.org/opportunity-solution-trees/
  77. https://www.standishgroup.com/sample_research_files/CHAOSReport-2024.pdf
  78. https://www.bcg.com/publications/2024/software-projects-dont-have-to-be-late-costly-and-irrelevant
Add your contribution
Related Hubs
User Avatar
No comments yet.