Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Domain Driven Design?

yehohanan7.medium.com

Post reply on HN
Print view View original

71–80 of 175 posts

Re: Why Domain Driven Design?

#71

Post by marcosdumay »

goto11 wrote: post #65
tester756 wrote: post #50

Earlier quoted context omitted.

It sounds like you started designing system from database perspective But doesn't this "skew" your domain model in code by affecting your thoughts by technical details? I'd prefer start with some event storming session? visualization of system and connections then design proper domain model, correct abstractions, events between those modules inside system then just implement persistence layer with mapper from domain…

> then just implement persistence layer There is two ways of thinking: 1) The database schema is the fundamental model of the business, and all application logic is built on top of that. 2) The application logic is the core and the database is just a utility for persistence of data. I'm firmly in the first camp and assume the GP is also. I believe data is more crucial and will last longer than any specific applicatio…

It's not that one of those is correct and the other wrong. The issue is that one of those can change very easily, but it's much harder for the other.

Also, data definitions are entirely language based, so if you doing DDD, most of what you need to discuss with other teams gets formalized on the data model, not on the logic.

Re: Why Domain Driven Design?

#72

Post by marcosdumay »

BulgarianIdiot wrote: post #39
marginalia_nu wrote: post #13

Earlier quoted context omitted.

> But do you know what helps? Having physical boundaries you can't cross so easily. Microservices. Or as I call them... just "services". Eric Evans has said that people using microservices may represent the most successful application of DDD's principles, not because people using them were fans or even aware of DDD, but microservices enforce the patterns DDD Evans was describing. Sir, your assembly code is so hard to…

Exactly. We need RECURSIVE DIVISION of compute/state entities. Our main mistake is that we invent a level of division, and never make it recursive, i.e. a class is badly designed to be an entire module, it can't contain classes (inner Java classes are not what I'm talking about), nor can classes cross machine boundaries easily in many languages and so on. We need a unit of division that works across machines just as…

Modules are recursive. Libraries are recursive. Hell, functions and classes are recursive too. I don't think we have any non-recursive code abstraction tool.

Some of the problem is that people need different capabilities from different abstraction layers. The rest of the problem is that there are a lot of incompetent people creating software.

Re: Why Domain Driven Design?

#73

Post by camgunz »

cies wrote: post #33
camgunz wrote: post #26

I think about this a lot, and I think my core beef with stuff like this is: - Engineering team has a problem - Engineer/Lead/Architect reads a book - Whole team builds an in-house, bespoke framework around the book's ideas - They now have 2 problems I'm very against in-house frameworks; I think they almost never deliver on value, and you should just use Rails/Django/etc (again, you almost certainly won't outdo them).…

> I think that Django is basically DDD/CQRS/SOA Sure you can do DDD in Django. But I do not find that framework inherently CQRS of SOA (not SOA due to it's monolithic nature). Maybe a monolith on BEAM (Erlang, Elixir) could be marked as SOA due to the nature of BEAMs concurrency model. > engineers aren't bogged down with irrelevant stuff like request (de)serializing Last Django app i saw sure had a lot of this boiler…

> Sure you can do DDD in Django. But I do not find that framework inherently CQRS of SOA (not SOA due to it's monolithic nature).

Django has "apps", which--while they do run in the same process--aren't intended to use code from each other. They're supposed to have their own models/views/templates/migrations/etc. They're effectively different services, as long as you don't think a service has to be available at a different network address to be a different service (think of mounting different apps or microservices behind different URLs, for example).

Also, I wouldn't say Django is CQRS--CQRS is more or less a different phrasing of "JSON-RPC", which "REST" has become.

> Last Django app i saw sure had a lot of this boilerplate going. I saw this talk and thought: well this is finally a "framework" that allowes me to do away with serialization (as in: in this framework the amount of extra work you do for making the app an SPA is fairly minimal):

Eh, some people are highly allergic to any boilerplate, but like, the DRF example [0] has practically none.

That Elm video is interesting, but I'm skeptical of anything whose central claim is "I can easily turn front end data requests into SQL and back again in very few lines of code". There's just a lot of inherent complexity there, and my evidence is every mainstream ORM, plus all the "backend-as-a-service" products that are multi-1000s LOC. Then again I think SQL is a great (legendary, honestly) language and we should stop trying to replace it.

[0]: https://www.django-rest-framework.org/#example

Re: Why Domain Driven Design?

#74

Post by LAC-Tech »

goto11 wrote: post #65
tester756 wrote: post #50

Earlier quoted context omitted.

It sounds like you started designing system from database perspective But doesn't this "skew" your domain model in code by affecting your thoughts by technical details? I'd prefer start with some event storming session? visualization of system and connections then design proper domain model, correct abstractions, events between those modules inside system then just implement persistence layer with mapper from domain…

> then just implement persistence layer There is two ways of thinking: 1) The database schema is the fundamental model of the business, and all application logic is built on top of that. 2) The application logic is the core and the database is just a utility for persistence of data. I'm firmly in the first camp and assume the GP is also. I believe data is more crucial and will last longer than any specific applicatio…

Might I humbly suggest being flexible?

I'd tend towards one as well, but a lot of real world constraints can throw that out the window.

Re: Why Domain Driven Design?

#75

Post by marcosdumay »

turtleyacht wrote: post #7

DDD sounds amazing, but y'all the pull requests are usually a dozen files with tiny changes. At least from what I have seen. And the promise is "change is easy" or "impact to existing code is low." This may be true. Is it? I have the Evans book. It may completely change the way I write code. But I also have "C Interfaces and Implementations," and that promises another. Yet another is Stepanov's "Elements of Programmi…

> I wonder if domain stuff surfaces naturally in SQL.

Only if your domain is very simple. Database types are not very expressive.

I wonder what is the minimum one must add to support actual people processes. Sum types and interfaces are a must, some kind of recursive namespace is clearly lacking, but those still don't seem sufficient.

Anyway, SOA is something that leads to a kind of segmented DDD. But the software development culture made such a mess with it that you simply can't do anything useful anymore once you acknowledge you are doing SOA.

Re: Why Domain Driven Design?

#76

Post by tiben_ »

dexcs wrote: post #64

On thing i often hear in the DDD universe: I do not want to know what the underlying database is doing. Just wanna safe my stuff. And so it goes that you have slow queries, both on sql and nosql databases because the programmer does not want to use the DB's own features correctly...

One point is code that is highly dependant on underlaying storage system (DBMS etc.) is hard to unit test.

Re: Why Domain Driven Design?

#77

Post by ki_ »

"In essence, all principles help you to model your software in a way that’s highly cohesive and loosely coupled- They are the building blocks of a well designed software."

My suggestion, stay away from all these design patterns. In my experience, they lead to overly complex code because of all the structure. The best structure is the most simple one.

"When you start thinking in abstractions and create abstractions in your code, either top down or bottom up, you will end up producing a good software design."

This, to me, is the most untrue statement you could make about software. Abstractions introduce more complexity, the more complex, the less stable and maintainable your software becomes.

If you want well designed software, you need to keep it the code simple, so its maintainable. Then add some tests to it so you are certain it works correctly. Working with a type strict language is also recommended. To me, this is the only way (right now) to build stable software.

Keep LOC low, keep file count low, stay away from abstractions and hidden code (unless it's very useful somewhere), keep the amount of types/classes low. TL;DR; you dont want a "code maze. aka. 10 million lines of structured code".

Re: Why Domain Driven Design?

#78

Post by BulgarianIdiot »

marcosdumay wrote: post #72
BulgarianIdiot wrote: post #39

Earlier quoted context omitted.

Exactly. We need RECURSIVE DIVISION of compute/state entities. Our main mistake is that we invent a level of division, and never make it recursive, i.e. a class is badly designed to be an entire module, it can't contain classes (inner Java classes are not what I'm talking about), nor can classes cross machine boundaries easily in many languages and so on. We need a unit of division that works across machines just as…

Modules are recursive. Libraries are recursive. Hell, functions and classes are recursive too. I don't think we have any non-recursive code abstraction tool. Some of the problem is that people need different capabilities from different abstraction layers. The rest of the problem is that there are a lot of incompetent people creating software.

If you start listing what different capabilities you need on each layer, you'll notice it can all be done, as a very lean abstraction, in one layer. I'm working on creating a platform that's doing just that, BTW.

I'll cite Erlang as an example that comes somewhat close to what I mean. An Erlang process is a function, a class, a module, and a remote service, all at once. It can be done. We just never stopped to truly think about it and try.

Re: Why Domain Driven Design?

#79

Post by marcosdumay »

Throw10987 wrote: post #55
youerbt wrote: post #18

I'm divided on DDD. On one hand there are some good ideas (system is model, language is important etc) that seems "obvious", but I guess still worth explicit mention. On the other hand there are implementation techniques that strike me as not really Domain Driven, but I Program In Java With Hibernate Driven (Entities, Value Objects & Aggregates section). I wonder why those two are married other than historical accide…

I think there is general acceptance that the implementation details in Eric Evans book could almost be completly skipped. The concepts of domain boundaries and the ubiquitous language are the useful if seemingly obvious bits.

Well, at least he says so on the book.

Re: Why Domain Driven Design?

#80

Post by marcosdumay »

bamboozled wrote: post #29
nurettin wrote: post #17

The problem with following a list of principles inside of a book is: It's hard and requires a holistic view of the entire manuscript which everyone has to remind themselves all the time. This is much more compelling: Why domain driven design? Because we have tools that detect deviations and give suggestions for expanding your models. Just like Rust constraining ownership, just like ruby on rails generating entities,…

I feel about the same about Scrum / Agile. The theory is sound, the principal is good, in the end the execution is often lackluster.

I disagree. The principal of Scrum is already rotten. Nothing in it leads to productive developers, only to micromanaged feature factories.
Post reply on HN