UK-AL

24 ms·

241.
by UK-AL 9y ago
This is demonstrably false, because otherwise the logical conclusion is to do everything yourself. Including growing your own food. The entire premise of market economies is that people are better at different things and by working together
242.
by UK-AL 9y ago
This is terrible advice in the general. I've known lots of people following this advice, to peruse a career in a field that doesn't really pay much. Ended up struggling and stressed.
243.
by UK-AL 9y ago
Software design is relatively timeless. Your not learning technologies, your learning how build software in general.
244.
by UK-AL 9y ago
Time
245.
by UK-AL 9y ago
Because it's more efficient. If your a software developer, 1 hour of your time could probably buy many hours of time from someone else.
246.
by UK-AL 9y ago
It actually makes front-end developer feel like 'proper' software development again. Previously it felt like strapping together a bunch of jquery scripts.
247.
by UK-AL 9y ago
"extra 25-50%" - That's really bad financial mangament on the employees part. 20-50% per annum extra, invested and compounded is A LOT of money. Literally for some people that could be an extra million at retirement.
248.
by UK-AL 9y ago
Ironically I find the developers, who have stayed at company for 10 years the worst for this. They've been maintaining the same product, for similar requests for the past years. Doing the exact same thing. Moving to different employers
249.
by UK-AL 9y ago
It's not a illusion if they can get it.
250.
by UK-AL 9y ago
"you need to replay all the events" If your aggregates have millions of events, I would suggest snapshotting, or mementos.
251.
by UK-AL 9y ago
In the startups arena in my area, i'm surprised when I see a CTO or CEO over 35 tbh. Average seems 27/28
252.
by UK-AL 9y ago
The repository pattern in the original example would allow you serailise your objects to whatever datastore you want. His object design isn't that great for being persistence ignorant though. I would instead do something like this.
253.
by UK-AL 9y ago
This guy has been thinking about this properly.
254.
by UK-AL 9y ago
"Most companies don't find it economically justifiable to re-write based on slightly different customer requirements and most companies have many deployments," Then don't. Make the domain model customisable with various
255.
by UK-AL 9y ago
You identify what customers want to customize, and provide a way customizing that. Some customers want 10 courses per student, others 5 courses. You could easily model that in a domain model. If you want something radically different, then
256.
by UK-AL 9y ago
"One day someone is going to want slightly different rules for student course registration and then they'll realise this rule is baked into the core and that's sad." This is a desirable trait, and one of the main points
257.
by UK-AL 9y ago
Bi-directional models come with their own problems.
258.
by UK-AL 9y ago
In this case it isn't that bad since its only loading registered courses for that specific student. Which for a student would be limited(10?). In fact it should probably be a business rule inside RegisterForCourse that a student can on
259.
by UK-AL 9y ago
You can persist this model using anything you want. You would have some kind adapter/library that handles the persistence. It would take these models, and covert them into your datastore.
260.
by UK-AL 9y ago
Which is essentially what this is.
261.
by UK-AL 9y ago
Nothing about DDD says you can't use multi-dispatch. If this how you think about the problem. Then this is your solution if your language is capable of expressing it.
262.
by UK-AL 9y ago
CQRS and entity central solutions normally go together like peas in pod. Command side has a domain model, which would be your business objects in this case. A command simply loads the entity, performs a method on it, saves it. Query has a q
263.
by UK-AL 9y ago
Most CQRS/Event store systems, simply just build up OO style domain objects by applying events to them. Then apply a command to the domain object, then save the emitted events. They are still entity centric.
264.
by UK-AL 9y ago
All your trying to do is match their language, so its easier to develop against a description of a use case. Technically either way allows you do what you want to do.
265.
by UK-AL 9y ago
"students can be registered for course" - This is already implying an order.
266.
by UK-AL 9y ago
Actually I think this is a major advantage. They are not complexities, they are putting down into code how you think about your application in your head. If your design is some data, which you can mutate however you want to get the job done
267.
by UK-AL 9y ago
This is actually a part of understanding the specific domain. How do the educational practitioners think about the problem for application your working on? Is the application student or course centric? This is big part of DDD, and involves
268.
by UK-AL 9y ago
This is solved by DDD and aggregates. Here's how i would do it. Course - Aggregate Root Student - Aggregate Root RegisteredCourses[RegisteredCourse[]) - Sub Entity Collection - with id reference to course. With metadat
269.
by UK-AL 9y ago
Still easier than having separate domain models. Adhering to dry in all cases, is not always the best solution. As the software community has discovered over the past years. Especially in relation to microservices. In my software there&#x27
270.
by UK-AL 9y ago
"presence of sql escape characters" - isn't a business rule. That's technical. Range acceptance - could defiantly be a business rule. Cross-field consistency - Could also be a business rule. I implement these rules both

More ›