domain software development core activities processes requirements design engineering construction testing debugging deployment maintenance paradigms and models agile cleanroom incremental prototyping spiral v model waterfall methodologies and frameworks asd devops dad dsdm fdd iid kanban lean sd less mdd msf psp rad rup safe scrum semat tsp up xp supporting disciplines configuration management documentation software quality assurance sqa project management user experience practices atdd bdd cco ci cd ddd pp standup tdd tools compiler debugger profiler gui designer modeling ide build automation release automation infrastructure as code testing standards and bodies of knowledge babok cmmi ieee standards iso 9001 isoiec standards pmbok swebok itil glossaries artificial intelligence computer science electrical and electronics engineering vte domaindriven design ddd is an approach to software development for complex needs by connecting the implementation to an evolving model the premise of domaindriven design is the following placing the projects primary focus on the core domain and domain logic basing complex designs on a model of the domain initiating a creative collaboration between technical and domain experts to iteratively refine a conceptual model that addresses particular domain problems the term was coined by eric evans in his book of the same title concepts concepts of the model include context the setting in which a word or statement appears that determines its meaning domain a sphere of knowledge ontology influence or activity the subject area to which the user applies a program is the domain of the software model a system of abstractions that describes selected aspects of a domain and can be used to solve problems related to that domain ubiquitous language a language structured around the domain model and used by all team members to connect all the activities of the team with the software strategic domaindriven design patterns in strategic domaindriven design and the relationships between them ideally it would be preferable to have a single unified model while this is a noble goal in reality it typically fragments into multiple models it is useful to recognize this fact of life and work with it strategic design is a set of principles for maintaining model integrity distillation of the domain model and working with multiple models bounded context multiple models are in play on any large project yet when code based on distinct models is combined software becomes buggy unreliable and difficult to understand communication among team members becomes confusing it is often unclear in what context a model should not be applied therefore explicitly define the context within which a model applies explicitly set boundaries in terms of team organization usage within specific parts of the application and physical manifestations such as code bases and database schemas keep the model strictly consistent within these bounds but dont be distracted or confused by issues outside continuous integration when a number of people are working in the same bounded context there is a strong tendency for the model to fragment the bigger the team the bigger the problem but as few as three or four people can encounter serious problems yet breaking down the system into eversmaller contexts eventually loses a valuable level of integration and coherency therefore institute a process of merging all code and other implementation artifacts frequently with automated tests to flag fragmentation quickly relentlessly exercise the ubiquitous language to hammer out a shared view of the model as the concepts evolve in different peoples heads context map an individual bounded context leaves some problems in the absence of a global view the context of other models may still be vague and in flux people on other teams wont be very aware of the context bounds and will unknowingly make changes that blur the edges or complicate the interconnections when connections must be made between different contexts they tend to bleed into each other therefore identify each model in play on the project and define its bounded context this includes the implicit models of nonobjectoriented subsystems name each bounded context and make the names part of the ubiquitous language describe the points of contact between the models outlining explicit translation for any communication and highlighting any sharing map the existing terrain building blocks in the book domaindriven design a number of highlevel concepts and practices are articulated such as ubiquitous language meaning that the domain model should form a common language given by domain experts for describing system requirements that works equally well for the business users or sponsors and for the software developers the book is very focused on describing the domain layer as one of the common layers in an objectoriented system with a multilayered architecture in ddd there are artifacts to express create and retrieve domain models entity an object that is not defined by its attributes but rather by a thread of continuity and its identity example most airlines distinguish each seat uniquely on every flight each seat is an entity in this context however southwest airlines easyjet and ryanair do not distinguish between every seat all seats are the same in this context a seat is actually a value object value object an object that contains attributes but has no conceptual identity they should be treated as immutable example when people exchange business cards they generally do not distinguish between each unique card they only are concerned about the information printed on the card in this context business cards are value objects aggregate a collection of objects that are bound together by a root entity otherwise known as an aggregate root the aggregate root guarantees the consistency of changes being made within the aggregate by forbidding external objects from holding references to its members example when you drive a car you do not have to worry about moving the wheels forward making the engine combust with spark and fuel etc you are simply driving the car in this context the car is an aggregate of several other objects and serves as the aggregate root to all of the other systems domain event a domain object that defines an event something that happens a domain event is an event that domain experts care about service when an operation does not conceptually belong to any object following the natural contours of the problem you can implement these operations in services see also service systems architecture repository methods for retrieving domain objects should delegate to a specialized repository object such that alternative storage implementations may be easily interchanged factory methods for creating domain objects should delegate to a specialized factory object such that alternative implementations may be easily interchanged disadvantages in order to help maintain the model as a pure and helpful language construct the team must typically implement a great deal of isolation and encapsulation within the domain model consequently a system based on domaindriven design can come at a relatively high cost while domaindriven design provides many technical benefits such as maintainability microsoft recommends that it be applied only to complex domains where the model and the linguistic processes provide clear benefits in the communication of complex information and in the formulation of a common understanding of the domain relationship to other ideas objectoriented analysis and design although in theory the general idea of ddd need not be restricted to objectoriented approaches in practice ddd seeks to exploit the advantages that objectoriented techniques make possible these include entitiesaggregate roots as receivers of commandsmethod invocations and the encapsulation of state within foremost aggregate roots and on a higher architectural level bounded contexts modeldriven engineering mde and modeldriven architecture mda while ddd is compatible with mdamde where mde can be regarded as a superset of mda the intent of the two concepts is somewhat different mda is concerned more with the means of translating a model into code for different technology platforms than with the practice of defining better domain models the techniques provided by mde to model domains to create dsls to facilitate the communication between domain experts and developers facilitate the application of ddd in practice and help ddd practitioners to get more out of their models thanks to the model transformation and code generation techniques of mde the domain model can be used not only to represent the domain but also to generate the actual software system that will be used to manage it this picture shows a possible representation of ddd and mde combined pojos and pocos pojos and pocos are technical implementation concepts specific to java and the net framework respectively however the emergence of the terms pojo and poco reflect a growing view that within the context of either of those technical platforms domain objects should be defined purely to implement the business behaviour of the corresponding domain concept rather than be defined by the requirements of a more specific technology framework the naked objects pattern based on the premise that if you have a good enough domain model the user interface can simply be a reflection of this domain model and that if you require the user interface to be a direct reflection of the domain model then this will force the design of a better domain model domainspecific modeling dsm dsm is ddd applied through the use of domainspecific languages domainspecific language dsl ddd does not specifically require the use of a dsl though it could be used to help define a dsl and support methods like domainspecific multimodeling aspectoriented programming aop aop makes it easy to factor out technical concerns such as security transaction management logging from a domain model and as such makes it easier to design and implement domain models that focus purely on the business logic command query responsibility segregation cqrs cqrs is an architectural pattern for separation of reads from writes where the former is a query and the latter is a command commands mutate state and are hence approximately equivalent to method invocation on aggregate rootsentities queries query state but do not mutate it cqrs is a derivative architectural pattern from the design pattern called command and query separation cqs which was coined by bertrand meyer while cqrs does not require ddd domaindriven design makes the distinction between commands and queries explicit around the concept of an aggregate root the idea is that a given aggregate root has a method that corresponds to a command and a command handler invokes the method on the aggregate root the aggregate root is responsible for performing the logic of the operation and yielding either a number of events or a failure exception or execution result enumerationnumber response or if event sourcing es is not used just mutating its state for a persister implementation such as an orm to write to a data store while the command handler is responsible for pulling in infrastructure concerns related to the saving of the aggregate roots state or events and creating the needed contexts eg transactions event sourcing es an architectural pattern which warrants that your entities as per eric evans definition do not track their internal state by means of direct serialization or or mapping but by means of reading and committing events to an event store where es is combined with cqrs and ddd aggregate roots are responsible for thoroughly validating and applying commands often by means having their instance methods invoked from a command handler and then publishing a single or a set of events which is also the foundation upon which the aggregate roots base their logic for dealing with method invocations hence the input is a command and the output is one or many events which are transactionally single commit saved to an event store and then often published on a message broker for the benefit of those interested often the views are interested they are then queried using querymessages when modeling your aggregate roots to output events you can isolate the internal state event further than would be possible when projecting readdata from your entities as is done in standard ntier datapassing architectures one significant benefit from this is that tooling such as axiomatic theorem provers eg microsoft contracts or chess are easier to apply as the aggregate root comprehensively hides its internal state events are often persisted based on the version of the aggregate root instance which yields a domain model that synchronizes in distributed systems around the concept of optimistic concurrency tools practicing ddd does not depend upon the use of any particular software tool or framework nonetheless there is a growing number of opensource tools and frameworks that provide support to the specific patterns advocated in evans book or the general approach of ddd among these are actifsource is a plugin for eclipse which enables software development combining ddd with modeldriven engineering and code generation apache isis is a java framework for developing domaindriven and restful applications using the naked objects pattern eco domain driven design framework with database class code and state machine generation from uml diagrams by capableobjects openmdx open source java based mda framework supporting java se java ee and net openmdx differs from typical mda frameworks in that use models to directly drive the runtime behavior of operational systems openxava generates an ajax application from jpa entities you only need to write the domain classes to obtain a ready to use application restful objects is a standard for a restful api onto a domain object model where the domain objects may represent entities view models or services two open source frameworks one for java one for net can create a restful objects api from a domain model automatically using reflection cubicweb is an open source semantic web framework entirely driven by a data model highlevel directives allow to refine the data model iteratively release after release defining the data model is enough to get a functioning web application further work is required to define how the data is displayed when the default views are not sufficient enode is a c framework which support to develop dddcqrsevent sourcing architecture style applications domain of a function event storming knowledge representation ontology information science semantic analysis knowledge representation semantic networks semantics domain driven design definitions and pattern summaries pdf eric evans 2015 implementing aggregate root in c language an introduction to domain driven design methods tools haywood dan domain driven design using naked objects interview infoq how to define bounded contexts 