Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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: You lack of experience in making complicated/complex software ! No, it's you lack ability to produce simple software, it's your fault.



Teaching-scale and production-scale programs are very different. Teaching-scale, where students start with a blank sheet of paper, are better served by simple approaches. You can't put enough complexity in there to warrant a complex framework.

I would like to see a course with a "maintenance" module, where students have to make changes to an application that's maintained over the several years of the course running. Including dealing with mistakes made by previous students.


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.


Breaking complexity, and ensuring it stays broken. "This data is read only, you shall not corrupt our state, deal with it" is an even more important design pattern than a shared domain vocabulary.


You surely don't know if there exists a practical real world application which only uses function. (Because you don't have access to codebase of all real world applications).

That's why your statement is logically wrong. I have no more word to say here.


I never said that. I said you can’t _only_ write functions. If you model properly, you absolutely can have a purely function based system. But if you skip the modeling and listening step, you will 99% end up with junk.


Hehe, actually, i intentionally use the "useful software", instead of perfect, good design, scalable,... software. If you skip that details, all furthur logic will be in wrong context.


Students are never writing enough code that "what logic goes where" really matters.

But on large applications it does, and DDD is an opinionated viewpoint on how to make those decisions.


> Hey guys, just use function, that's all you know to make usable software

"Those who can, do, those who can't, teach" comes to mind


"Those who can make shit, do. Those who can't make shit, teach"




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: