mlntdrv.bsky.social
aProgrammingExtremist
92 posts
6 followers
21 following
Getting Started
Active Commenter
comment in response to
post
It's because the customer is also a dev team. The team lead has some hard rules and conventions like this.
One other comparable stupidity is the rule that abstract classes should prefixed Abstract*.
comment in response to
post
But yeah, what were we going to do without those mighty builders in place?
comment in response to
post
When I was introduced to the project, I was told the customer expert made a rule such that each entity has a builder (the pattern).
I asked what if factory fits better... awkward pause.
Leter I took a look at the code of most entities. They had little to no behavior so they weren't even entities.
comment in response to
post
The interest rates from a central bank?
comment in response to
post
At least these are a bit more sound-proofed than apartments, unless also sharing a wall.
comment in response to
post
Wasn't it Dyatlov?
comment in response to
post
Hmm, not impressed from a quick skim. Most of the files in domain directories were records (passive data) and behavior was in Services. Typical anemic domain model.
At least there was no abuse of conditionals.
To sum up: not great, not terrible.
comment in response to
post
A macro aggression.
comment in response to
post
Severely overpriced. This shit should be around 15 for "a buy".
comment in response to
post
If there were no dependencies held in fields, that method would have been a static one.
That's what static-by-design means.
(2/2)
comment in response to
post
Just a clarification.
When I said static methods, I meant static-by-design, not static-by-language-facility.
What that means is that the method can be an instance method as far as e.g. Java is concerned, but it is only instance so it can have access to fields that hold dependencies.
(1/2)
comment in response to
post
Turns out such a design has a name - Anemic Domain Model.
comment in response to
post
You might have just coined the term.
comment in response to
post
Truth.
Git enabled the impossible - parallelism in SW dev, which is what true agile (XP) fought against the whole time because later on integration would be a buttache (and still is).
Git "cured" the symptom the wrong way.
comment in response to
post
Minimal intervention is inevitable, to get tests in place.
The techniques from Michael Feather can be pretty safe.
Only downside is, even if you write them, they are far from programmer tests (the product of TDD). They will most likely be fine grained test-class-per-class tests with heavy mocking.
comment in response to
post
Right. Anyone who rejects your hypermedia talks and accepts AI talks is a merchant of complexity anyway.
comment in response to
post
Don't you feel the stuff that's been coming out of the Smalltalk world is particularly susceptible to this? Almost every innovation (Oop, agile) has been semantically diffused. REST might be the only exception, but not because it didn't turn to shit, rather didn't originate in the Smalltalk world.
comment in response to
post
comment in response to
post
Hmm, I think Persons should be in the domain, responsible for behavior spread among several `Person`s. Example:
Persons.included(vaughn, milan).distributeEvenlyJiraTickets(aTicket, anotherTicket, yetAnotherTicket).
If the domain was maths, then I would expect e.g. Numbers.included(1, 2, 3).max()
comment in response to
post
Yeah that interface is nicer.
discussers = Persons.enumerated(vaughn, milan)
comment in response to
post
It would be better to address the Person of interest directly.
Persons on the other hand would be suitable for other business logic, i.e. electing the smartest Person from a pool of `Person`s.
comment in response to
post
Persons.connect(personId, contact) is like entering a room full of people and saying "hey all, IDK and care which one of you has an id of 123, but whoever it is, add this Contact to your contacts.
comment in response to
post
The name was not such a big deal, it's worse that Persons seemed like a global all-knowing god class, a bag of procedures, which operates on data that is only provided as arguments, and most probably encapsulating only its dependencies (store). Also displayed a bit of primitive obsession (personId).
comment in response to
post
Seems like Collection is causing too much confusion.
I will replace it with Bunch. A BunchOfPersons is the same as Persons in domain terms.
Now let's see how they look at object creation:
discussers = new BunchOfPersons(vaughn, milan)
discussers = new Persons(vaughn, milan)
"New persons" sounds off.
comment in response to
post
Every domain has the concept of collections. That's how one represents multiple objects of the same kind.
If this clashes with a programming language's shitty data structure API, tough luck. To avoid the clash there are a plethora of namimg options.
comment in response to
post
But still anabolic steroid positive...
comment in response to
post
Tariff bear market is over?
comment in response to
post
Lol, is the Tower of Pisa architecture when shit happens early on, but we choose to ignore the feedback, build the thing anyway and then put it in the failure museum so we can point at it and say "don't do it like this"?
comment in response to
post
It might be an English language issue. In Aristotle's language it might be perfectly fine.
comment in response to
post
It's because of daylight. Let's see the tradeoffs with the opposite approach:
- sunrise at 9:00 during winter if we stick with summer time
- sunrise at 5:00 during summer if we stick with winter time.
comment in response to
post
0% test coverage means shitty tests. 100% test coverage means nothing, it could still be shitty tests, it could be awesome tests, there is no way of knowing by just looking at coverage.
Mutation coverage however, ...
comment in response to
post
And then also actually using it in every class, when in reality you only needed to use it in 3 or 4 singletons.
comment in response to
post
Yes, that's it.
comment in response to
post
I think I can also call it vendor lock-in. The vendor employees are not confronted for doing a half assed job, because no other vendor will be able to maintain their mess, leading to securing the vendor's business in the long run.
How would you explain to such a company that this is unhealthy?
comment in response to
post
It's roughly the ReactiveX's tap equivalent.
comment in response to
post
There are easier distributed systems, but what makes MS particularly difficult is partitioned data. Distributed transactions and sagas are such a buttache, that it's not worth the cost unless it enables some kind of cancerous growth in your organization.
comment in response to
post
Building teams that perennially have to clean up after themselves, maintain the horrible mess they created, gets customers stuck with the company. Kind of a "job security" on a business level. Those teams make their company big bucks and suit your definition of a manager's job, how can you counter?
comment in response to
post
Wow, that was really interesting. Make the API self documenting and self revealing (in portions)...
What's been your experience with the cross-context hyperlinks: did it introduce a bit more coupling between affected contexts than ideal?
comment in response to
post
comment in response to
post
That's been my experience but I thought I was a bit late.
Nice to hear that I might be just fine.