I would like to use a common data structure of kubernetes to represent objects including services, replication controller, deployments, statefulset, daemonsets, etc. Now kubernetes api already provides individual data structures for each of them and the data structure that i could find the closest to representing a common structure are
type ObjectMeta
type ObjectReference
reference : https://github.com/kubernetes/api/blob/master/core/v1/types.go
The reason I do not select one of the above two structures is because I need to use the status field of most objects so that I can check if
`replicas==readyreplicas==Availablereplicas`
or to check for most things
Desired==Current==Available
There is no common structure which can describe each object in Kubernetes, except using some dynamic one, but it will be hard to validate the structure of objects based on dynamic objects inside it.
Each type has a different set of objects inside. If you want to work with Kubernetes objects, just use proper structures from core.
Related
I'm in the process of making an API for a database with three distinct categories: Systems, Products, Components:
database schema skeleton
Now, each of the above categories will have several tables. For example, there are many different types of components, such as cameras, monitors, power supplies, etc. And each one will have a table in the database.
I'm using NestJS to build an API for this database. One way I could approach doing it is to create a resource for every single table in the database. But the associated CRUD operations for each table within a given category has identical functionality. For example, there is no difference between the Cameras resource and Monitors resource other than the fact that they reside in different tables in the database.
For each resource within the same category, I would just be copy and pasting the same code over and over again, and I am curious if there is a way to overcome this code reuse.
So, I'm wondering if there's a way for me to write my controller, service, and module files for a parent resource called Components, and just inherit this exact functionality within the controller, service, and module files for all the child resources such as Cameras and Monitors?
A current project needs us to persist domain objects in a NoSQL database such as mongoDB.
In many examples (incl. Eric Evans, Vaughn Vernon) the domain objects are serialized and persisted to the mongoDB directly.
We would like to avoid mixing the domain layer with persistence related inforamtion by not having any annotations in our domain objects.
Also we are concerned about corrupting the persisted data by changing the domain object in the future.
We came to the conclusion that we need to have some kind of DTOs translating between the domain objects and the persisted data.
Did anyone of you come across a good solution for such a case?
Yes. Your domain models should be ignorant of persistence. So you need a DTO or what I call data models (apart from the domain models and view models). Your data models will be map to the domain models before persisting to the database. This mapping is pretty common in insert and update operations. For read-only operations (reporting, etc) you can bypass the mapping from data models and to domain models. That will prevent loading the whole object graph of your domain models. This is widely applied in CQRS architecture patterns where read and write commands are separated.
Like you, I want business objects to have no dependency on any kind of specific repository. I solved it like this: That have your business object define its state objects and repository functions as interfaces. Your repository implementation can create an actual state object and inject that into your business object using the constructor.
There are a lot of advantages to this approach (such as having business objects for specific purposes), but you easily achieve complete (two-way) independence of your repository this way. Martin Fowler also hinted at this approach elsewhere.
I actually use the same pattern in my Angular / TypeScript projects. My read-api calls return DTO objects that get state objects injected as well and their properties map directly onto state objects.
These DTOs that end up as untyped javascript objects when they come from the api to the client (Angular) project are then in turn injected as state objects into TypeScript objects, injected in the constructor again and mapped by getters and setters. It works very cleanly and is well maintainable. I have an example on my GitHub (niwra) account (Software-Management repositories), but can expand here if anyone is interested.
MongoDB allows for very clean and Unit-Testable repository implementations, that returns strongly typed aggregates. The only thing I haven't solved cleanly yet is telling MongoDb about state objects for child-collections. Currently that is pretty 'static' still, but I'm sure I'll find some nice solution.
You can store your domain objects as-is in document databases. Vaughn Vernon has posted an article The Ideal Domain-Driven Design Aggregate Store? about this, featuring PostgreSQL new (at that time) JSONB document-like storage.
Of course, you get a risk having your aggregates polluted by BsonX attributes, which you probably do not want. You can avoid this by using convention configuration but you will still need to think about serialisation and this can have an effect on the level of encapsulation.
Another pattern here is to use a separate state object, which is then held as a property inside the aggregate root (or regular entity). I would not call it a "DTO", since this is clearly your aggregate state. You are not transferring anything. Methods inside your aggregate can mutate the state or, even better, the state would be an immutable value object and new state is produced when you need to change the state.
In such case persistence would only care about the state object. You still might be unhappy to have MongoDb attributes on the state object properties and this is reasonable. Then, you would need to have an identical structure inside the persistence mechanism, so you can map properties on-to-one.
A current project needs us to persist domain objects in a NoSQL
database such as mongoDB. In many examples (incl. Eric Evans, Vaughn
Vernon) the domain objects are serialized and persisted to the mongoDB
directly.
I can confirm you that MongoDB is a good choice for persisting DDD models. I use MongoDB as an Event store in my current project. You can use MongoDB even if you are not using Event sourcing, for example using an ODM (Object Document Mapper): you have a document for each Aggregate instance (this applies to any document based database, not only MongoDB) and you store nested entities and value objects as nested documents.
We would like to avoid mixing the domain layer with persistence related inforamtion by not having any annotations in our domain objects.
You can use xml mapping.
Also we are concerned about corrupting the persisted data by changing the domain object in the future.
For this you can use custom migration scripts. If you use Event sourcing then there are event versioning strategies.
We came to the conclusion that we need to have some kind of DTOs translating between the domain objects and the persisted data.
This is a bad conclusion.
If you use CQRS you won't need DTOs because the readmodels are enough.
I am trying to understand when someone would use AddItemToSet vs StoreRelatedEntities.
It seems the former is a way to associate a set label with a string-based item handle.
The latter is a way to associate two entities, which seems like a more generalized operation.
What is it that AddItemToSet does that StoreRelatedEntities can't do?
Thanks
The AddItemToSet API in ServiceStack.Redis is a 1:1 mapping that calls Redis' Server SADD Operation, i.e. adds an item to a Redis SET.
The StoreRelatedEntities is a higher-level operation that also maintains an index containing relationship between the entities described in detail in this Storing Related Entities in Redis answer.
Reading a SO question, I realized that my Read services could provide some smarter object like ViewModels instead plain DTOs. This makes me reconsider what information should be provided by the objects returned by the Read Services
Before, using just DTOs, my Read Service just made flat view mapping of a database query into hash like structure with minimum normalization and no behavior.
However I tend to think of a ViewModel as something "smarter" that can have generated information not provided by the database, like status icon, calculated values, reformatted values, default values, etc.
I am starting to see that the construction of some ViewModel objects might get more complicated and has potential downsides if I made my generic ReadServiceInterface return ViewModels only:
(1) Should I plan some design restriction for the ViewModels returned by my CQRS? Like making sure that their construction is almost as fast as a plain DTO?
(2) DTOs by nature are easily serialized and ready to be sent to an external system in a SOA architecture or embedded into a message. Does this mean that using ViewModels will have a negative impact on my architecture?
(3) Which type of ViewModels should I keep outside my Read Services?
(4) Should I expect all ViewModels to be retrieved from Read Services?
In the past I implemented some ViewModels that needed more than one query. In a CQRS I suppose, that is a design smell, since everything they provide, should be in only one query.
I am starting a new project, where I thought that any query will return either aggregate objects or DTOs. Since now ViewModels come into play. I am wondering:
(5) Should I plan that queries within my architecture will yield two type of objects (ViewModels+Aggregates) or three (+DTO)?
View Models (VM) serve a single master: the View. We're usually consider the VM a pretty dumb object so in this regard, there's no technical difference between a VM and a DTO, only their purpose and semantics are different.
How you build a VM is an implementation detail. Some VM are pre generated and stored in a VM repository. Others are built in real-time by a service (or a query handler) either by querying the db directly or querying other repos/services then assembling the results. There's no right or wrong and no rules about how to do it. It comes down to preference.
In CQRS the important part is separation of commands from queries i.e more than one model. There's no rule about how many queries you should do or if you should return a view model or dto. As long as you have at least one read model dedicated for queries, it's CQRS.
Don't let technicalities complicate your design. Proper design is more about high level structure and not low level implementation. Use CQRS because having a read model simplifies your app, not for other reasons. Aim for simplification and clean code, not for rigid rules that dictate a 'how to' recipe.
I have a SpringServlet (from Jersey) that is exposing my JPA-annotated POJOs in a very basic manner right now. For example, rather than returning an actual represetantion of the object, I've just returned a field such as Name to play around.
Of course I want to return the actual representation of the object as a resource... the part where I am stuck is that if I have an object of type Foo accessible via /foo/{id}/ but it also has a relation to object type Bar as part of Foo -- I don't want to serialize Bar in the response. I want to return a URI to a Bar resource.
Am I on my own from here -- no frameworks handle that part? Especially with regard to the path. It feels like I'm going to have to create BarResource annotated with #Path but then also, during serialization, set the URI for the Bar POJO reference read from a constant. I'm not able to take a type and lookup a resource (and subsequently the #Path annotation) but that would be handy, no?
You are destined to remain confused until you clear up the distinction between resources, representations and objects.
A resource is a concept, or some "thing" that is useful to the client application. It is very nebulous. It is identified by a URI and is operated on using methods. It needs to be nebulous/flexible to make up for the very limited set of methods.
A representation is a set of bytes that can be transferred across the wire that represents the resource as some instant in time.
An object is an implementation detail that may or may not have a direct correlation with a resource. The information contained within a resource may be implemented by a single object or an entire object graph. A resource's contents could be stored in a file, the result of a SQL query, a XSLT transformation, pretty much anything.
You may or many not use object serialization to create representations of resources. References between objects may relate to content within a single resource or links between resources. However, be very careful serializing domain objects into representations. That is sure to introduce a level of coupling between your client and server that you will live to regret.