Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
Suppose we want to model a blog based on Domain Driven Design practices. The main entities are Blog, User, Post, Comment and Like. So, how do you define your aggregates, value-objects, and repositories? By DDD definition, Since all of the entities are dependent on the Blog entity, it seems that there is just one large aggregate with Blog as it's aggregate root. However, It brings too many consistency and performance challenges.
You should model your aggregates based on consistency requirements. The larger is the consistency boundary => the larger is the aggregate.
Do you think is it valid to have just one aggregate root with Blog as it's root. From there we can have blog.Posts, blog.Posts(id).Comments, and blog.Posts(id).Likes
Having only a big/god-like aggregate Blog offers the biggest consistency boundary but it drastically affects the performance. Think about this: every time somebody creates/publishes/unpublishes/likes a post, posts/edits/deletes a comment then the entire Blog aggregate is loaded, the action is performed on it's nested entities and then it is persisted. All in a single transaction.
I recommend you to read this blog post about designing aggregates.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 months ago.
Improve this question
I am new to REST API, and I am designing my own REST API for my web project.
Which of the followings is the better convention?
I want to access to the article that user ID 3 wrote.
/user/3/article
/article?user_id=3
Thanks.
Which of the followings is the better convention?
They are both fine.
/article?user_id=3 may prove more convenient if you are expecting to use HTML forms as a way of finding resources.
/user/3/article may prove more convenient if you expecting to use dot segments to describe other resource identifiers in the hierarchy.
What if I want to access to the fourth article that User ID3 wrote? /user/3/article/4 is appropriate? I think this hierarchy is unnecessarily deep.
Deep hierarchies are fine. Not using deep hierarchies are also fine.
In some designs, we'll use resource identifiers for items that are not part of the same hierarchy as the collection itself
context="/user/3/article" rel="item" href="/articles/4"
context="/user/3/article" rel="item" href="/articles/9"
context="/user/3/article" rel="item" href="/articles/16"
Think "web page with links"; if you can follow a link, you don't need a formula to compute the URI yourself.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
Currently I am doing the aggregation & business logic (joins, revenue calculation, ect) partly in an SQL database and I am wondering if there is a general best practice for this?
With this little information available, it is hard to give you proper advice, but as a general rule of thumb, the more business logic you can implement in the database layer, the better. SQL Server is good for set-based calculations and aggregations, and that's typically what business logic would be based on.
Another advantage is that by implementing the logic in the database, your data/business logic definitions are conformed, and can be based on the business signing off on the definitions. If you'd leave that part out, when 2 different analysts will attempt to create the same business logic in Power BI, they might end up with slightly different implementations that could lead to different results. By implementing it in the back-end, both analysts would get the same output, no matter what.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I'm working on a side project of mine using rails api. The app is like a project manager which the structure is gonna be different based on the company type. For example a company which is doing production is different with a company that provides services. Does it make sense to use multi db in this case so based on the company type the users are gonna have different interface and structures?
Thanks for your time in advance
It makes sense to use multiple databases when you're reaching the resource limits of a single database in your application. Of course this presumes you have also followed best practices along the way (efficient queries, effective caching strategies, etc.) Rails 6 has support for replicas which allow you to automatically separate your db writes from your db reads based on the HTTP verb. Beyond replicas, Rails 6 supports using a distinct database with its own replica for a custom collection of ActiveRecord models.
For more details I would recommend taking a look at the Rails Guides on Multiple Databases.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
After hours of searching on google on the above mentioned topic. I am unable to contrast the difference between model based testing and model driven testing. Tons of definitions are there,. But there is no clear definition with real world example.
Can anyone please help me understand the difference between these two with the help of real world example.
I'm afraid there is no clear-cut difference between the two. First, because everybody uses a different terminology (there is no "standard" definition for these terms). Secondly, because IMO, both terms refer to the same concept (using models as part of the process of writing the tests for your system) and only differ regarding the importance of the role of models in the testing process.
To me, model-driven implies a stronger role of the models (i.e. models are used to derive the tests) than model-based (where models are used but maybe as an additional input in the test generation process).
At least, this is how I explain other "model-based" vs "model-driven" concepts as I tried to explain in more detail here: http://modeling-languages.com/clarifying-concepts-mbe-vs-mde-vs-mdd-vs-mda/
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
Anyone knows some design patterns for hierarchical structures? For example, to manage inventory categories, accounting chart of accounts, divisions of human resources, etc..
Thank you very much in advance
EDIT: Thanks for your interest. I am looking for a better way of dealing with hierarchical items to which they should apply operations depending on the level of hierarchy. I have been studying the patterns by Martin Fowler, for example Accounting, but I wonder if there are other more generic.
The problem is that operations apply to the items must be possible to change even at run time and may depend on other external variables. I thought of a kind of strategy pattern but would like to combine it with the fact that it is a hierarchical scheme.
I would appreciate any reference to hierarchical patterns and you'll take care of them in depth.
The composite pattern immediately springs to mind. Paraphrasing the wikipedia definition, the pattern allows you to compose objects into tree-like hierarchies (of branches and leaves) and treat single instances, or the composition as a whole, uniformly.
I've tended to use it in my work to represent complex view structures but imagine it might be helpful in representing inventory categories or divisions of human resources.