Domain Event: An object that is used to record a discrete event related to model activity within the system.Value Object: An immutable (unchangeable) object that has attributes, but no distinct identity.
Entity: An object that is identified by its consistent thread of continuity, as opposed to traditional objects, which are defined by their attributes.
Bounded Context: A description of a boundary (typically a subsystem, or the work of a specific team) within which a particular model is defined and applicable.ĭomain-driven design also defines a number of high-level concepts that can be used in conjunction with one another to create and modify domain models:.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.Model: A system of abstractions that describes selected aspects of a domain and can be used to solve problems related to that domain.Statements about a model can only be understood in a context. Context: The setting in which a word or statement appears that determines its meaning.Constantly collaborate with domain experts, in order to improve the application model and resolve any emerging domain-related issues.Įvans’ Domain-Driven Design further defines a few common terms that are useful when describing and discussing DDD practices:.Base complex designs on models of the domain.Focus on the core domain and domain logic.
Domain driven design layers software#
It aims to ease the creation of complex applications by connecting the related pieces of the software into an ever-evolving model. Initially introduced and made popular by programmer Eric Evans in his 2004 book, Domain-Driven Design: Tackling Complexity in the Heart of Software, domain-driven design is the expansion upon and application of the domainconcept, as it applies to the development of software. The business logic of an application refers to the higher-level rules for how business objects (see: OOAD) interact with one another to create and modify modelled data. In other words, during application development, the domain is the “sphere of knowledge and activity around which the application logic revolves.”Īnother common term used during software development is the domain layer or domain logic, which may be better known to many developers as the business logic. The common dictionary definition of domain is: “A sphere of knowledge or activity.” Drilling down a bit from that, domain in the realm of software engineering commonly refers to the subject area on which the application is intended to apply. To define domain-driven design we should first establish what we mean by domain in this context (and in development in general). Throughout this article we’ll examine what domain-driven design is, how it is commonly implemented in modern development life cycles, and consider a few potential advantages and disadvantages of using DDD in your own projects. DDD is a software development approach that uses and builds upon OOADprinciples and ideas, so it’s the next logical topic for us to dive into. Expanding on our previous article that covered Object-Oriented Analysis and Design ( OOAD), today’s article will explore domain-driven design ( DDD).