Domain Driven Design

Domain driven design is a software development approach where you start segregating responsibilities between domain and every domain serve set of services.

What is a Domain: –

Domains in Domain Driven Design is a group of services which handle specific types of requests. Now lets talk in simple example. Say, You are working in one company and you have query about your salary or last month payments. So which department your will go to. Of course, Finance department. Not to HR or Transport or Security. Because even if you had approached them they would not have solved your problem. They have no idea about your query.

So when you build Office Management System application, you combine your set of APIs or services between domain or in this case departments. Every specific department (domain) handle their own area of queries.

There are few more terms related to Domain Driven Design. Lets talk about them below.

• Context: The setting in which a word or statement appears that determines its meaning. Statements about a model can only be understood in a context.
• 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. i.e. A language which can be understood by all team members. Let it be, Project Manager, Product Owner, Developer, Tester, Business Analyst, Business People etc..in short everyone.
• 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.        E.g. You are the employee of your company but your context varies between department to department. Finance department people don’t care about whether you are using any of transport service or not and Transport department are not interested in your financials and so on.

Building Blocks: –

Below are some of the building blocks of Domain Driven Design strategy.

• Entity: Entity is something which can be identified by its one unique identifier.
• Value Object: An immutable (unchangeable) object that has attributes, but no distinct identifier.
• Domain Event: An event is something that has happened in the past. A domain event is something that happened in a particular domain, and something you want other parts of the same domain (in-process) to be aware of and potentially react to.
• Aggregate: A group of entities and value objects with defined boundaries that can be treated as a single unit.
• Service: The term service is overloaded and its meaning takes on different shades depending on the context. Service is a significant process or transformation in the domain.
• Repositories: The DDD meaning of a repository is a service that uses a global interface to provide access to all entities and value objects that are within a particular aggregate collection.