An Interview with Vaughn Vernon on Implementing Domain-Driven Design
Read Implementing Domain-Driven Design and more than 24,000 other books and videos on Safari Books Online. Start a free trial today.
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Rebecca Wirfs-Brock: Why did you write Implementing Domain-Driven Design?
Vaughn Vernon: First of all, I think that there is a big problem in software development today. There are too few developers with the maturity, know-how, and drive of developers like you, Rebecca, and also like Eric Evans. Whether or not you think of yourselves as such, I think you are two of the few pioneers of software craftsmanship. Of course, there can only ever be a limited number of those who introduce the rest of the industry to giant leaps in thought and technique. But I don't believe that the pioneers of thought should be the only ones who can attain maturity and capabilities. Otherwise, the work of thought leaders would have a disappointingly limited impact.
Every software developer today has reached some level of maturity in his or her careers. That may be quite limited, or it may be advanced. For those advanced in their know-how, they can pick up your book, Object-Oriented Design: --Roles, Responsibilities, and Collaborations, or Eric's book, Domain-Driven Design: Tackling Complexity iInthe Heart of Software, and grasp most of the concepts in one read. Perhaps their experiences overlap quite a bit with yours such that they can relate quite readily to what you have written. They just get it. Others with less experience may be able to grasp sections of these forward-thinking works, while being at a loss for why and how to follow more advanced guidance. They have learned to program software largely without design consideration, perhaps possessing a worldview that is quite removed from craft. Some even being skeptical find themselves wondering if what is considered craft by some makes any sense at all in their real world. And if not actually skeptical, they are at least somewhat intimidated by the prospect of trying to put the advanced techniques to work in their projects. Still others with far less experience than either of the first two groups, are overwhelmingly intimidated by even the most basic material presented, and may lack the maturity to understand at a fundamental level what the more mature developers take for granted. It's not that they don't have the desire to learn, but they may lack a wise and patient coach/mentor to help them understand and advance.
In my experience, there are too few who just get it from cover to cover. The vast majority are those with limited understanding, skeptics, and those who are largely intimidated by advanced software development topics. I am not happy with that, and thus it is my goal to give all three groups the ability to mature to the next level of software development maturity, and beyond.
What I have done with Implementing Domain-Driven Design is remove intimidation from the equation. Theory is replaced by practice, as I have provided practical, top-down guidance for implementing DDD on a real project. This opens up the possibility for many more to benefit from the work of true pioneers of software craftsmanship.
Rebecca: Should those new to Domain-Driven Design read your book or Eric’s book?
Vaughn: The short answer is, my book, Implementing Domain-Driven Design, is meant to be a companion to Eric's book. I think it would be unfortunate for anyone to view my book as a standalone answer to DDD. Clearly Eric codified the design wisdom from at least a decade of experience in domain modeling, and it would be a real shame for anyone to short change his material. While my book may be seen as the fast track to DDD, Eric's book is an essential study in order to gain a rich background from the mind of its originator.
If possible, obtain both books together (assuming you don't already have Eric's book). If that's a problem for you, then spend a few months learning from my book, then read Eric's to get a richer background on the origins and theory behind DDD.
Rebecca: How did you come up with the case studies for your book? Is this based on your experience?
Vaughn: As I explain in Chapter 1, Getting Started with DDD, I purposely avoided introducing a case study from my own experience. First of all, I am not at liberty to discuss projects I have worked on. Perhaps more importantly, however, I am not sure that I could have taught as effectively using such a case study. Yet, I could still draw on similar experiences while presenting different projects. I chose to use project case studies from domains that are fairly well understood by most developers today: collaboration tools; Scrum-based project management automation; and identity and access management. I think it would be quite rare for most developers today to be completely unfamiliar with any of these three problem spaces. Clearly, these are not the most complex projects that I could have chosen, and they may not be as interesting as some I have actually worked on. Yet, most actual projects would require considerable effort to wrap your head around. I didn't want to subject readers to that level of cognitive overload, when wrapping their arms around DDD is challenging enough.
Using fictional, yet realistic case studies, I was able to create the ideal scenarios for teaching the essential DDD topics that needed to be covered. For example, using fictional projects, I could get the teams to perpetually paint themselves into a corner, and then show how they worked out of a bad situation. That seems to me to be one of the best teaching tools, because it allows readers to look in on the mistakes of others--perhaps all too familiar to read--and learn from both the errors and their pragmatic solutions.
Rebecca: Where's a good place to start doing Domain-Driven Design? Is Domain-Driven Design appropriate for every enterprise application? Where do you think it fits best?
Vaughn: If you are working with an experienced DDD practitioner, you will have a distinct advantage, and you can use DDD on the most complex of problem and solution spaces. Modeling complex domains is the sweet spot for DDD. If you don't have the advantage of working with an experienced DDD practitioner, you might want to be more conservative. While DDD is meant for tackling complexity, you may want to try it out first on a moderately complex domain. Still, you will want to make sure that the software model you develop has some calculations, algorithms, and/or processes that make it worth modeling.
DDD is not appropriate for just any enterprise application. Some applications can be more effectively developed using a tool or a framework that provides less modeling flexibility, but facilitates rapid development. This approach is especially applicable for very data-centric applications that require little thought about calculations, algorithms, and business processes. In such cases it makes sense to use a framework such as Ruby on Rails or Groovy and Grails, and just forget about crafting a true domain model.
Yet, even if you collect a lot of data using a CRUD framework, you may still need to process some of it in a more complex way after it is stored in your enterprise. In such cases you can always leverage DDD to deal with the heavy lifting parts of your business.
One of the most important things to do when you use DDD is to interact with a domain expert. So, actually the best way to start with DDD is to find the project visionary and get them to share their mental model and work with you to enhance it. This is how you develop one of the DDD project cornerstones, the Ubiquitous Language.
Rebecca: So is the project visionary the same as the domain expert?
Vaughn: In same cases they are, but in other cases they are not. The vision can start at a very high level in the business, but those who convey the vision actually don't have the expertise to carry it off themselves. Instead they lean heavily on those who have practiced in specific areas of the business to make it happen. This can largely depend on the overall scope of the business program. The overall vision could span several projects, with different kinds of experts being needed for each of the projects under the one program. What is more, it is quite possible, even likely, that more than one of the projects is considered a Core Domain; that is, a model that will distinguish this business from its competition and make it superior.
On the other hand, there may not be a large corporate program at all. In such cases a mid-level manager is given a lot of flexibility to take full responsibility to carry out some business initiative with their own budget and flexibility to hire and execute on their own vision. Here, it is extremely important that the visionary acts as the domain expert because it is theirs to succeed or fail in.
However, when we are discussing large programs that encompass several areas of expertise, sometimes business analysts are true domain experts. They have worked in an area that earns them the right of domain expert, even if their "business analyst" job title disguises that fact. They may have been on the job for so long that they simply know how the business functions far better than the visionaries. So, I disagree with those who think that anyone with the title "business analyst" should be immediately written off. Don't be too quick to assume that a business analyst is the wrong person to work with. Sometimes business analysts will actually have more experience and much better insights into the way to convey how the business software should work than those with more corporate influence. It's a judgment call, and definitely one answer doesn't fit all business situations.
This is actually where it can get really interesting. Get a VP or C-level manager involved in a project as a domain expert, and add in a very experienced business analyst, and watch them disagree. I have seen the business analyst have far better insights than the senior manager, yet it's pretty clear whose vote will count most. As frightening as the truth may be, corporate culture and politics play a role in the development of the Ubiquitous Language. Now, as a modeler, do you do the smart thing or the right thing? Or better yet, will you even have a choice?
Rebecca: What is the most difficult challenge you've had modeling/discovering Ubiquitous Language?
Vaughn: Perhaps my most difficult challenge is the same as other DDD practitioners, or will be the most difficult challenge of future practitioners. For me it's been getting time with the true domain experts. Sometimes, no matter how hard you try, it is just plain difficult to involve the experts in the project. Many times they are upper management with lots of responsibility. Sometimes they travel a lot or consider the software design effort something that only the programmers should worry about. Sometimes the company has a perception that placing business analysts between experts and developers is the only way to roll.
When you get down to modeling the software you will almost always find those who fundamentally disagree at a conceptual level. This is where the difficult work begins of sorting out the different mental models. What is fascinating about this situation is that often you will find that all disagreeing parties are correct. When you witness this situation it may be pointing to the need for separate models, or Bounded Contexts. The differences in opinion are actually just a reflection of different people viewing a similar concept in a different context. So, to sort out the differences in opinion ask each domain expert to explain the context that their thoughts are focused on, and listen carefully to determine if their context is different than the others.
It is important for those with expertise in somewhat different areas of the business recognize their limited insights in other areas and to show respect for the expertise of others. Again, conflict could point to there being different subdomains of concern, rather than just one. These differentiations may well supply more insight to the broader business terrain. For example, I worked in a domain where there were three clear domain experts, but each with a slight advantage in a specific area of the business. This particular project worked out well, however, because the three respected the subdomain expertise of each other, and the top manager was not too proud to allow the other two to call the shots in their personal nuance of expertise. In fact, the top manager encouraged the other two to speak up and share their points of view. It's a pleasure to work with teams like that.
Rebecca: In my own experience, I’ve often found that while domain experts have deep knowledge of their domain, they may not be modelers nor good at abstractions—and worse yet (for software design) they may even have inconsistencies in how they themselves talk about the domain (I remember working at a railroad company where they had a little red book of domain concept definitions, and there were multiple definitions---just like you find for words in a dictionary). So a big challenge for someone trying to “capture” Ubiquitous Language is also to disambiguate it. What advice do you have for doing that?
Vaughn: I find there are usually a few ways you might deal with these situations. First of all, don't count on domain experts to be able to think abstractly, since even some software developers struggle here. We software developers who can think in abstractions and have reached a good level of modeling maturity should take it upon ourselves to translate the experts' descriptions of vision, concerns, and requirements into an abstract model. We should then use our communication skills to convey a convincing demonstration of the fact that the model realizes the business vision in a specific way. In actuality while it requires abstract thinking ability to design a useful software model, it doesn't necessarily require abstract thinking ability to recognize that the model makes sense in addressing the business needs.
That said, we shouldn't expect a domain expert to read our models—whether whiteboard UML or as source code—and understand them. That may work with some but not with most. Yet, almost every domain expert can understand our unit tests that execute real business operations on the modeled objects if they are demonstrated using realistically simulated test data. If we step through these tests along with them, showing them the assertions we make about results, they can generally grasp the way things actually work. That's because the tests are concrete, not abstract. In the end it's really up to the individual domain experts to settle on what level of project artifact they are comfortable with as a communication medium.
For the second challenge you bring up—multiple definitions for the same concept—in my experience there are two primary ways to deal with this. The first step is to state your doubt that there are multiple correct definitions and explain that it would help a lot if the team could settle on the one best definition. Of course this implies that there is just one best definition, rather than a few or several. Sometimes that's true, but sometimes it is actually not the case at all. Still, by making an effort to get the team to identify the one best definition, you can find out for sure whether the multiple definitions are accurate. If the team insists that all definitions are correct and necessary to convey the complete meaning, it is probably pointing to the need to exercise your modeling prowess to the full.
Once you have exhausted the possibility that the various definitions span different models (Bounded Contexts), this situation likely means that the various definitions point to different aspects of the one overarching concept.
For example, if we were discussing a stock trading system, we may find that domain experts insist that these two definitions describe a buy order:
- An order to buy stock that indicates the ticker, price, quantity of shares to be purchased, and a status indicating that the order is Open or Filled.
- The process of purchasing stock, which indicates the progress of the execution of the purchase.
In this case I don't think that it would benefit the team to insist that they choose to call the concept either “Buy Order” or “Purchase Execution” when they insist that both are intrinsic to purchasing stock. It's likely pointing to something more substantial.
Actually in this case the main concept may well be a “Buy Order,” but one that has an internal tracking concept that models the process of “Purchase Execution.” In other words, both definitions are correct, but they correspond to slightly different aspects of the same domain concept. As a solution, we could design the overall aggregating concept as a BuyOrder, but composed with a concept named PurchaseExecution. It is the responsibility of the BuyOrder to manage the state of the overall order as it transitions from Open to Filled. Yet, BuyOrder tracks and manages the progress of the purchasing process in a composed part named PurchaseExecution. Each time a step advances the BuyOrder toward being filled, the state of the BuyOrder changes by replacing the previous PurchaseExecution value with a new value instance that reflects the most current progress.
Rebecca: How well does Domain-Driven Design fit into agile development?
Vaughn: It depends on whom you ask. For those who believe that a Scrum Product Backlog with sticky notes on a wall is the product design, it doesn't fit well at all. A developer just moves a sticky note to the in-progress column, and the design is pretty much done. Of course, the software quality usually reflects this shortsighted approach, and I am not talking about quality from the angle that all tests are green. Tests may pass, but the software model is probably swill.
On the other hand, there are those who understand that agile is about delivering quality software and that Domain-Driven Design is about delivering higher-quality software. Given that viewpoint it makes perfect sense to invest some time into designing/developing a carefully crafted domain model. The time needed for this investment may come as a design spike, or it may be neatly spread across the tasks of your sprint's backlog items. This can be biased by the current project life cycle phase. If you are early on in the project, it will probably tend to take the form of a spike. The further into the project you reach, the spikes will tend to flatten to the point where modeling can be achieved while working on specific backlog items. Of course, spikes can always reappear when disruptive requirements or new insights must be addressed.
Rebecca: So you are saying that domain modeling needs to happen at the “most responsible moment,” not the “last responsible moment.” This is a bit more nuanced than the attitude I see with some agile teams, where the design approach is simply to let the design emerge/change with the next story. Domain-Driven Design adds delivery domain understanding “embedded” carefully into how the software is constructed too, not just delivering working code. Thoughts?
Vaughn: I'll back my way into answering this question...
I think it is accurate to say that software architecture is a big deal to most software developers. Even if a given software developer is not highly qualified to make architectural decisions, most probably think they do qualify.
With that given, if I were to suggest to just about any software developer that the architecture of their system should just emerge, I think a very high percentage of those software developers would object strongly to that notion. They would say that they need to have significant architectural mechanisms in place before they can commence developing the realizations of use cases in their system.
In my opinion this is an argument to be won or lost, because generally your functional and non-functional requirements should drive the need for specific architectural mechanisms. You don't just throw together an architecture that's perfect for the software that will be developed next.
I am not saying that architecture should emerge. However, I do believe you must be able to justify the use of each architectural mechanism, and that you can't justify it until you understand your use cases (or user stories) and non-functional requirements. That only comes as a result of examining the real system requirements and even writing some code.
Still, if software developers--even those under-qualified to make architectural decisions--believe that architecture should never emerge, how could any qualified architect or project lead developer insist that a domain model could possibly emerge without careful design? In fact, I believe that developing the essential parts of a domain model first will lead to a clear understanding of what architectural mechanisms are required to support it.
What kind of persistence is needed: relational, key-value, or data grid? Will our domain model need to publish events by means of temporal decoupling? Will some parts of the domain model's state consistency need to be brought into sync eventually? What are the concurrency and parallel processing aspects of the model, if any? The answers to all of these questions lead to architectural decisions. Yet, none of the answers can be determined without empirical knowledge about how the domain model will work.
Certainly, in terms of emerging software concerns, the domain model is the very least of those that should emerge.
Rebecca: Can you incrementally adopt Domain-Driven Design? If so, where would you suggest your readers start?
Vaughn: I think so, yes. If you have a legacy system, and you are required to implement some new features providing business advantage, you can use DDD to accomplish this. You have a few options here.
If the politics in your organization, wherever it may be, prevents you from breaking off the new features into a clean Bounded Context, you can carve out your own clean space right in the existing system. Just create some packages/namespaces that belong only to you, and make sure none of the existing software reaches in to use your new code.
As for your code, put a clean division between your domain objects and the legacy model. (Note that the legacy “model” may be a complete mess, so “model” is used loosely here.) Create some abstraction components—usually called an Anticorruption Layer—that queries the parts of the legacy system needed for you operations. However, don't use the legacy data directly. Instead, translate the legacy data so that it adapts to objects in your own model. Of course you will have to take responsibility for how much data you drag over and maintain; and the less you take on the easier it will be. Now, you have what you need to function on your own terms. In essence you have broken off from the legacy, even though it otherwise engulfs your new code. (By the way, Eric Evans calls this a “Bubble Context.”)
If you do have the leverage to completely break free from the legacy system, then create your own clean Bounded Context that is a separate process, has a completely separate model, separate persistence, and possibly even a separate user interface. You still will want to use an Anticorruption Layer between your new model and the legacy, but the difference is you will need to coordinate communication between two separate processes. Communicate between models using remote procedure calls (RPCs), REST, or messaging.
Clearly the first approach may require less investment overall and give your jaunt into DDD a less risky road to success. It is fairly easy to conclude that your need to enlist domain experts in your project could be disruptive enough to the current business mindset without making bigger waves by requiring new server infrastructure, persistence mechanisms, messaging, and so forth. I've seen DDD efforts crumble before they ever got off the ground simply because architects became too ambitions amid a landscape rife with corporate stumbling blocks.
Rebecca: DDD includes a collection of software design structuring practices (not sure how else to phrase this, but techniques for encapsulating domains-identifying bounded contexts and mapping relationships between domains is quite a sophisticated concept) as well as domain modeling building blocks/patterns. As a new comer to Domain-Driven Design, how do I gain the most traction/what should I focus on?
Vaughn: This is called strategic design, and includes the use of Bounded Contexts and Context Mapping. I have previously mentioned Bounded Contexts in my answers to your questions. A Bounded Context is a linguistic boundary, which means that it is the barrier within which a Ubiquitous Language has context and where it is modeled as software. It is a barrier in the sense that we prevent other software models from encroaching on our clean modeling jurisdiction.
In a complex enterprise, there are always multiple Bounded Contexts, and one or more must be integrated. Context Mapping is used as a means of modeling the relationships between any two Bounded Contexts. The Mappings help define inter-team relationships and how one system technically collaborates with the other system. Of course Context Maps should be used to indicate how any one DDD system relates to and operates with all other outside systems.
These important strategic modeling techniques, along with the Ubiquitous Language, are addressed first in my book in order to emphasize their incredible importance to any serious DDD project.
Rebecca: What are the fundamental patterns of Domain-Driven Design and what’s new with DDD since Eric wrote his book?
Vaughn: The building block patterns, known as the tactical modeling tools of DDD, are those such as Entities, Value Objects, Services, Domain Events, Modules, Aggregates, Factories, and Repositories. If the DDD strategic modeling patterns help us make very broad brushstrokes on the enterprise canvas, the tactical patterns give us the ability to paint the details of realism—well, at least realism in the sense of a useful model.
Domain Events are the newcomer to the DDD tactical toolbox, but are certainly not the least important. Far from it, Domain Events may actually prove to have the most extensive impact on your enterprise.
Rebecca: What should everyone know about Repositories?
Vaughn: First of all I want to clarify that you do not need to use Repositories in order to use Domain-Driven Design. It's just a building block pattern that you can take or leave. However, many find it useful to treat the persistence of each Aggregate type as if it were an in-memory collection of instances.
If you believe that Robert Martin's (“Uncle Bob's”) Single Responsibility Principle makes sense—and I think you should—then an Aggregate should not be responsible for its own persistence. Neither should any one Aggregate instance be responsible for the persistence of any other Aggregate instance. An Aggregate should be responsible only for the specific business-related behavior assigned to it and to managing its state's consistency.
I think that's easy for most software developers to accept, but I don't take for granted that all do. For example, some popular frameworks see to it that each Entity implements a save() method, and some frameworks even house finder methods on the Entities. This is a whole discussion in itself, but assume for now that this is a bad idea. With that assumption, you need some other means to persist Aggregates.
Now, what do you do? Do you use a DAO? In my opinion, and many others, DAO is only about CRUD and veers far of the path of object-orientation. Some DAO approaches don't even deal directly with domain objects. You can, in fact, pass individual attributes to a DAO creation procedure and have those attributes persisted to a database, but with no consideration for a conceptual and meaningful whole within a modeled domain.
On the other hand, Repositories are used to store whole Aggregate instances, using one Repository per Aggregate type. Typically you will want to use a Repository to mimic an in-memory collection, so it seems less like a database mechanism than a convenient object-oriented container. And while you can add() new Aggregate instances to a Repository and remove() existing ones from it, you can also perform sophisticated queries (whether using SQL, specifications, or some other capabilities of the underlying persistence store).
Repositories can also be used to provide simple calculations that are best performed in the database. For example, if you need the sum of values across thousands of Aggregate instances, you can write a query to perform that summing calculation inside the database rather than dragging all the instances back to your process and performing the calculation there. Even though it is less desirable to “hide” domain business logic inside a Repository than to put the operation in a Domain Service or on a specific Aggregate, this technique can provide important performance optimizations when the desired approach is too slow.
Rebecca: So what is the big idea behind Command-Query Responsibility Segregation (CQRS)?
Vaughn: The idea behind CQRS is to allow the user interface to be designed independently of the structure of the domain model. This basically means that you can execute commands (as in CQS) on the domain model, but allow data used by displays to be queried independently of the domain model that handles commands. It can help quite a bit when the data rendered on your application's views tends to cut across multiple Aggregates in the domain model.
It is important to note that CQRS is an architecture pattern that, like any pattern, allows you to achieve certain goals given a certain set of tradeoffs. CQRS is not, however, part of the definition of DDD. In fact, CQRS can be used completely independently of DDD.
Rebecca: What does it mean to integrate events into Domain-Driven Design? Does this change how we should be thinking about integrating and communicating between enterprise systems?
Vaughn: Events can significantly change the way you model. When a Domain Event is published as the outcome of a business operation performed by an Aggregate, the Event can have far reaching impact on the same Bounded Context and others. The Event, when received by subscribers in its own Bounded Context, could cause other Aggregate instances to eventually harmonize with the Aggregate instance that published the Event. Also, if the same Event is subscribed to and received by components in other systems, it can cause Aggregate instances there to also come into consistency with the publishing system.
In both cases this is known as eventual consistency. When embracing an eventual consistency mind set, those who currently depend on global transactions can potentially abandon their use.
You can now leverage the use of long-running processes in a distributed and parallel processing environment. Since Events tend to be handled shortly after the time they were first published, enterprises normally burdened by after hours batch processing can instead spread processing into smaller increments throughout the day. In fact, since Events carry the facts about what has previously happened in any given model, other systems don't have to determine the state of the business situations produced by an entire day of production operations. Instead they know the business situation, one Event at a time, just in time.
Rebecca: It's interesting that you bring up various aspects of distributed computing. What advice do you have for implementing Domain-Driven Design in this new world of distributed computing, cloud computing, and service-orientation?
Vaughn: The use of DDD does not in any way lock you out of the world of distributed computing, or any other architecture. Frankly, Chapter 4 of my book was conceived largely in response to an author of a book on software architecture. This particular author claimed that DDD required the use of an archaic software architecture. After I laughed inside, I set about showing that this author proved himself to be uninitiated on this particular subject. Thus, in my book I show how Domain-Driven Design can be used within the following architectural styles and patterns: Layered, Dependency Inversion Principal, Hexagonal (Ports and Adapters), SOA, REST, Command-Query Responsibility Segregation (CQRS), Event-Driven Architecture (including Pipes and Filters and Event Sourcing), and Data Fabric (or Data Grid). I didn't stop there because I ran out of applicable architectural influences. I simply ran out of space in the book.
However, I have some advice to give about this brave new world. Most importantly, use architecture because it is necessary, not because it is cool.
Second, persistent domain objects (Aggregates, Entities) can be a perfect means to use in distributed systems. Each domain concept that is modeled as, for example, an Aggregate, can reside in a Data Fabric (Grid). In this case, you don't even have to bring the domain object to your process in order to execute some operation. Instead, you can send the operation to the domain object right inside the fabric/grid. That's distributed computing with domain objects.
Also you can leverage continuous repartitioning of your domain objects to a greater and greater number of computing nodes. This could be for in-memory fabric/grid distribution, or using highly scalable key-value storage. But to succeed here you need to keep some basic rules in mind.
For example, you should design small Aggregates. The smaller the Aggregate memory footprint the more quickly it can be retrieved and moved from node to node as needed by repartitioning.
Also when one Aggregate needs to reference another Aggregate—and this will almost always be true—you should point to the associated Aggregates by identity only, not by object reference. By using identity you will allow each referenced Aggregate to reside anywhere in the distributed infrastructure as best determined by the low-level partitioning software.
You will also need to use a scalable messaging mechanism or passing domain event-based messages between computing nodes. The messages should provide the identities of the “partnering” Aggregates that are needed to carry out a specific business process, allowing each domain object to operate in its own time and space, and according to its own responsibilities.
Rebecca: It seems to me that domain-driven design has the potential to not just impact enterprise application design, but also the architecture of enterprise data and communications mechanisms. Do you agree?
Vaughn: I do agree. If you look back at the architectural options that can be used on a DDD project—Layered, Dependency Inversion Principal, Hexagonal (Ports and Adapters), SOA, REST, Command-Query Responsibility Segregation (CQRS), Event-Driven Architecture (including Pipes and Filters and Event Sourcing), and Data Fabric/Grid—it basically means that the sky is the limit for leveraging DDD in most business.
Also it's not like DDD is limited to use by the Fortune 500. Small startups can benefit equally from both the strategic and tactical modeling benefits. For example, I recently worked with a group of Colombian startups as part of an incubator initiative. I primarily spent time with three companies, but consulted and advised more than a dozen total. In most cases I was able to use DDD strategic design to help the various teams to identify their true Core Domain, to see the need to implement new core features, and to understand where they needed to focus their development funds, and where to invest less.
In most cases, strategic design led to some tactical modeling. The teams learned how to best leverage Domain Events, how to make their models more scalable and perform better, and how to make their systems more maintainable. By placing an emphasis on separating models and integrating using loose coupling techniques, each of the startups is now better prepared for growth, expansion, and new innovation.
Rebecca: What's next for you and Domain-Driven Design?
Vaughn: Currently I am working on taking my Implementing DDD Workshop classes to a broader audience of developers than this important education has previously been open to. I have called this the IDDD Tour, and it commences in the Spring of 2013. I will be taking my Workshop to a significant number of students in half-a-dozen European countries, including Eastern Europe. The IDDD Tour is a Workshop that includes lectures, problem-solving exercises, and domain modeling sessions over a four-day program. In order to make my Workshop available to a broader audience, I have lowered the registration fee to approximately 1/5 the normal cost. It's just part of my commitment to put the power of DDD into to hands of as many software developers as possible. You can learn more about this special program here: http://idddtour.com
Of course my efforts won't stop there, but it's best to maintain a certain amount of expectation for the details. Needless to say, what's coming next will be fun and introduce new ways of approaching DDD.
Rebecca: Sound exciting. I wish you the best of luck.