title: Architecture pattern is an extreme violation of the open/closed principle
body: <p><a href="https://i.stack.imgur.com/277wB.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/277wB.png" alt="enter image description here" /></a></p>
  <p>I am working on a web app that will automatically generate Bootstrap sites given a bounded set of parameters. I need help with regards to architectural decisions, as over time, I have made very naive design decisions and I don't want to repeat this mistake with this project. For my PoC, I have taken an MVC approach to design, with the top-level architecture (see above) containing the following:</p>
  <ul>
  <li><p>CanvasComponent - this is the entry point for the application, a UI element in which the user can generate their website and be given to download it;</p>
  </li>
  <li><p>CanvasService - this service orchestrates the creation of the website, and has dependencies on a set of services (NavbarService, HeroService, FooterService);</p>
  </li>
  <li><p>DomService - this service is in charge of the creation of the DOM element at a high level sans styles;</p>
  </li>
  <li><p>ComponentService - these group of services (NavbarService, HeroService, FooterService) are in charge of the creation of the DOM element at a lower level;</p>
  </li>
  <li><p>FontService - this service is a Google font repository.</p>
  </li>
  </ul>
  <p>The above is something I put together fairly quickly, so I understand that it isn't perfect. I also have a few questions with regards to the direction of the project with regards to the scalability of it as I move towards productionalising it. These are my problems:</p>
  <ol>
  <li><p>I showed it to someone and they said they can't make sense of it... as it sounds like my CanvasService, DomService and component services create raw HTML, all of which are models that describe DOM elements. It seems very overly mis-engineered. the way we are developing our services isn't scaleable or manageable. If nothing else, it is an extreme violation of the open/closed principle. They will ultimately be huge &quot;factories&quot; that don't fully cover all the functionality of DOM elements. <strong>This is my main concern. How do I resolve this from an architectural perspective?</strong></p>
  </li>
  <li><p>Given the nature of the project, I am dealing quite extensively with raw html. I use a mixture of approaches to dynamically generate the required HTML. I wanted to ask if the above is advisable. What would be the cleanest approach architecturally to creating and managing blocks of HTML? Should I use raw string or create something more bespoke?</p>
  </li>
  <li><p>What would be the best approach to storing an assortment of styles per component (navbar, hero, footer) and then applying them randomly? From what I understand a style can be separated into two categories - a template and a theme. A template can have many themes, and a single theme can be associated with multiple themes. A good example is &quot;light/dark&quot; colour mode on a website. At the moment in NavbarService, I store a range of possible widths and heights in an array.</p>
  </li>
  <li><p>Are there any issues that my current architectural approach will present down the road besides the violation of the open closed principle (unknown unknowns)? In the past, whenever I have started projects like this, they have quickly become unsustainable. I lose interest, because I am wrestling with the code-base at that point. I want the process to continue to be enjoyable, and keep my code clean and manageable over the course of the project, as well as apply the best principles.</p>
  </li>
  </ol>
  <p>A sample demo is available here: <a href="https://stackblitz.com/edit/angular-ivy-2pga8q" rel="nofollow noreferrer">https://stackblitz.com/edit/angular-ivy-2pga8q</a> (each time you reload the page, a new navbar appears).</p>