Looking for love: (in all the wrong places)
OOPSLA '04 Companion to the 19th annual ACM SIGPLAN conference on Object-oriented programming systems, languages, and applications
Looking for love (in all the wrong places)
ACM SIGPLAN Notices
Reuse and variability in large software applications
Proceedings of the 10th European software engineering conference held jointly with 13th ACM SIGSOFT international symposium on Foundations of software engineering
From scenarios to aspects: exploring product lines
SCESM '05 Proceedings of the fourth international workshop on Scenarios and state machines: models, algorithms and tools
Lazy Types: Automating Dynamic Strategy Selection
IEEE Software
Transaction Support Using Unit of Work Modeling in the Context of MDA
EDOC '05 Proceedings of the Ninth IEEE International EDOC Enterprise Computing Conference
WebHelix: another web engineering process
Journal of Computing Sciences in Colleges
ICWE '06 Proceedings of the 6th international conference on Web engineering
Improving software development organizations with autochthony
Companion to the 21st ACM SIGPLAN symposium on Object-oriented programming systems, languages, and applications
Architectural improvement by use of strategic level domain-driven design
Companion to the 21st ACM SIGPLAN symposium on Object-oriented programming systems, languages, and applications
Using domain-driven design to evaluate commercial off-the-shelf software
Companion to the 21st ACM SIGPLAN symposium on Object-oriented programming systems, languages, and applications
Impact of Evolution of Concerns in the Model-Driven Architecture Design Approach
Electronic Notes in Theoretical Computer Science (ENTCS)
Modeling process-driven and service-oriented architectures using patterns and pattern primitives
ACM Transactions on the Web (TWEB)
Companion to the 22nd ACM SIGPLAN conference on Object-oriented programming systems and applications companion
IAnticorruption: a domain-driven design approach to more robust integration
Companion to the 22nd ACM SIGPLAN conference on Object-oriented programming systems and applications companion
Agile enterprise software development using domain-driven design and test first
Companion to the 22nd ACM SIGPLAN conference on Object-oriented programming systems and applications companion
A survey of patterns for Service-Oriented Architectures
International Journal of Internet Protocol Technology
Integrating The Concept Of Synthesis In The Software Architecture Design Process
Journal of Integrated Design & Process Science
Semantics through language sharing
Proceedings of the hypertext 2008 workshop on Collaboration and collective intelligence
Patterns for business object model integration in process-driven and service-oriented architectures
Proceedings of the 2006 conference on Pattern languages of programs
Functional testing: a pattern to follow and the smells to avoid
Proceedings of the 2006 conference on Pattern languages of programs
Review of Knowledge Engineering Requirements for Semantic Reasoning in Autonomic Networks
APNOMS '08 Proceedings of the 11th Asia-Pacific Symposium on Network Operations and Management: Challenges for Next Generation Network Operations and Service Management
Engineering of Software-Intensive Systems: State of the Art and Research Challenges
Software-Intensive Systems and New Computing Paradigms
Software Engineering for Ensembles
Software-Intensive Systems and New Computing Paradigms
Ontological approach to the specification of properties of software systems and their components
Cybernetics and Systems Analysis
Domain-driven discovery of stable abstractions for pointcut interfaces
Proceedings of the 8th ACM international conference on Aspect-oriented software development
Management of requirements in ERP development: a comparison between proprietary and open source ERP
Proceedings of the 2009 ACM symposium on Applied Computing
Daileon: a tool for enabling domain annotations
Proceedings of the Workshop on AOP and Meta-Data for Software Evolution
Proceedings of the 2005 conference on Self-Organization and Autonomic Informatics (I)
A comparison model for agile web frameworks
Proceedings of the 2008 Euro American Conference on Telematics and Information Systems
Discovery of architectural layers and measurement of layering violations in source code
Journal of Systems and Software
Applying agile to large projects: new agile software development practices for large projects
XP'07 Proceedings of the 8th international conference on Agile processes in software engineering and extreme programming
Learning agile methods in practice: advanced educational aspects of the Varese XP-UG experience
XP'07 Proceedings of the 8th international conference on Agile processes in software engineering and extreme programming
Software tools for requirements management in an ERP system context
Proceedings of the 2010 ACM Symposium on Applied Computing
A reputation pattern for service oriented computing
ICICS'09 Proceedings of the 7th international conference on Information, communications and signal processing
The Tower of Babel did not fail
Proceedings of the ACM international conference on Object oriented programming systems languages and applications
An architecturally-evident coding style: making your design visible in your code
Proceedings of the ACM international conference companion on Object oriented programming systems languages and applications companion
A four-way framework for validating a specification
SAICSIT '10 Proceedings of the 2010 Annual Research Conference of the South African Institute of Computer Scientists and Information Technologists
Requirements modeling for embedded realtime systems
MBEERTS'07 Proceedings of the 2007 International Dagstuhl conference on Model-based engineering of embedded real-time systems
Mod4J: a qualitative case study of model-driven software development
MODELS'10 Proceedings of the 13th international conference on Model driven engineering languages and systems: Part II
Web Pontoon: a method for reflective web applications
IWST '10 International Workshop on Smalltalk Technologies
Communications of the ACM
REST and Linked Data: a match made for domain driven development?
Proceedings of the Second International Workshop on RESTful Design
Discovery of stable abstractions for aspect-oriented composition in the car crash management domain
Transactions on aspect-oriented software development VII
Executable model composition: a multilevel approach
Proceedings of the 2011 ACM Symposium on Applied Computing
Discovery of stable abstractions for aspect-oriented composition in the car crash management domain
Transactions on aspect-oriented software development VII
Queue - Interoperability
Experiences on a design approach for interactive web applications
WebApps'11 Proceedings of the 2nd USENIX conference on Web application development
Capitalizing on uncertainty, diversity and change by online individualization of functionality
UMAP'11 Proceedings of the 19th international conference on User modeling, adaption, and personalization
Experiences with rapid mobile game development using unity engine
Computers in Entertainment (CIE) - Theoretical and Practical Computer Applications in Entertainment
The investigation of WEB software system based on domain-driven design
WISM'11 Proceedings of the 2011 international conference on Web information systems and mining - Volume Part I
Proceedings of the 10th SIGPLAN symposium on New ideas, new paradigms, and reflections on programming and software
The artist in the computer scientist: more humanity to our research
Proceedings of the 10th SIGPLAN symposium on New ideas, new paradigms, and reflections on programming and software
Reuse of continuation-based control-flow abstractions
Proceedings of the 2nd workshop on Free composition @ onward! 2011
Generating smart wrapper libraries for arbitrary APIs
SLE'09 Proceedings of the Second international conference on Software Language Engineering
Conceptual schema-centric development: a grand challenge for information systems research
CAiSE'05 Proceedings of the 17th international conference on Advanced Information Systems Engineering
XP'05 Proceedings of the 6th international conference on Extreme Programming and Agile Processes in Software Engineering
Component synthesis from service specifications
SMTT'03 Proceedings of the 2003 international conference on Scenarios: models, Transformations and Tools
Modeling crosscutting services with UML sequence diagrams
MoDELS'05 Proceedings of the 8th international conference on Model Driven Engineering Languages and Systems
Adaptable generic programming with required type specifications and package templates
Proceedings of the 11th annual international conference on Aspect-oriented Software Development
Divide after you conquer: an agile software development practice for large projects
XP'06 Proceedings of the 7th international conference on Extreme Programming and Agile Processes in Software Engineering
An example of the retrospective patterns-based documentation of a software system
Transactions on Pattern Languages of Programming I
aRDF: a plugin to expose RDFa semantic information using Grails
Proceedings of the 6th Euro American Conference on Telematics and Information Systems
Applying fundamental banking patterns: stories and pattern sequences
Proceedings of the 15th European Conference on Pattern Languages of Programs
Personalization for unobtrusive service interaction
Personal and Ubiquitous Computing
Architectural decision identification in architectural patterns
Proceedings of the WICSA/ECSA 2012 Companion Volume
Domain specific feature modeling for software product lines
Proceedings of the 16th International Software Product Line Conference - Volume 1
Assisted behavior driven development using natural language processing
TOOLS'12 Proceedings of the 50th international conference on Objects, Models, Components, Patterns
Growing a pattern language (for security)
Proceedings of the ACM international symposium on New ideas, new paradigms, and reflections on programming and software
Implementing modular domain specific languages and analyses
Proceedings of the Workshop on Model-Driven Engineering, Verification and Validation
Domain-Driven discovery of stable abstractions for pointcut interfaces
Transactions on Aspect-Oriented Software Development IX
Automated construction of a large semantic network of related terms for domain-specific modeling
CAiSE'13 Proceedings of the 25th international conference on Advanced Information Systems Engineering
Design principles for research data export: lessons learned in e-health design research
DESRIST'13 Proceedings of the 8th international conference on Design Science at the Intersection of Physical and Virtual Design
A guide to agile development of interactive software with a "User Objectives"-driven methodology
Science of Computer Programming
Proceedings of the 2013 ACM workshop on Domain-specific modeling
Light-weight software product lines for small and medium-sized enterprises (SMEs)
CASCON '13 Proceedings of the 2013 Conference of the Center for Advanced Studies on Collaborative Research
International Journal of Enterprise Information Systems
Hi-index | 0.02 |
From the Book:Leading software designers have recognized domain modeling and design as critical topics for at least twenty years, yet surprisingly little has been written about what needs to be done or how to do it. Although it has never been clearly formulated, a philosophy has developed as an undercurrent in the object community, which I call "domain-driven design".I have spent the past decade focused on developing complex systems in several business and technical domains. I've tried best practices in design and development process as they have emerged from the leaders in the object-oriented development community. Some of my projects were very successful; a few failed. A feature common to the successes was a rich domain model that evolved through iterations of design and became part of the fabric of the project.This book provides a framework for making design decisions and a technical vocabulary for discussing domain design. It is a synthesis of widely accepted best practices along with my own insights and experiences. Projects facing complex domains can use this framework to approach domain-driven design systematically.Contrasting Three ProjectsThree projects stand out in my memory as vivid examples of the dramatic effect domain design practice has on development results. Although all three delivered useful software, only one achieved its ambitious objectives and delivered complex software that continued to evolve to meet ongoing needs of the organization.I watched one project get out of the gate fast with a useful, simple web-based trading system. Developers were flying by the seat of their pants, but simplesoftware can be written with little attention to design. As a result of this initial success, expectations for future development were sky-high. It was at this point that I was approached to work on the second version. When I took a close look, I saw that they lacked a domain model, or even a common language on the project, and were saddled with an unstructured design. So when the project leaders did not agree with my assessment, I declined the job. A year later, they found themselves bogged down and unable to deliver a second version. Although their use of technology was not exemplary, it was the business logic that overcame them. Their first release had ossified prematurely into a high-maintenance legacy.Lifting this ceiling on complexity calls for a more serious approach to the design of domain logic. Early in my career, I was fortunate to end up on a project that did emphasize domain design. This project, in a domain at least as complex as the one above, also started with a modest initial success, delivering a simple application for institutional traders. But this delivery was followed up with successive accelerations of development. Each successive iteration opened exciting new options for integration and elaboration of functionality. The team way able to respond to the needs of the traders with flexibility and expanding capability. This upward trajectory was directly attributable to an incisive domain model, repeatedly refined and expressed in code. As the team gained new insight into the domain, the model deepened. The quality of communication improved among developers and between developers and domain experts, and the design, far from imposing an ever-heavier maintenance burden, became easier to modify and extend.Unfortunately, not all projects that start with this intention manage to arrive at this virtuous cycle. One project I joined started with lofty aspirations to build a global enterprise system based on a domain model, but finally had a disappointing result. The team had good tools, a good understanding of the business and gave serious attention to modeling. But a separation of developer roles led to a disconnect between the model and implementation, so the design did not reflect the deep analysis that was going on. In any case, the design of detailed business objects was not rigorous enough to support combining them in elaborate applications. Repeated iteration produced no improvement in the code, due to uneven skill-level among developers with no clear understanding of the particular kind of rigor needed. As months rolled by, development work became mired in complexity and the team lost its cohesive vision of the system. After years of effort, the project did produce modest, useful software, but had given up the early ambitions along with the model focus.Of course many things can put a project off course, bureaucracy, unclear objectives, lack of resources, to name a few, but it is the approach to design that largely determines how complex software can become. When complexity gets out of hand, the software can no longer be understood well enough to be easily changed or extended. By contrast, a good design can make opportunities out of those complex features.Some of these design factors are technological, and a great deal of effort has gone into the design of networks, databases, and other technical dimension of software. Books have been written about how to solve these problems. Developers have cultivated their skills.Yet the most significant complexity of many applications is not technical. It is in the domain itself, the activity or business of the user. When this domain complexity is not dealt with in the design, it won't matter that the infrastructural technology is well-conceived. A successful design must systematically deal with this central aspect of the software.The premise of this book is that For most software projects, the primary focus should be on the domain and domain logic. Complex domain designs should be based on a model. Domain-driven design is a way of thinking and a set of priorities, aimed at accelerating software projects that have to deal with complicated domains. To accomplish that goal, this book presents an extensive set of design practices, techniques and principles.Design vs. Development ProcessDesign books. Process books. They seldom even reference each other. Each is a complex topic in its own right. This is a design book. But I believe that these two issues are inextricable if design concepts are to be put into successful practice and not dry up into academic discussion. When people learn design techniques, they feel excited by the possibilities, but then the messy realities of a real project descend on them. They don't see how to fit the new design ideas with the technology they must use. Or they don't know when to worry about a particular design aspect and when to let go in the interest of time. While it is possible to talk with other team members about the applica design principle in the abstract, it is more natural to talk about the things we do together. So, while this is a design book, I'm going to barge right across that artificial boundary when I need to. This will place design in the context of a development process. This book is not specific to a particular methodology, but it is oriented toward the new family of "Agile Development Processes". Specifically, it assumes a couple of process practices are in place on the project. These two practices are prerequisites for applying the approach in this book. Iterative development. The practice of iterative development has been advocated and practiced for decades, and is a corner stone of the Agile development methods. There are many good discussions in the literature of Agile development and Extreme Programming, among them, Cockburn1998 and Beck 1999. A close relationship between developers and domain experts. Domain-driven design crunches a huge amount of knowledge into a model that reflects deep insight into the domain and a focus on the key concepts. This is a collaboration between those who know the domain and those who know how to build software. Because it is iterative, this collaboration must continue throughout the project's life.Extreme Programming (XP), conceived by Kent Beck, Ward Cunningham and others Beck2000, is the most prominent of the agile processes and the one I have worked with most. To make the discussion concrete, I will use XP throughout the book as the basis for discussion of the interaction of design and process. The principles illustrated are easily adapted to other Agile Processes. In recent years there has been a rebellion against elaborate development methodologies that burden projects with useless, static documents and obsessive upfront planning and design. Instead, the Agile Processes, such as XP, emphasize the ability to cope with change and uncertainty. XP recognizes the importance of design decisions, but strongly resists upfront design. Instead, it puts an admirable effort into increasing communication, and increasing the project's ability to change course rapidly. With that ability to react, developers can use the "simplest thing that could work" at any stage of a project and then continuously refactor, making many small design improvements, ultimately arriving at a design that fits the customer's true needs.This has been a much-needed antidote to some of the excesses of design enthusiasts. Projects have bogged down in cumbersome documents that provided little value. They have suffered "analysis paralysis", so afraid of an imperfect design that they made no progress at all. Something had to change.Unfortunately, some of these new process ideas can be easily misinterpreted. Each person has a different definition of "simplest". Continuous refactoring without design principles to guide these small redesigns developers can produce a code base hard to understand or change - the opposite of agility. And, while fear of unanticipated requirements often leads to over-engineering, the attempt to avoid over-engineering can develop into another fear: The fear of any deep design thinking at all. In fact, XP works best for developers with a sharp design sense. The XP process assumes that you can improve a design by refactoring, and that you will do this often and rapidly. But design choices make refactoring itself easier or harder. The XP process attempts to increase team communication. But model and design choices clarify or confuse communication. What is needed is an approach to domain modeling and design that pulls its weight.This book intertwines design and development practice and illustrates how domain-driven design and agile development reinforce each other. A sophisticated approach to domain modeling within the context of an agile development process will accelerate development. The interrelationship of process with domain development makes this approach more practical than any treatment of "pure" design in a vacuum.The Structure of This BookThe book is divided into four major sections:Part I: Putting the Domain Model to Work presents the basic goals of domain-driven development that motivate the practices in later sections. Since there are so many approaches to software development, Part I defines terms, and gives an overview of the implications of placing the domain model in the role of driving communication and design. Part II: The Building Blocks of Model-driven Design condenses a core of best practices in object-oriented domain modeling into a set of basic building blocks. The focus of this section is on bridging the gap between models and practical, running software. Sharing these standard patterns brings order to the design and makes it easy for team members to understand each other's work. Using standard patterns also establishes a common language, which all team members can use to discuss model and design decisions.But the main point of this section is on the kind of decisions that keep the model and implementation aligned with each other, reinforcing each other's effectiveness. This alignment requires attention to the detail of individual elements. Careful crafting at this small scale gives developers a steady platform to apply the modeling approaches of Parts III and IV.Part III: Refactoring Toward Deeper Insight goes beyond the building blocks to the challenge of assembling them into practical models that provide the payoff. Rather than jumping directly into esoteric design principles, this section emphasizes the discovery process. Valuable models do not emerge immediately. They require a deep understanding of the domain. That understanding comes from diving in, implementing an initial design based on a probably naive model, and then transforming it again and again. Each time the team gains insight, the model is transformed to reveal that richer knowledge, and the code is refactored to reflect the deeper model and make it's potential available to the application. Then, once in a while, this onion pealing leads to an opportunity to break through to a much deeper model, attended by a rush of profound design changes.Exploration is inherently open-ended, but it does not have to be random. Part III delves into modeling principles that can guide choices along the way, and techniques that help direct the search.Part IV: Strategic Design deals with situations that arise in complex systems, larger organizations, interactions with external systems and legacy systems. This section explores a triad of principles that apply to the system as a whole: Bounded Context, Distillation, and Large-Scale Structure. Strategic design decisions are made by teams, or even between teams. Strategic design enables the goals of Part I to be realized on a larger scale, for a big system or in an application that fits in an enterprise-wide network.Throughout the book, discussions are illustrated with realistic examples, drawn from actual projects, rather than oversimplified "toy" problems.Much of the book is written as a set of "patterns." The reader should be able to fully understand the material without concern about this device, but those who are interested in the style and format of the patterns can read Appendix A.Who This Book Is Written ForThis book is primarily written for developers of object-oriented software. Most members of a software project team can benefit from some parts of it. It will make most sense to people who are on a project, trying to do some of these things as they go through, or who have deep experience already to relate it to.Some knowledge of object-oriented modeling is necessary to benefit from this book. The examples include UML diagrams and Java code, so the ability to read those languages at a basic level is important, but it is unnecessary to have mastered the details of either UML or Java. Knowledge of Extreme Programming will add perspective to the discussions of development process, but the discussion should be understandable without background knowledge.For an intermediate software developer, a reader who already knows something of object-oriented design and may have read one or two software design books, this book will fill in gaps and provide perspective on how object modeling fits into real life on a software project. It will help an intermediate developer make the jump to applying sophisticated modeling and design skills to practical problems.An advanced or expert software developer should be interested in the comprehensive framework for dealing with the domain. The systematic approach to design will help them in leading teams down this path. The coherent terminology will help them communicate with peers.Readers of various backgrounds may wish to take different paths through the book, shifting emphasis to different points. I recommend all readers to start with the introduction to Part I, and Chapter 1. This book is a narrative, and can be read beginning to end, or from the beginning of any chapter. A skimmer who already has some grasp of a topic should be able to pick up the main points by reading headings and bolded text. A very advanced reader may want to skim Parts I and II, and will probably be most interested in Parts III and IV.In addition to this core readership, the book will be of interest to analysts and to relatively technical project managers. Analysts can draw on the connection between model and design to make more effective contributions in the context of an "Agile" project. Analysts may also use some of the principles of strategic design to better focus and organize their work. Project managers should be interested in the emphasis on making a team more effective and more focused on designing software meaningful to business experts and users. And, since, strategic design decisions are interrelated with team organization and work styles, these design decisions necessarily involve the leadership of the project, and have a major impact on the project's trajectory.While an individual developer who understands domain-driven design will gain valuable design techniques and perspective, the biggest gains come when a team joins to apply a domain-driven design approach and move the domain model to the center of discourse of the project. The team members will share a language that enriches their communication and keeps it connected to the software. They will produce an implementation in step with the model, giving leverage to application development. They will share a map of how design work of different teams relates, and will systematically focus attention on the most features most distinctive and valuable to the organization.A domain-driven design is a difficult technical challenge that can pay off big, opening opportunities just at the stage when most software projects begin to ossify into legacy. Eric Evans, San Francisco, California, March 2003