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.
DDD DOMAIN DRIVEN DESIGN CODE
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.
DDD DOMAIN DRIVEN DESIGN SOFTWARE
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: