Conscientious leaders work hard at building up the right teams for the right reasons for the right outcomes. And, you want your brand to perform well now and long into the future. You want to rely on your team to provide the greatest value for the the investment. Domain-Design Design done well will give you peace of mind that an iterative approach to thinking through an adaptive solution design gives your team the fighting chance they need to make high quality solutions with lower total cost of ownership than Feature Factories due to the software's adaptive nature.
With DDD done well, you can trust that your developers did not waste nearly the time they had wasted when they were in Feature Factory mode. Intelligent use of existing domain knowledge gives them a much more accurate target and you can be sure that if they got it slightly wrong, the process to correct it is generally hours or days, not weeks or months. This is especially true if your continuous delivery system is in place, functioning, and leveraged by DDD autonomous teams. Importantly, once a majority of your systems are DDD enabled, you should not be replacing systems every few years. DDD systems are adaptive to change. That is the main reason executives will like empowering their teams with DDD for the long haul.
Directors give their teams the opportunity to perform at their best by supplying reasonable amounts of resources entrusted to them to get the job done. You want to know the right people are managing the right people to get the most value for the organization.DDD Practitioners help you use those resources wisely, not just today, but for the long life of these systems. Quality software is not cheap, and you want to know your teams can make good products today that can adapt to changes requested by the business tomorrow, and five years from now. DDD aligned software enables a reduced Total Cost of Ownership when factoring in maintenance of business logic and upgrades.
Software does not just come together. We all know that entropy is a battle that we cannot seem to get ahead of when we are facing legacy systems. Systems seem to just breakdown faster than we can prop them up. DDD gives you the ability to design the brains of your system. That Domain logic, maintained by DDD principles, do not leaking out into your controllers, orchestrators, choreographers, database procedures, backend for frontends and more. You want to trust that your security is not mixing logic with accounts and your handlers are not getting bloated - by design.
Leading your developers to understand, implement, and sustain DDD enabled systems gives you far more confidence than the Feature Factory mode can ever really hope to provide. Your role is central to DDD success in another way. You want to be sure the developers are not only coloring in the lines correctly, but that they are encouraged to understand the business to fill those gaps. You want things clean and you want them well thought out. When you show teams by example that they too can work with the business, wisely using business terms in code, you are enabling a healthy culture of domain aligned adaptive system design, architecture, and development.
The Product department developed from a need to integrate the business with Information Technology and to keep both working and efficient. You want to ensure what the business needs, within reason, are communicated so well that IT just cannot easily miss.DDD, in particular, the Ubiquitous Language component and a related tools like Eventstorming, give you a way to ensure communication is clear. Developers will have an easier time making what is needed in a way that the business can approve of and enjoy far more often. DDD helps product people integrates the minds that rarely seem to communicate well. DDD is a powerful tool that pulls the walls down and aligns communication with all involved.
Your stress is unique in the world of IT. You are expected to perform. You want to perform. DDD is one way that you can shine bright in the light of the business. In Feature Factory mode, requirements are there, but they don't often translate well into business logic models that can stand the test of time. Often you are not present when requirements are gathered and compiled. The fear is that management has agreed that you will deliver on these requirements, even as agile gives you the perception you are in control, the design process is not there to ensure that is the case. DDDUS is specifically interested in helping you grow past this disfunction by helping you learn what you need to truly make quality software. It is helpful when the rest of the organization is bought-into the DDD way of doing things, as that gives you more freedom to perform at higher levels, but you don't have to wait for everyone to get it to start making a difference. You can start working with your architects to shape new software in a DDD way and integrate it with the rest of the system using DDD principles like Anti-Corruption Layers and Open Host Services. One other really nice thing about a DDD capability with your coworkers is the notion of communication about design principles themselves. If several of you have a DDD vocabulary, those conversations that took hours might be minutes. You get to do really great work in DDD that can last a long time and it reduces your burden on fixing bugs, especially as you pay attention to the principles of side-effect free functions.
Testing in a Feature Factory feels like the job can never truly be done to the satisfaction of the business. You must test everything, all the time, everywhere, no matter what changes. This is true of a monolith as well as a system of microservices that were not carved using domain language boundaries.
DDD sets QA up for a more realistic testing paradigm where modules generally only need to be tested in isolation. Of course, if a contract changed between modules, those tests would be included. Still, this is generally far more focused and normally far less testing per feature than the Feature Factory mode offers. Your job can be nerve racking enough as it is, reducing it to just the real changed scope can help keep your work successful faster with less headache. This also means QA is not the place where features go to die in endless testing. Good DDD is going to provide clearly testable designs.
DevOps has come along way in the last decade. Still, when you work in this capacity, with killer deployment process, it can be extremely frustrating that the systems cannot take advantage of this wonderful power to the level available. This is especially true when microservices are coupled together and constantly deployed together rather than independently. It can be scary to deploy these modules in the way everyone knows they should be these days, so you likely will avoid autonomous component deployments, opting for big bang deploys.
Modular DDD by Bounded Context, especially with a distributed architectures, utilizes logical containers based on the domain. This is good news for DevOps. When we want to deploy a fix to the shipping module, generally we just deploy shipping. If we need the ecomm package deployed to give users a better shopping experience, we just deploy the part of the shopping experience that we upgraded.
When DevOps sees the domain align, it seems DevOps and the previous steps in the process are working smoothly more often than not.
DDD is for the tail end of the Software Development Life Cycle as much as it is for the tip of the spear.