Domain Driven Design with Vue Applications

Welcome to this talk on domain-driven design in Vue.js application. My name is Abdurazak Mostafa, also known as Geekmarrers. I'm a frontend engineer at Papershift. I'm 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 Geekmarrers.

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're also going to take a quick look into a simple code based on structure of a 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 Vue controllers, is a design pattern used for developing user interfaces that divide the related program logic into three connected elements, which are the Vue models and the controller, the MVVM, which is the models Vue Vue model, which is kind of like the pattern for Vue.js, 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 thrives in. The main discourse of the day is domain-driven design, which is a design approach that focuses on modeling softwares to match a domain according to input from domain experts. With these, we are going to explain further more in the slides.

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 the 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. Well, 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 payments domain, you could have like a products 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 default folder structure for default MVVM, which is basically what you'd get when you scaffold the Vue.js application, the assets, components, routers, stores, views. 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. Right? 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 gonna have its own component. It's gonna have its own store. It's gonna have its own router. It's gonna have its own pages and its own tests and many other custom features that 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 to our VGS 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 domained by the engineers within the team.

So what are the use cases for DDD with VGS 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 software.

So let's take a quick look into a simple codebase or a simple structure of how DDD can be implemented into a VGS application. I'm going to start with this, 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 VGS 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 our 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 on that route we're going to have our modules, our modules which are the core part or the core domains of our application. And this simple example comes with just two domains which is the, or two modules, which is just the blog module and the product module, and we'll find here that for each model is that 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 route, which basically looks at all the domains we have, all the models we have in our application, gets the route, 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 gonna take a look at this, we'll look at the product domain, I will look at the blog.

So this is, this is basically the, this is basically a detail of a product, a product coming from the from from the dummy API. Right. And we can also move to the blog section. And this is also a blog coming from an API. And we'll also look at the the dev tools would find out that I'm just gonna hard reload this. Yes. So we'll also see that our store is presents will also find that our routes in each of our applications are also present.

And the second report 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 mentoring 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 this 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 this modules or in these domains, it's also registered services and registers and meets 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 configs that our application might have. And just like we mentioned in the previous repository, it's also follows the same design, domain designs structure, which is each domain of, we have about two domains here as well. Each domain has its own components, its own locals, its own pages, its own routes, its own stores. And similar approach for this subdomain, which is the two domains here are the example and the four 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 easier form. 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, 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, month 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.