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 7 years ago.
Improve this question
Does every type modeled in DDD have to be either an entity or a value object?
No, in DDD you can modelled the following types of objects:
Domain Event: A domain object that defines an event. Where a domain event is something that happened that domain experts care about.
Service: When an operation does not conceptually belong to any object. Following the natural contours of the problem, you can implement these operations in services.
Repository: methods for retrieving domain objects should delegate to a specialized Repository object such that alternative storage implementations may be easily interchanged.
Factory: methods for creating domain objects should delegate to a specialized Factory object such that alternative implementations may be easily interchanged.
Related
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 1 year ago.
Improve this question
Should the classes always have connectivity in UML? For example, in the following diagram, class Zugriff is not connected to any other classes. It that a valid or correct class diagram in UML?
Yes. You SHOULD but not MUST.
Class diagram is UML structure diagram which shows the structure of the designed system at the level of classes and interfaces, shows their features, constraints, and relationships - associations, generalizations, dependencies, etc.
(from https://www.uml-diagrams.org/class-diagrams-overview.html)
These classes and interfaces should have a type of relationship so that it makes sense to put them together. A typical relationship is a generic (weak) use.
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
In my case, I have a java package - domain with JPA entity classes.
One of these entities, say Employee, has an attribute - status. status will always be from the set {ACTIVE, INACTIVE}, hence I have defined an enum - Status.
I know this is a small thing, but I was thinking whether this enum (which has no table mapped in the RDBMS database), be kept in domain package itself, or should it be kept somewhere else so that domain contains only the actual domain classes.
Simple put it depends on your taste.
If this enum is only used for the purpose of defining the status of a single class - in your case Employee then I would put it in a subpackage of domain.
For example:
*.domain.enums (for all enums of that kind)
*.domain.model (for all entity classes)
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 am using Spring framework usually with the common simple form:
Controller <-> Service <-> Repository
And I usually have a common services that I put inside a CommonService class and make all other serivces extends class.
A developer told me that it is better to inject the CommonClass in each service instead of using inheritance.
My question, Is there one approch better than the other? Do JVM or performance affected by one more than the other?
Update
There is no direct relationship between CommonService and other Services, it is not has-a or is-a relationship, it's like a utility service.
It is the principle of favoring composition over inheritance. If you inherit from a certain class, both are tightly coupled which makes it harder to keep separate things separate.
Unless an there is an is-entity relationship between the two, it is better to model a uses-entity relationship, because this allows for easier changes later on.
Of course it depends on the use case and it is more of a design and architecture question than a performance aspect.
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
Today I had an interview for test automation in one of the MNC.
They asked me "why do we need to create an object?"
I explained about OOPs concepts with example of individual bank account holders. But he is not convinced. He just need a definition.
What could be a suitable answer for that question?
You require an object to represent state.
At the most simple definition, a class defines behaviour and an instance of a class (an object) represents state.
Of course there are other things like static contexts which can also maintain state, which you can mention also, but above is the clearest answer which I believe they were looking for.
It also always helps to give an example. You could talk about, for example, an Employee class. You would need an object to represent John and another to represent Jane.
I think that this question is kind of generic and does not give much value to an interview. But some generic question should have a generic answer, and here is mine:
We need to create objects in java so we can get instances that have a state inside our application. This allows us to have persistent encapsulated elements that contain any required information, and methods that operate with it.
Just plain basic OOP theory.
There are many reasons why we create a object apart from basic oops
1) To bring up persistent state data to transactional state to perform action (curd and other) and persist back to data storage.(EJB, POJO,etc )
2) Creating handler to serve service and send fluid data across wire like web-service.
3)Stuctural behavior in action.for example you designed a class for a workflow and to make in action state we create a object and serve the behavior example validation , authorization , etc class
All in all to make design time architecture to response based live system
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 9 years ago.
Improve this question
Should the conversion methods be stored in the DTO ? ( like in the tutorial for hibernate+gwt on gwtproject.com) Or should i make a a static class with converter methods? When i send a DTO over the wire using asynccallback then is the method code sent?
The idea of the DTO is to separate the model from the data transported on the wire. If you have the conversion methods in the DTO you couple these 2 together.
When would it be problematic? Let's say for example you have a jar that contains dto classes that both server and client use. In this case you can use the same jar in your build process for both sides. But if you couple the model to the DTO you'll have to add jars to your model classes in the client tier.
I recommend a decoupled class for converting. It can be either with static calls or instance-calls if you have specific data for different conversion (for example - different injected services).