Benefits of Domain-Driven Design in Nuxt Apps
vueschool.io
vueschool.io
The most important aspects of domain driven design (as per Eric Evans himself) are probably the ideas of a ubiquitous language (so developers and domain experts understand each other) and bounded contexts (so you don't conflate two different views of a particular domain concept into a single implementation).
I have to say that over the years I've become less enamored with associated object-oriented approach of entities and aggregates when it comes to an information processing system.
DDD likes to model things in terms of interacting entities, but I think a more functional, ETL-ish approach is closer to what our information systems are doing. Taking data from one place (UI, database, 3rd party service, etc), transforming it, applying business logic, and sending the result somewhere else. You can still leverage the benefits of a ubiquitous language and bounded contexts, you just model things as flows of data rather than interactions of entities.
I suppose I'm digressing here, but ultimately, this article is really only scratching the surface of DDD.
Not quite, DDD is based on the idea that the domain model is the one driving the design of an application. The domain model is just a data structure that reflects functional requirements, and the application is just a bunch of code that directly or indirectly operates over that data structure.
> DDD likes to model things in terms of interacting entities, but I think a more functional, ETL-ish approach is closer to what our information systems are doing.
DDD is the embodiment of the ETL-ish approach. You get all those and values from services, operate over then, send the transformed data to services, rinse and repeat.
You are right! I learn something new every day.
"Although a model-driven design does not have to be object oriented, it does depend on having an expressive implementation of the model constructs, be they objects, rules or workflows. If the available tool does not facilitate that expressiveness, reconsider the choice of tools" - Eric Evans, Domain Driven Design, Ch 5
Now although Eric specifically states that a model-based design doesn't have to follow an OO approach (he gives Prolog/Rule Engines as an alternative), the bulk of the rest of his book does demonstrate how to model a domain using OO techniques. I guess that is why I (and maybe most people) associate DDD so strongly with object oriented design.
I wonder if he had written his book in 2020 he would have included functional modeling approaches along side the OO examples.
https://pragprog.com/titles/swdddf/domain-modeling-made-func...
I'm not sure I'd call it "dead-simple". I agree with the thrust of the article, but the difficulty of DDD is proportional to the difficulty of understanding your domain and the problem you're solving. DDD at its essence isn't really about the code; I think that makes many software engineers (including myself at first) uncomfortable.
There's no free lunch -- DDD is just a (really good) approach to extracting as much knowledge as you can from the domain, with some guidelines for manifesting that knowledge in the architecture of your program. But it's important not to confuse the coding guidelines for the domain modeling.
The problem domain I'm working in has been difficult to get a handle on, because some things have been traditionalized or operationalized to the point that it's sometimes hard to find someone who knows why the domain is how it is. (I'm not saying those people don't exist; but they're less easy to reach.) It's taken nearly a year for the team I'm on to build up a sufficient domain model. It was anything but "dead simple". Worth it, though? Absolutely. But it's likely to be hard going unless you're already domain experts.
Then again, it could just be the obscure terminology. Every time I read about it, I keep thinking "there's probably a much easier way to explain this" and it's frustrating. So much jargon.
Pluralsight has a nice DDD Learning path which has 2 popular & recommended courses in the above podcast, "Domain-Driven Design Fundamentals" & "Modern Software Architecture: Domain Models, CQRS, and Event Sourcing".
You're probably familiar already with the books "Domain-Driven Design: Tackling Complexity in the Heart of Software" & "Domain-Driven Design Distilled".
That's my sentiment, too. The descriptions I've seen give primacy to the code-related patterns, like "Aggregate" and "Entity", but increasingly I think they're the result of applying DDD, not the starting point. (And, as oft noted, they arise in a distinctly-flavored OOP context which has fallen somewhat out of favor.)
My team has had to pick things up as we go, but we have the benefit(?) of a complex domain, so we worked our way backwards to first principles anyway.
The most important part, we've found, is that someone on the team has to be a domain expert, and anyone planning/designing/architecting features must be an expert at least in the aspects they are working on. The reason is simple, if daunting: software is automation, and we are ultimately automating a domain process that would be undertaken, at least in principle, by a human. If we are to tell a machine what to do, we must understand the process at least as well as the human who would undertake it -- and potentially more so. It simply doesn't make sense to have a non-expert team build a supposedly-expert system.
(This is of course why "the customer" is such an important part of an Agile team. Sometimes the customer's expertise is enough, by proxy, to effectively design a software-based solution. But even then, that expertise gets processed by somebody into software-oriented tasks.)
Since our domain is particularly complex, we've found it valuable to distill our knowledge of the domain into a "domain model" document. This makes sure that there's a single source of truth for domain understanding on the team, which keeps things from otherwise getting too out-of-sync. It's particularly valuable to assign a single editor to that document, to maintain cohesion across the model.
The key point about a domain model is that it does not describe a particular software solution, and should not be especially biased toward the needs of software. On the other hand, it should organize the domain in ways that reduce redundancy, capture similarities and differences, etc. Put differently, software engineering is a domain of its own, and we should be able to bring our experience with abstraction and modularity to bear.
Whether explicit (documented) or implicit (known by experts), a domain model should illuminate the global structure of the domain. Boundaries between parts of the domain should start to become visible, and the relationships across those boundaries speak to the ownership and flow of information. This is where DDD "bounded contexts" emerge, and where the so-called "ubiquitous language" becomes meaningful.
The domain model doesn't solve a problem, but it brings it much closer to the software engineering domain, and makes it much more tractable to use prototypes to identify gaps in the model or to try different approaches to automating different domain processes. It should be much easier to get a birds-eye view of how the whole system behaves, even before software enters the picture.
Well, no, it's not. It's true that DDD-based architectures (like Hexagonal or Ports & Adapters) do provide guidance on code organization (I teach courses on this), but to say that code organization is DDD is misleading at best.
As others have said, DDD is so much more than that, and I'd summarize DDD as making Domain Concepts and Behavior primary, instead of the Data (and databases) being the focus.
That take is disputable.
Arguably, the focus of DDD is indeed the data, because the data structure is designed to reflect functional requirements dictated by the domain, thus serving as a model of said domain.
The focus of DDD is to implement that data structure that allows to model the domain, and from there drive the application design.
Databases are not relevant, though, as they are just an implentation detail of an external service. In fact, databases follow a persistence model, which more often than not is significantly different as it's dictated by implementation details.