Hi, I normally contract in MSBI, Oracle, .Net/.Net Core, focusing on a property platform at the moment. Have also been working hard on upgrading my limited company website too.
The reason you are struggling is because you are trying to fit the technology to the problem. I think you are thinking - I want to learn this technology, now I have thought up a requirement, I can now do this technology.
The problem with this framework based approach, is once you get into the solution, you may come up with a completely different strategy. Then the panic sets in that you aren't perfect and the whole experience just sucks.
I read Eric Evan's book on Domain Driven Design and thought, now I can move all the database code out to another layer, create domains and bounded contexts. Before you know it, you realise that it was easier the old way - that DDD is pretty much like logical models within a database. Eventually, it became a hybrid approach that wasn't really DDD at all but with a better application layer.
The way I approach these sorts of things is;
1 - I have these pain points or requirements.
2 - What technologies do I already know that may help?
3 - If my existing knowledge is not sufficient, what other technologies are there which may help?
4 - Start prototyping, designing, learning, thinking.
5 - Commit to an approach, I am fairly confident will work.
I am very keen to start using Svelte on my projects, as I didn't see the appeal of Angular or React - but, until I really see a planned use case for it, I won't commit to it.
To answer your question - despite what everybody else will probably say. Start with a data model. Keep testing the model, thinking, can this structure hold this data, if a user does this, can it help with this? Once you have that in place, you have all the objects where you think you need them, it gets you thinking about the solution.
You mentioned CRUD. Again, see how you are falling into the trap of thinking, it must be restful > I need to perform all actions on all data, all actions must be exposed or it won't be restful. Data just doesn't work like that. The idea an entire model can be exposed with Create, Read, Update, Delete is naive. There is Event Sourcing, which is very interesting and great for storing history - but not so good for reporting. There is also CQRS.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
The reason you are struggling is because you are trying to fit the technology to the problem. I think you are thinking - I want to learn this technology, now I have thought up a requirement, I can now do this technology.
The problem with this framework based approach, is once you get into the solution, you may come up with a completely different strategy. Then the panic sets in that you aren't perfect and the whole experience just sucks.
I read Eric Evan's book on Domain Driven Design and thought, now I can move all the database code out to another layer, create domains and bounded contexts. Before you know it, you realise that it was easier the old way - that DDD is pretty much like logical models within a database. Eventually, it became a hybrid approach that wasn't really DDD at all but with a better application layer.
The way I approach these sorts of things is;
1 - I have these pain points or requirements.
2 - What technologies do I already know that may help?
3 - If my existing knowledge is not sufficient, what other technologies are there which may help?
4 - Start prototyping, designing, learning, thinking.
5 - Commit to an approach, I am fairly confident will work.
I am very keen to start using Svelte on my projects, as I didn't see the appeal of Angular or React - but, until I really see a planned use case for it, I won't commit to it.
To answer your question - despite what everybody else will probably say. Start with a data model. Keep testing the model, thinking, can this structure hold this data, if a user does this, can it help with this? Once you have that in place, you have all the objects where you think you need them, it gets you thinking about the solution.
You mentioned CRUD. Again, see how you are falling into the trap of thinking, it must be restful > I need to perform all actions on all data, all actions must be exposed or it won't be restful. Data just doesn't work like that. The idea an entire model can be exposed with Create, Read, Update, Delete is naive. There is Event Sourcing, which is very interesting and great for storing history - but not so good for reporting. There is also CQRS.