Vue.js Live Conference

Vue.js London 2023

Introduction to Domain Driven Design<ul><li>- What is DDD?</li><li>- Key principles of DDD</li><li>- Benefits of using DDD in web application development</li></ul>Domain Modeling in Vue 3 Applications<ul><li>- How to design and implement domain models in Vue 3</li><li>- Strategies for integrating domain logic with Vue's reactive data model and component-based architecture</li></ul>Best Practices for Implementing DDD in Vue 3<ul><li>- Strategies for organizing code in a way that follows DDD principles</li><li>- Techniques for reducing coupling between domain and application logic</li><li>- Tips for testing and debugging domain logic in Vue 3 applications</li></ul>

Domain Driven Design with Vue Applications

Welcome to this talk on domain driven design in Vue.js application. My name is Abdur Razak Mostafa, also known as Geek Mara's. I am a front end engineer at PaperShift. I am a content creator on YouTube where I post videos on coding tutorials, productivity, carriers and many others. You can also find me on GitHub as Geek Mara's. Today we are going to look into domain driven design, its benefits and how it works with Vue.js. Domain driven design versus the MVVM model. We are also going to take a quick look into a simple code base on structure of Vue.js application written in a domain driven design pattern. There are various design patterns that we know exist in the software development cycle. We have the object oriented design. We have the MVC, we have the DDD and the MVVM and many others. When we look at the OOD, which is the object oriented design, which is a process of creating a software system or application utilizing object oriented paradigm. The MVC, which is the model view controllers, is a design pattern used for developing user interfaces that divide the related program logic into three connected elements, which is the view, models and the controller. The MVVM, which is the models view, view model, which is kind of like the pattern for Vue.js applications by default, which is a pattern that helps cleanly separate an application, business and presentation logic from its user interface. We all know that this is one of the things that Vue.js thrive in. The main discourse of today, which is domain driven design, which is a design approach that focuses on modeling softwares to match a domain according to input from domain experts. And with these, we are going to explain further more in the slides. So when we look at DDD, which is domain driven design, it's an approach to software development that emphasizes understanding business logic and modeling the problem domain. The goal is to create a domain that accurately reflects the language, concepts and relationship within the domain. And this in turn helps the team to better understand complex business entities, leading to improved software design and writing maintainable codes. When we look at the domain driven design structure in comparison to the default MVVM, the MVVM splits folder structure by relationship to functional aspects of the code base, such as the router, the store, the pages, components, assets and many more custom folders we want to add to our application. While the DDD approach follows a domain rather than a loose MVVM, meaning that our application is actually disintegrated to the core domains of our applications. And these domain folders, this domain may contain folders and these folders are like the core models in which our applications are using. So you could have a payment domain, you could have like a product domain, you could have orders domain, you could have user profile domain and lots of features depending on the models or domain of which applications we are building. When we look at the default folder structure for a default MVVM, which is basically what you'd get when you scaffold the Vue.js application, the assets, components, routers, stores, views. And with this, if you're building a larger application, you might struggle when the application gets big and yet if you build by this default structure, it might be difficult to maintain at a long run. And this is one of the things where domain driven design thrive. And that is because for each of our domains or for each of our models, it's going to have its own component, it's going to have its own store, it's going to have its own router, it's going to have its own pages and its own test and many other custom features we might want to add to our various domains. And with this, it's cleaner and more easier to maintain in the long run. So the benefit of integrating domain driven design into our Vue.js application is because it's a more effective modeling of complex business domain. It's more structured and organized code base that reflects the domain logic. It's more maintainable, scalable and flexible in developing software applications. It's more effective in building user interfaces. I think one of the beautiful things about DDD is that it's for easy onboarding and ownership of products domain by the engineers within the team. So what are the use cases for DDD with Vue.js application? This pattern can be used to build e-commerce applications with complex products and inventory management system, financial applications with complex data models and regulatory requirements. It can also be used on healthcare applications with complex patient data and pervasing concerns and lots of other complex business domains that we can incorporate the DDD pattern into our softwares. So let's take a quick look into a simple code base or a simple structure of how DDD can be implemented into a Vue.js application. I'm going to start with this simple application and when we take a look at our folder structure here, we would find that it's unlike the regular pattern of which a Vue.js application have, which is going to have like by default, we should see the routes, we should see the store, we should see the components and many others. Because this application has been converted or the DDD approach has been implemented into this simple application where we have on the source, we have an app. We have a folder called the core, which is like the model of the application and it's like the top layer of our application. And under it, we're going to have our modules, which are the core parts or the core domains of our application. And this simple example comes with just two domains, or two modules, which is just the blog module and the product module. And we would find here that for each module, it has its own API, its own components, its own constants, its own pages, its own routes, and its own store. And with this, it's quite easier for us to view the application tailored to a particular domain and also ensuring that the business logic and business requirement are met. And one of the beautiful things is that when we look at our entry file, which is the main.js, would find a beautiful import function, which is the autoload routes, which basically looks at all the domains we have, all the models we have in the application, gets the routes and we can then add those routes to our application on a larger scale. And when we take a look at this on... So I'm just going to... When we take a look at this, when we look at the product domain, I would look at the blog. So this is... It's zero now. This is basically a product coming from a dummy API. And we can also move to the blog section. And this is also a blog coming from an API. And when we also look at the dev tools, we would find out that... I'm just going to hard reload this. Yes. So we'll also see that our store is present. We'll also find that our routes in each of our applications are also present. And the second repo which I'll be showing to us is by... Philip Will. Philip Will. You can check him on GitHub and follow him on Twitter. I saw a beautiful repository by Philip Will, where he also did a simple implementation of the main journey design in the VGS application. And on looking at this, and he also made this with TypeScript, which is quite more interesting and more safer. And more safer because it's obviously TypeScript. And one of the most beautiful things I saw in his approach is writing a plugin that helps you register, gets the routes and helps you register the routes, helps you register the module and also if there are other services in these modules or in these domains, it also registers the services and registers the events and other sub-entities within our application. And when we check the entry file to this, this plugin is then used to register the modules, the services, the routes, and other config that our application might have. And just like we mentioned in the previous repository, it also follows the same domain design structure, which is each domain of... We have about two domains here as well. Each domain has its own components, its own locales, its own pages, its own routes, its own stores and similar approach for this sub-domain, which is the two domains here are the example and the full domains. And with this managing a large application is much more easier. Writing maintainable code is assured. And one of the most beautiful things, which is ownership of these domains and it's easier for onboarding of new members on... It's an easier onboarding for new members within coming into the team to understand the application structure by domains. And yes, thank you for listening. And I hope you're going to learn one... I hope you learned one or two things from this and try to as much as possible to implement domain-driven design into your own VGS applications. And another thing is I might need to add is the default MVVM structure is quite good for a simple application, not too big, not too complex. But as you begin to go bigger or build a bigger application, or if you know that starting the project is going to definitely grow bigger in the next few weeks, months or years, then it's a good thing to start your application with a domain-driven design pattern right from the onset. And that's it. Thank you for listening once again. See you in the next one. Bye.
