Hi,
I'm relatively new to domain driven design. How would you model something like companies and stores? Our company exists of multiple other companies which all have stores. A lot of our applications have something to do with a company or a brand. For instance, they retrieve a list of companies or branches or data is stored for a specific company. We have a core service module that contains functions to retrieve and edit company data. So that would make the company domain a horizontal domain. Is that correct?
Now, there's also a frontend application to put in company data, because that's a manual task. Can that frontend be part of a horizontal domain? If I understand the OutSystems documentation and DDD slides correctly, it's not. But how do I model it then? A vertical and horizontal company domain? A horizontal company domain en vertical data management domain or something?
Any help is highly appreciated.
Hi Ramon,
To model the architecture of your application you can look into the context of how your business problem is organized. I'd suggest to look into the "lines of business" to answer your question about vertical and horizontal domains. In terms of application components, if you have core modules providing services to different applications, that sounds an horizontal domain (but depends on the context). Let me know if you need more help, good work!
Cheers!
Hi all,
Since you're talking about DDA and the place of a frontend application in this, I want to share a document that I found about frontend applications (not OutSystems) but where, maybe, we can find some interesting content that help us shaping our models and give us ideas to the future:
https://betterprogramming.pub/domain-driven-architecture-in-the-frontend-i-d27fb71b5cb0
Hope you like this lecture.
Best regards,
Ricardo
Thank you for the link @Ricardo Pereira. Indeed an interesting read
I think it's always a challenge to detach the human domain concepts which are generally way more abstract, from the concepts of DDA - and in general, a lot more info would be needed to properly assess a good fit, but here's my 2cents:
I get a "red flag" in my mind earing the concept of a company being put on an horizontal domain.
Now, it can be the case that your case of "companies and stores" have so little domain complexity/rules, with your applications being highly complex that DDD may not even be a fit, and that's perfectly fine.
Other than that, if your company/store concepts have their own "language", they definitely belong into their own vertical concept.
Regarding the Front-end Applications, you can leverage the foundation layers for the Themes and Templates and this is in fact an horizontal concept for your apps, but that's about it - unless, again, your domain is so simple (like just the company name) that you don't even have to fall into a DDD approach.
I was thinking about this and here's an example that may clarify it (or make it worse :D)
Let's say you have a Book store, with a selling front office and a warehouse for the books. It is natural to think of this store as a single domain/abstract concept, it's books - but not so in DDD.
This warehouse and selling front office should be modelled in their own (vertical) business domains, each with their own book concept, with proper context mapping between them.
Now, does it make sense for the above to have an horizontal front-end application concept for both the store and warehouse? I think it doesn't.
DDD solves scalability problems and gets the experts on those domains closer and enabled - it may not always be a fit, but that's the purpose in a nutshell, at least the way I see it.
I don't even much care about the physical aspect of it - like, are they sharing the same DB, metal, containers, opinionated frameworks - as long as the logical domain boundaries are isolated, it should eventually be possible to extract the benefits.