Your understanding of the model is evolved in your code. In DDD, this notion is called model-driven design.
Even though it's an imitation of the perfect solution, you can seek to bring that code closer to the true Form over time. It is only a manifestation-a shadow, if you will-of the application Form you set out to achieve.
The software you create is not the true model. The fact of the matter is, the mismatch between the model that's in everyone's head and the model you're committing to code is the first thing an aspiring domain modeler should understand. Good models exhibit a number of attributes independent of their implementation. It's not much of a stretch to say these limitations are the equivalent of cave dwellers only ever being able to see the interior wall of shadows.
These are, in a very real sense, the shadows to Plato's imaginary cave dwellers.įurthermore, you are often constrained by programming languages and considerations of time and budget in trying to reach that Form. The path to the Form you want to describe with your code is scattered about in the minds of domain experts, the desires of stakeholders, and the requirements of industries in which we're working. Much of its guidance helps us get closer to the ideal model over time. You can relate Plato's theory of Forms to DDD. When a lion walks by, they point at the shadow of the lion and exclaim, "Run for cover!" But it is really only a shadow of the real Form, the lion itself. To the cave dwellers, these shadows are the real thing. When an animal walks by the opening, a shadow is projected onto the interior wall that the cave dwellers see. These cave people are chained in such a way that they can only ever see a blank wall of the cave that receives light from the opening. In this allegory, there exists a people that are bound inside a deep, dark cave. To explain Forms, Plato used what's become known as the allegory of the cave. He dubbed this idea of a true thing a Form. Plato, that most famous student of Socrates, proposed that the concepts, people, places, and things we intuit and perceive with our senses are merely shadows of the truth. Answering this question leads us on a short, metaphysical journey. Since we're just starting off here, it makes practical sense to define what I mean by model. He's quite experienced with and articulate about this approach and produces a fair amount of content on the subject.
If you're interested in architectural Bounded Contexts, I highly recommend keeping tabs on Greg Young's blog. Bounded Contexts give you a glimpse of this promised land. This might come as a shock to some, but it's possible for database administrators and developers to get along. You can use a technology such as Microsoft Message Queue (MSMQ) to publish data updates coming from the model and incorporate them into data warehouses optimized for reporting and analysis purposes. You want the freedom to pursue the right degree of normalization for developing reliable reports, and you want to use an Object-Relational Mapper so that you can keep coding transactional business logic in the object-oriented paradigm. It's often desirable in such circumstances (which might occur pretty often) to break out the reporting database from the transactional database. The classic example of this approach is an application that has both a robust transactional footprint and a portfolio of reports. They're very useful in dividing a system to achieve desired architectural examples. The patterns and core tenets of DDD that I will discuss in this article are derived from the concepts that are detailed in this book.īounded Contexts needn't be organized solely by the functional area of an application. More than simply the original introduction to DDD, it is a treasure trove of information by one of the industry's most seasoned software designers. If the ideas presented here appeal to you, I highly recommend that you deepen your toolbox by reading the book Domain-Driven Design: Tackling Complexity in the Heart of Software, by Eric Evans. To provide some context to the discussion, I'm using a complex business domain with which I'm familiar: insurance policy management. Think of this article as a gentle introduction to designing and evolving rich domain models. In this article, I'll cover the basic concepts and design patterns germane to DDD. These models encapsulate complex business logic, closing the gap between business reality and code. Properly applied it can lead to software abstractions called domain models. Repositories Save and Dispense Aggregate Rootsĭomain-Driven Design(DDD) is a collection of principles and patterns that help developers craft elegant object systems. This article uses the following technologies:
Using the Single Responsibility Principle.Volume 24 Number 02 Best Practice - An Introduction To Domain-Driven Design