DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
  1. DZone
  2. Data Engineering
  3. Databases
  4. Let's Talk About DDD

Let's Talk About DDD

The basics of Domain Driven Design, and what you need to do to implement it, explained with a helpful video.

Petter Holmström user avatar by
Petter Holmström
·
May. 05, 16 · Presentation
Like (2)
Save
Tweet
Share
4.40K Views

Join the DZone community and get the full member experience.

Join For Free

All software systems are hopefully designed to solve a real world problem. To be able to do this, the software needs an abstraction of the problem — a model — that it can work with. Coming up with this model is not always easy, especially if the real world problem is complex.

Domain Driven Design (DDD) is a software design process that can help us come up with the model. It gives us the tools and building blocks necessary to discover and design our model and turn it into working code.

The most important deliverables of the DDD process are the shared understanding of the problem domain and a language to describe it in. If you cannot describe the concepts and processes of the problem you are solving in such a way that everybody — both customers and developers — understand them, then something is missing from your model and you need to find out what it is. Exactly how you document this understanding and this language is less important as long as it works for your project. My personal favorite is to use UML diagrams and a wiki, but there are other alternatives as well.

In our DDD webinar, shown below, we are demonstrating what the domain modeling process might look like in practice. We re-enact a scenario where a designer and a domain expert (the customer) discuss a specific business problem while documenting the domain model in UML on an iPad. The key here is to keep the technical stuff on such a level that everybody involved understands the model, including the customer who in many cases does not know much about software development.

We also added some UX design to the process, since we have found that this forces us to look at the problem domain from a different angle and discover things that we would otherwise have missed (which we also try to show in the webinar). The end result is a feedback loop where the domain model, the UX design and the discussion with the domain expert all influence each other, gradually building up the understanding of the problem until we know enough to actually solve it in code.

DDD also includes patterns for designing and implementing the software. You may have heard about concepts such as entities, value objects, aggregates, repositories and services. We are not covering them in this webinar, but I tried to use them when I wrote the example code.

Finally, you do not need to go all in to be able to gain from DDD. Full DDD requires practice to master it and I still consider myself a beginner in this subject. In spite of this, the principles of DDD have helped us in many projects. For example, there was one deteriorating project where we experienced serious data consistency issues. Data was duplicated or not saved at all and optimistic locking errors occurred seemingly at random. We managed to bring the project back on track by restructuring our code to use entities, value objects, aggregates and repositories. With this I want to encourage you to familiarize yourself with DDD and pick the bits and pieces you feel might be useful to your particular project.

If you want to learn more about DDD, have a look at these resources:

  • The book that started it all: Domain Driven Design by Eric Evans. If you really want to start using DDD in your projects, this book should be in your bookshelf.
  • If you don’t have time to read the entire DDD book, or you need something right now, you can download and read this free, short summary of the fundamentals of DDD.

If you prefer watching and listening to reading, you can check out these talks on YouTube (in addition to our webinar, of course):

  • Domain Driven Design - Eric Evans
  • Eric Evans: What I've learned about DDD since the book
  • DDD & Microservices: At Last, Some Boundaries! • Eric Evans
Domain-driven design Software design

Published at DZone with permission of Petter Holmström. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Why the World Is Moving Towards Serverless Computing
  • Learning by Doing: An HTTP API With Rust
  • The 31 Flavors of Data Lineage and Why Vanilla Doesn’t Cut It
  • Apache Kafka vs. Memphis.dev

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: