As I’m doing this, I’m looking for high cohesion within a context and low coupling with other contexts. Following the principles of DDD as articulated by Eric Evans in his excellent book on the topic, I’ve taken the hotel logical data model from the book and started identifying bounded contexts by drawing blue boxes around them. You may have heard quite a bit of talk over the past couple of years about Domain Driven Design (DDD) and its relevance to the microservices movement. Domain-driven design (DDD) and bounded contexts Let’s look at one example of how this might work. So, the time has come to test out my assertion that data modeling and architecture should be done together in an iterative style. Developing data modeling and architecture together Don’t worry, we’ll get back to it soon enough. We need to set that approach aside for a little while and let the data model come to the forefront for a bit. Know we often have an architectural approach in mind before we start new application work, whether we’re intending to build a monolith (hopefully just as a proof of concept, amirite?) or a set of microservices. The room entity could even be generalized further to “reservable spaces” or perhaps “products”.Įntity-relationship diagram for a hotel application with a generalized “room” concept Set your architecture strategy aside (for a moment) If I start my domain models with a clean slate, I can ask questions like - how would my model account for reserving meeting rooms at the hotel?Īs it turns out, the hotel entity-relationship diagram from the book demonstrates the idea of just representing “rooms”. If we’ve been working in that domain for a while, we might assume that the inventory that should be tracked is the rooms that people sleep in. Take the hotel domain model from the book, for instance. This approach may allow you to set aside assumptions about your domain that will overly constrain your design. You can always check your data models against those other data models later. This is true even in cases where there are existing systems to which you are interfacing, which have their own views of the data that your application will need to take into account. Whenever possible, I recommend developing data models and architecture iteratively, as we’ll discuss below. You’ll most likely be left with an awkward mapping exercise.Īs you can probably guess, I believe developing architecture and data modeling independently is a mistake. While you could certainly argue that this brings a proper focus to the training, try taking that same approach in your application development. The training materials I’ve seen for Cassandra data modeling tend to reinforce this pattern, focusing only on development of schema without regard to the underlying architecture.
![domain driven design vs microservices domain driven design vs microservices](https://cdn.confluent.io/wp-content/uploads/Microservices_Diagram-e1561586035890.png)
In my experience, data modeling is sometimes treated as an independent activity from architecting. The proper relationship of data modeling and architecture That’s the ideal we’re looking for in this relationship. At the first point of contact, the domains appear distinct, but as you look downstream they begin to blend and flow together, and the end result is a single unified whole. In my view, data modeling and architecture are two vital elements of the development of an application, and neither should dominate the other.
![domain driven design vs microservices domain driven design vs microservices](https://miro.medium.com/max/1530/1*Lnlel30a2UKjhmHlhbzoWw.jpeg)
“Which comes first? Should the data model drive the architecture, or vice versa?” In this article, we’ll look at the relationship between data modeling and architecture. Previously we’ve discussed how to navigate relationships between different data types and how to maintain unique identity of data over time.
#Domain driven design vs microservices series#
N this series of articles, I’m answering a series of questions that I received from a reader of of my book Cassandra: The Definitive Guide, 2nd Edition(O’Reilly), who asked several questions about how the hotel data model presented in the book would work in practice. This content originally appeared on Jeff's personal blog and is reproduced here by permission. Note: This blog series coincides with the short course Data Model Meets World. Where do data modeling and architecture converge?