51–60 of 97 posts
Earlier quoted context omitted.
I love technical reading but found DDD a really hard book to get through. I've been meaning to read the Vaughn Vernon books to figure out if they're an easier read for when I feel like I need to refresh my memory.
Have you tried Scott Wlaschin's book. It's a very easy read.
Better article: https://dev.to/cheetah100/domain-driven-disaster-147i The biggest flaw of DDD I've run into is there's no emphasis on when not to use it. There's no mention that over-coding business rules into modules and services locks you into businesses processes that are slow or impossible to update. There's no mention that most times you want to build services that offer platform capabilities, not focus on what…
"XDD" for all X is overrated, in the sense that the ideas attract adherents who use them as the hammer for all nail-looking things. Yet the best way to present any XDD principles is to ignore the rest of the world and alternative approaches, otherwise you'll get bogged down in all the qualifications and exceptions and lose the central thread of what you're trying to communicate. The article is probably correct that b…
Better article: https://dev.to/cheetah100/domain-driven-disaster-147i The biggest flaw of DDD I've run into is there's no emphasis on when not to use it. There's no mention that over-coding business rules into modules and services locks you into businesses processes that are slow or impossible to update. There's no mention that most times you want to build services that offer platform capabilities, not focus on what…
I agree with his point that DDD will restrict an application that could be generic to a specific domain. When you can build something generic you should. But not everything can be made that way.
Also: "someone who should not communicate with humans" is a little bit too much.
Better article: https://dev.to/cheetah100/domain-driven-disaster-147i The biggest flaw of DDD I've run into is there's no emphasis on when not to use it. There's no mention that over-coding business rules into modules and services locks you into businesses processes that are slow or impossible to update. There's no mention that most times you want to build services that offer platform capabilities, not focus on what…
That article misses some important nuances. Yes hard coding business logic can land you in hot water. But you don't need to do that domain driven design. What you do need is the domain to specify the flexibility of your design. Almost all business need an accounting system. An accounting system can be built following domain driven development. But for it to be useful to many businesses it must be flexible. So the rul…
Domain driven design is about understanding the business requirements enough to know “this is fundamental to the domain” versus “this is going to change next month”.
In the accounting example, when you talk to the accountants and develop an ubiquitous language, you’ll notice that long term concepts are “assets”, “transactions”, “taxes”, etc. while the transient things are exact tax rates, how transactions are structured (eg, net 30), etc.
So you’d build your system to match:
- A foundation of transacting assets/currency/inventory
- A system for defining transaction flows
- A system for reporting transaction aggregates (eg, for tax filings)
Domain driven design doesn’t say which of those to hardcode versus make user configurable — it says to talk to your users until you understand the domain, then build software that reflects that.
Like most good ideas, people get way too formulaic about it sometimes.
tl;dr but i wholeheartedly disagree. i can live without the lingo but the concepts are incredibly important. especially in large and complex projects. even though, in essence, it is all merely about encapsulation of data and actions that can be performed with/on them within context. it is good to have some general understanding of what is actually being done, conceptually. and having a philosophy with a name helps.
For example, from a domain driven point of view Awk operates on a simple structural hierarchy of input and output files, lines and fields; designing a nice DSL around the obvious operations on these entities is clearly a much greater achievement than designing (or rather postulating) this model.
My organization was in the hype about DDD for years, so I practiced it for quite some time. I would say many parts of it is overrated. But there's still great parts. Here's what I learned: 1. It's a specific version of Model-driven Architecture. And the idea is very close to Hexagonal Architecture, Clean Architecture 2. There are a lot of cases when it's not worth it. If you don't have the vision to evolve your syste…
I'm a Scala dev and I know monads, but what exactly is TMonad? Like `[T: Monad](users: T[Users])`?
> 2. Although it claims to help you to build pure models, the platform you're targeting will most likely still decide your model
I think that is a crucial point. In fact, the platform _is_ very often part of the domain and should be part of the language in DDD. It's one of the reasons why no-code solutions fail and why there is often a mismatch between developers and product-team - the latter does not see these things as part of the domain, but they are and if you don't describe them as it, there quickly is a mismatch between dreams and reality.
Earlier quoted context omitted.
Have you tried Scott Wlaschin's book. It's a very easy read.
I haven't, is this the one? https://www.amazon.co.uk/Domain-Modeling-Made-Functional-Dom...
Also I'd recommend getting it from here. https://pragprog.com/titles/swdddf/domain-modeling-made-func...
Just because I personally like the pragprog site.
On the other hand, "Documentation Driven Design" is definitely underrated and an excellent way to end up with a very nice API.
Or “literate programming”