# DDD Introduction As a Developer or Software Engineer, you're probably working with teams of varying skill, size, and expertise. Usually in an environment where people can be slotted in and out on a weekly basis. Or maybe you're a consultant or freelancer who has multiple projects in different stages of development. Keeping track of every project is a daunting task. You don't need the application organization and structure to add to that mental load. Reactium aims to lighten the load by implementing Domain Driven Design ***(DDD)*** ### Domain Driven Design A common strategy for developing applications is Model Driven Engineering ***(MDE)***, where the code is organized by functional domains. A popular MDE is Model/View/Controller ***(MVC)***. > *Techs love acronyms* In most applications that follow MDE you'll find that creating the initial feature is pretty straight forward. *Need a view?* \ Just add it to the **/views** directory and give it a name-spaced file name. *Need a controller?* \ Just add it to the **/controllers** directory and give it a name-spaced file name. Before you know it you have a completed app where there are 50 **views** and 50 **controllers**. Doesn't sound too bad. But what happens when your application model spans more than just views and controllers? Given the feature of a **Page**, your model could expand to include **styles**, **services**, **assets**, and **lang**. Fast-forward 2 months. The marketing department has asked for a new hero image on the Home page with a Spanish and Chinese translation with right to left design implemented for the Chinese translation. Looking at MDE there will be a fair amount of traversing and getting your bearings on where to make the necessary edits *(even with the fixed set we're working with in the following example)*. {% code title="MDE" %} ```jsx /assets about-hero.jpg home-hero.jpg /controllers about-actions.js home-actions.js /services about-services.js home-services.js /styles about-styles.css about-styles-rtl.css home-styles.css home-styles-rtl.css /lang /cn about.cn.pot home.cn.pot /en about.en.pot home.en.pot /es about.es.pot home.es.pot /views about.html home.html ``` {% endcode %} Imagine what MDE would look like if you're looking at a full site with multiple page templates and multiple language support. Looking at DDD it's a lot easier to figure out where to start and what to touch. {% code title="DDD" %} ```jsx /about-page /assets hero.jpg /lang cn.pot en.pot es.pot controller.js services.js styles.css view.html /home-page /assets hero.jpg /lang cn.pot en.pot es.pot controller.js services.js styles.css styles-rtl.css view.html ``` {% endcode %} You'll notice that since we're working with an exact set of files in each domain, we can reduce the number of sub-directories required for grouping files, opting to only use a sub-directory when the number of files will be unknown or varies per domain. You'll also notice that the domain model for each page it the exact same, creating an implied knowledge of the codebase and establishing predictability. Imagine the same request came in for the About page. After completing the Home page edits, it will be easier and faster to make the About page edits. Your brain has the domain in recent memory and since the domain model is the same, you spend no time traversing the code for the necessary files to edit. ### DDD Pros * If you were new to the codebase, you wouldn't have the entire application to discern while trying to figure out what to edit. **After successfully making the first edit, you will feel empowered to make the next and any other similar changes while increasing your domain knowledge**. * **Domain experts can write clear and concise documentation** that can be consumed in smaller chunks with progressive knowledge acquisition making the on-boarding process smoother and require less hand holding. * **Creating variance is as easy as replicating a domain** and making the necessary changes. * **Installing, removing or refactoring a feature is simple** and less risky. * **Identifying problems is a tighter loop** as most issues will be domain specific and not systematic. * **Identifying systematic issues is easier**, you'll be able to trace where the issues are based on which domains are effected and what they share in common. It wouldn't be fair to suggest DDD without listing its cons. ### DDD Cons * Repetitive. With having a domain model comes the need for boilerplate code. This can be mitigated with [generators](/approach/intro.md#generators) and [aggregators](/approach/intro.md#aggregators). * Maintaining the domain model integrity will some times cause for micro-files with 3 or 4 lines of code. It's worth noting this is dependent on how you structure your domain model. The more specific your domain files are the more this will happen. With practice you can find your sweet spot pretty quickly. * Refactoring boilerplate files can become tedious. With a good IDE this isn't as big of a problem. You can easily enough do a regular expression search in a text editor like [Atom](https://atom.io/) and aggregate the files into a list much like they would be shown in MDE. * Sharing functionality across domains can be risky if not done with care. {% hint style="info" %} **Neutral:** With larger or remote teams, planned collaboration is needed to ensure domain experts can share knowledge and reduce duplicating effort when features have overlapping requirements. This can be both a pro and con depending on your team and how you prefer to work. {% endhint %} --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.reactium.io/approach/intro.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.