Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Search - "domain driven design"
-
Do anybody here work with a codebase that actually has tests?
Or at the very least, the codebase has a domain layer, rather than puking lines of code randomly in the controller?
Am I trying to find an unicorn?7 -
!rant
"If you want to find the secrets of the universe, think in terms of energy, frequency and vibration."
Nikola Tesla
If you want to understand your business, think in terms of customers, problems, and solutions.6 -
It is easy to believe something is over-engineered as a junior. You open a solution and get slapped in the face with a wet fish of many classes, with strange names, doing very little, with everything coming together in ways you don't understand.
My advice is to learn about design patterns, clean code, clean architecture, and model driven design. Until that point I don't think you can make such a distinction. And indeed once knowledgeable of patterns and techniques as well as the domain, the same solution can look obvious, elegant and readable.
In a field where everyone is saying 'dont over-engineer', one must be able to tell if something is actually bad, or just uses techniques you don't recognise.
Telling your senior you think something is over done just because you don't understand it is not good. First learn techniques, understand the code, then form opinions that are at least relevant then.
From someone who committed that crime.4 -
Rails. Fucking rails...
God damn monoliths, built by a cowboy coder.
Every one I have ever worked with becomes (or already is) a house of fucking cards that will blow over at the slightest gust of wind.
The worst part is that you always hear the same justifications from rails developers, then after they convince the higher-ups that “we will build it right, not like those other monoliths” we find ourselves F’ed right in the A a few months later.
It’s this frustration that lead me to MUCH better paradigms like Microservices, Event-Sourcing, CQRS, Domain Driven Design and the like.
When someone says “our backend is in rails” my first response is “so when are you replacing it?”8 -
Rant to discuss Domain Driven Design (DDD) architecture.
Did anyone implemented on production?
How scalable and easy to use?
Do you recommend it? if yes in which environment? in which business types?17 -
I think I may be someone's wk101soon given how things are going for me.
So I get shipped over to the new offices to do some work. Initially, I was supposed to be updating SQL stored procedures.
That I can handle, well my task is now to build the skeleton project for a web API in core 2.0 using domain driven design and onion architecture which the rest of the team will use.
Okay, I don't have any experience in any of that at all. And god bless the team lead explaining some stuff to me. But it's going to take more than a 20-minute chat here and there for this stuff to sink in.
And being told just to build it how you think it should be isn't great advice when I'm trying to figure out how the systems work.
Every other API project I look at is structured completely different from one another so looking for patterns has failed.
I'm fucking stressed out every bit of information I'm getting on whats potentially happening with my job im getting second hand from people. Because I can't access my emails while off-site something I'm repeatedly flagging.
Every job advert is painstakingly making it clear how out of date my skill set is (or lack of). Evidently, I've been way too lax, and this has been a kick in the bollocks I'm not likely to forget.
If we're being evaluated on performance to see who they'll keep, then I've failed at the first hurdle.
Life lesson for those in education, don't be this knob head here and get comfortable when you land a job. Just knowing about the tech that's commonly used in your field does jack all study it.
Not a structured/meaningful rant and shits probably not as bad as I see it. I've only chewed through one fingernail after all.1 -
Test Driven Development, Pattern Driven Development, Domain Driven Development, Design Domain Driven Development.
When do we eventually get to the development part??3 -
Trying to implement DDD into this current project of mine but the whole concept of converting Eloquent objects into plain entities seems to be more work than it is worth.
But the whole methodology of DDD also seems rather complicated.2 -
Does anyone recommend this book: https://kobo.com/us/en/...
Just want to learn more about Domain Driven Design.3 -
Here is my problem. The team I'm on has developers from other areas that were "put" into a new team. Two use "structured programming" but the requirements make me think we need "domain driven design". How in the world can I get them to evolve into another mindset while still meeting the deadline?1
-
sorry for not ranting but im quite anxiously looking for a talk about Domain Driven Design. I think it was from Eric Evans but the ones I found yet arent it. he has a very speqking example of shipping which he usus throughout his talk, speaking in front of quite a big crowd, interacting with the crowd and no desk or anything in front..... Is there anyone who knows which talk I mean? Infinite kudo's to he who does!1
-
Any suggestions for good reading regarding the boundaries of Microservices? By this I mean a domain driven design approach.
I have a pretty good idea of what I “think” is right for my project. But something is telling me to challenge my idea.
For a little bit of background... I am using separate DBs for each Microservices, and building APIs to access the information across the system.2 -
So the project I have been working on for the past 5 months was finally released yesterday with only very minor problems, this stemmed from both programming side, and users entering data incorrectly.
It has been a rather hectic 5 months. I've had to deal with crap like:
- clients not knowing their own products
- a project manager that didn't document anything (or at least everything into a Google Slides document)
- me writing both requirements AND specifications (I'm a dev, not a PM)
- developers not following said specifications (then having to rewrite all their work)
But the worst thing I think would be the lack of vision from everyone. Everyone sees it as a "project" that should be get it over and done with rather a product that has great potential.
So with the project winding down, and only very few things left to fix/implement. Over these 5 months I learned a lot about domain driven design, Laravel's core, AWS, and just how terrible people are at their jobs. I imagine if I worked with people who gave a damn, or who actually had skills, I probably wouldn't have had such a difficult project.
Right now I'm less stressed but now feel rather exhausted from it all. What kind of things do you to help with the exhaustion and/or slow down of pace?1 -
So In Domain Driven Design, it is okay to have methods in your domain class to load children (lists) on demand? Example: Your aggregate root is Person. Then a person has a list of books that they’ve read. Is it okay to load that list of books by using person.GetBooks(); instead of loading the books when the person is initialized?2