61–70 of 175 posts
My definition of DDD involves drawing up a series of relational tables in excel and reviewing those with the business stakeholders. If the product is like most, I'd then convert those excel workbooks to SQL schemas and start building some vertical slice demos. None of this has anything to do with micro services, source control, etc. The schema (domain) is the most important part of the product. If your manager can un…
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).…
Until we as a profession understand how to structure code and how it is different from simply choosing Django vs flask, these discussions will not be productive.
Earlier quoted context omitted.
I think the OP is leaving out some of the other steps they also take. The tables give you common language for talking about the entities involved in the business logic that actually does the work. Though I think I agree with you anyway, it is a chicken and egg problem. You can't know all things you will need schema for until you understand the businss logic requirements well, but it's hard to talk about those require…
It is inherently flawed though, isn't it? It assumes you're in just one big schema, surely? Part of DDD is breaking that assumption and fragmenting your systems into the disparate domains withing your org, fully encapsulating your domains' functionality and data. As someone else said, it's probably better to start with what events drive your org. What are the communication channels and triggers for those events.
My definition of DDD involves drawing up a series of relational tables in excel and reviewing those with the business stakeholders. If the product is like most, I'd then convert those excel workbooks to SQL schemas and start building some vertical slice demos. None of this has anything to do with micro services, source control, etc. The schema (domain) is the most important part of the product. If your manager can un…
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…
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 application. Thinking of the database as mere "persistence" for application logic is putting the cart before the horse.
I also believe in Fred Brooks:
> Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowchart; it'll be obvious.
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 teach programming and software design, too. But i never use domain, driven, design,... as vocabulary. I use function all the time. "Hey guys, just use function, that's all you know to make usable software." What's the problem with NOT following "weird, confusing" patterns and vocabularies. And the result is, all of my students actually make useful code, simple code. Also, most of software recruiters will tell you:…
This is impractical in real world applications. Breaking complexity is much more than writing better code. DDD starts with listening to the subject matter experts (the business) and agreeing on language and models. You can write a hundred functions that look good, but if it isn’t aligned with how the business thinks, you will have built spaghetti code.
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).…
Frameworks are not architectures, and architectures are not frameworks. DDD is an approach to building an architecture that emphasizes domain modeling. Done properly, all the web gunk (and there’s a lot of it) can be mostly isolated from the actual interesting part: the domain being modeled. Until we as a profession understand how to structure code and how it is different from simply choosing Django vs flask, these d…
I'm not saying they are; I'm saying you should outsource the building of a framework that implements your architecture of choice when you can. I would also go further and say that if you can't, you should pick a different architecture where you can.
The value in DDD is in the boundaries. It makes them explicit not just at technical but also organisational level. Then within a boundary you have a shared semantic model which is explicitly documented so visitors from other domains can "speak the language". So far none of that touches code - but Conway's Law generally results in a set of services at the boundary.
There is a shared semantic model both inside a boundary and outside. However, DDD has relatively little to say about the most crucial part of that too - how to shape and define that language.
DDD does, however, have a lot to say about how to misapply certain design patterns.
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).…
React was in-house framework. In-house framework is fine. Just be Facebook with necessary resources.
I think we're mostly saying the same thing haha. Most of us aren't MANGA, most of us shouldn't make a competing Django.