3 ms·
This article seems to be more focused on code organization, which I guess ties into the idea of a bounded context, but doesn't really dive into the nitty-gritty
by adamkl 6y ago
This article seems to be more focused on code organization, which I guess ties into the idea of a bounded context, but doesn't really dive into the nitty-gritty of DDD.
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.
- rualca 6y ago> DDD likes to model things in terms of interacting entities, (...) 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.
- adamkl 6y ago> 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. 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.
- scns 6y agoScott Wlaschin wrote a book in 2018 about DDD in F#. https://pragprog.com/titles/swdddf/domain-modeling-made-functional/ https://pragprog.com/titles/swdddf/domain-modeling-made-func...