The domains we have been looking at all involve different forms of complexity in the business areas that are served well using a domain-driven design approach. In the previous sections, we have seen a couple of domains suited well to this approach.
What do they have in common?
As seen before, it is all about the different forms of complexity we need to approach.
A domain that is moving fast in its business rule set needs more attention toward its modeling because rules need to be adjusted as they evolve. Even more importantly, evolving rules mean that the developers don't have a complete understanding of the rules, so the business experts need to be involved heavily. This means that the language we are building in domain-driven design pays off quickly. Therefore, one important part of domain-driven design is that it is about developer access and the ability to understand the domain. We want to be able to quickly get business experts integrated in the process to avoid misunderstanding. The business experts, in the end, are the ones who drive the domain. We, as developers, provide the software that allows the business to be more successful at what it does. As a part of our domain-driven design approach, we identified what really matters to the business
Approaching the problem from the other side now, and still considering access, means access to the system from other systems needs to be simple. At the moment, this is true for a lot of domains with new devices being popular all the time and business in general driving towards a higher level of integration in a business-to-business environment. How does domain-driven design fit in there? The key again is access. We want to be able to provide multiple interfaces that are accessible from the outside, with the same underlying logic. In domain-driven design, we are all about building a strong service layer, and this layer can then be exposed to different systems via different interfaces without the need to duplicate logic, which will inherently risk a divergence of the parts and logic.
Further reading
As the name of this book suggests, it is already heavily influenced by the ideas Eric Evans presented in his book Domain-Driven Design: Tackling Complexity in the Heart of Software, Addison-Wesley, and I would recommend this as a follow-up. He goes in to much more detail about the general approach by providing different examples and from the perspective of a classic Java backend approach.
Another book that should not be missing in any follow-up about software design is, of course, Patterns of Enterprise Application Architecture, Martin Fowler, Addison-Wesley, which follows most of the patterns used every day in object-oriented development and goes into more detail about the patterns in general. The book leans more heavily on the Java side, but as we have seen throughout this book, using JavaScript in an object-oriented way is very possible and will be recommended in a lot of the modeling scenarios.
Summary
With applications written in JavaScript becoming more and more complex, the need for stronger application design has increased. Browser applications are growing, and the business reliance on them grows as well. Due to this, what used to be a domain of backend development starts to become important in frontend development. For a long time now, people have been evolving the way backend applications can be modeled for flexibility, so they can grow with the business, and now browser applications need to do the same. There is a lot to learn from the approaches that have been developed over the years, and even though some are not directly transferable to JavaScript, or might not even be needed, the general ideas port over very well. I hope I was able to present some of these ideas throughout the book.
On the other hand, with the rise and adoption of Node.js as a platform for
application development, JavaScript has moved into the backend as well, and the same challenges that needed solving for Java or Ruby on the Rails backend systems, now need to be solved for JavaScript/Node.js. It is important to stay true to the nature of JavaScript, as with Node.js, the goal often is to make systems simpler and easier to manage in smaller chunks. This in turn means that a Node.js backend takes a lighter modeling approach than a classic enterprise Java system would have.
This is empowering to the developers, as the overarching large-scale architecture discussions move toward a more practical approach being built bottom-up. This should not mean that architecture is not important, but with the split of complexity between frontend and backend systems, the complexity can be managed better with a lighter approach.
Index
value, creating without code 38 architecture, modern applications
context map, drawing 120, 121 monolithic architecture 121, 122 Open Protocol 129
drawing 120, 121
object design, applying to 81 traps, of common names 74 domain-driven design
in domain-driven design 149, 150
domains, suitable for domain-driven design
web application, glueing via 14, 15
F
and functional programming 151, 152 JavaScript frameworks
about 163
implications 163, 164 JavaScript Mixins
URL 144
user experience, enhancing 160, 161
modeling patterns, beyond inheritance 78 Model-View-Controller (MVC) 16
pure object orientation falling short, scenarios 143
object-oriented modeling, of business domains 141, 142