In the "clean architecture", the buissiness logic (entities) is in the core of the application and should not depend on anything.
But now I wonder, if a entity can have a dependency on another entity?
For example in a marketplace application:
The entity class Product would have following parameters:
class Product(
int id,
double price,
User owner
)
so the owner parameter would be another entity of type: User.
So would it violate the dependency rule?
The dependency rule is about the dependencies between the layers. It states than an inner layer must not depend on an outer layer. I.e. the dependency graph "arrows" must always point inward.
Therefore, one entity can depend on another.
Related
AHere's the setup:
Springboot, springboot-data-jpa, hibernate.
I have one entity, a Review, that has a property that has a many-to-one relationship with another entity, a vehicle. The vehicle entity conversely has a one-to-many relationship with the review entity.
To create the review entity via a POST endpoint, I give the vehicle entity as of the properties in the JSON.
This works fine, not only is the review record added in the database but it goes ahead and creates the vehicle entity as well. The only issue is that in the case where the vehicle already exists, instead of making that connection, it creates another record with the exact same information so I have a duplicate vehicle entity.
Is this because I should be handling the creation of the vehicle entity on my own instead of relying on hibernate? Am I just missing some annotation I'm not aware of?
Originally I was getting an error about flushing or something so I added the Cascade.ALL annotation to the review class 'vehicle' property and that fixed that problem. I tried changing the Cascade type as it seems to be relevant somehow but it either breaks the server or doesn't work at all.
Lets say I create a slot in Rasa called "yearlybill".
I will have to write:
slots:
yearlybill:
type: float
min_value: 0
So my question is, when I want to use these slot in my intents, will I have to explicitly mention it as an entity as well? Or is that option?
Let's start with a bit of background.
A slot should be seen as a long-term memory slot. You can store information in there manually, via a custom action, without having an entity around.
An entity is a substring of the user message that you'd like to extract for later use. Common entities are names, dates, and product-ids. It's very common to store the entity in a slot, but you don't have to. You can also detect an entity and have a custom action retrieve that information from the tracker.
You could define a slot without defining an entity. If you're planning to use a custom action to fetch the slot value from a users' text, you technically don't need an entity. This isn't a common pattern though. Typically you'd like a specific entity detection model to fetch the entity so that it can be stored in the slot after. That's why it's common to see domain.yml files that contain both a slot and an entity definition.
I was wondering if it is possible to combine DAO and Entity in a single class. e.g.
In rails
If I have table named user then there will be one ActiveRecord User and by using that class I can access access Methods related to DB and user i.e. it has both methods user.name (accessing object properties) and user.save / User.get_all methods (managing DB interactions) in the same class
In Spring/Hibernate Configuration
I have two things: DAO and Entity
Entity: I have User class that is an entity and is mapping Table as POJO, so that I can access methods related to a single user e.g. user.getName()
DAO: I have a DAO in which there are DB interactions e.g. userDAO.save(user) and userDAO.get(id).
Question:
I was wondering if I can create single User class and define User properties and getter/setter inside along with DB interactions so that I can single class as both, i.e. user.getName() (as POJO) and User.get(id)/user.save() (as DAO).
Is this method possible, and why are the complications I might run into, if I start with this approach?
it's called Active Record Pattern . Here is article about topic for JPA . Active Record Pattern . and example https://github.com/ActiveJpa/activejpa
Is this method possible, and why are the complications I might run into, if I start with this approach?
it's :
Cohesion & Coupling
if it's real project , it might become problem to support it
when you have 20 entities it's difficult to decide where to put method into what entity , and also find method that you need as it might be in many places
when you don't use active record pattern you can share entity with web layer , with active record entity can't be Serializable.
code become bigger and bigger
Suppose I have one aggregate, Ticket. A Ticket will have one assigned Department and one or more assigned Employee.
When instantiating a Ticket, should a TicketFactory be responsible for ensuring that a Ticket is created with a valid/existent Department and Employee?
Likewise, when decommissioning a Department or Employee, what is responsible for ensuring that a new Department or Employee is assigned to a Ticket so as to maintain its invariants? Could there be a service in the domain responsible for decommissioning, or is this a case where eventual consistency or some form of event listening should be adopted?
The TicketFactory would be declare that in order to create a Ticket you need references to both a Department and an Employee. It would not verify that those actually exist. It would be the responsibility of the calling code to obtain the appropriate references.
If using eventual consistency, the decommissioning of a Department and Employee would publish events indicating the decommission. There would be a handler associated with a Ticket which would subscribe to that event and either assign a new department and employee or send some sort of warning to task.
Take a look at Effective Aggregate Design for more on this.
I've recently started exploring DDD, so I have ran into some of the issues you mention.
I think that TicketFactory should always return validated/properly built Ticket instances. If you model is complex, you can have a domain service that validates that a given Department or Employee can be attached to it and then the factory uses it. Otherwise, you can just put it all in the factory. But what comes out of the factory should be a proper ticket.
I'd say that if e.g. only Ticket knows about the other two, a domain service that uses the Department and Employee repos would get the job done. If the relationship is bidirectional, then you can utilize event sourcing. Also, if it's really a event that should be captured in your domain model, and has other consequences other than reshuffling tickets, you can attach one of the handlers to this event to be InvalidTicketHandler. But if it's a small scale thing, keep it simple, just have a domain service that maintains the invariants.
Sidenote: If the Department and/or Employee are aggregates themselves, then you can reference them within Ticket via their identifier (e.g. employee's company ID or ID-code of the department). In that way you'll achieve consistency easier as you will not cross consistency boundaries between different aggregates.
A FACTORY is responsible for ensuring that all invariants are met for the object or AGGREGATE it creates; yet you should always think twice before removing the rules applying to an object outside that object. The FACTORY can delegate invariant checking to the product, and this is often best. [Domain-Driven Design: Tackling Complexity at the Heart of Software]
A depends on question type, but from the look of it it seems like a great candidate for an application layer functionality, i wouldn't go for the event solution though cause i find it only suitable in between layers and not between objects in the same layer.
I am attempting to refactor my application from a repository per entity to a repository per aggregate root.
A basic example would be I have an entity root of Cars. Cars have hire contracts. As far as I can see contracts don't exist without cars hence cars is the aggregate root.
I am trying to implement a user view which will shows every contract in the system(all the child entities of the root entities). Before refactoring I could just go to my contracts repository and get All. As contracts repository has been removed (as its not a root) I now need to get all cars out of my repository and then get all their contracts.
My repository has the interface
public interface ICarRepository
{
IQueryable<Car> All { get; }
IQueryable<Car> AllIncluding(params Expression<Func<Car, object>>[] includeProperties);
Car Find(long id);
void InsertOrUpdate(Car car);
void Delete(long id);
void Save();
}
I thought of creating an ICarManagementService and having it have a GetAllContracts method (perhaps with filter parameters). Would that mean to get all contracts I need to pull all car entities out with their contracts and then retrieve each entities associated hire contracts and filter them?
I can then pass these to the controller and AutoMap the contracts as before.
Is this best practice?
Thanks
Graeme
As far as I can see contracts don't exist without cars hence cars is
the aggregate root.
This is not necessarily true. 'Don't exist without' is not enough for an entity to become a part of an Aggregate Root. Consider classic order processing domain. You have an Order that is an Aggregate Root. You also have a Customer that is an Aggregate Root. Order can not exist without a Customer but it does not mean that Orders are part of the Customer Aggregate. In DDD entities inside one Aggregate can have references to other Aggregate Roots. From DDD book:
Objects within the AGGREGATE can hold references to other AGGREGATE
roots.
Aggregate is a life cycle and data exchange unit. It is essentially a cluster of objects that enforces invariants. This is something you want to be locked if you have multiple users changing domain at the same time.
Back to your question, my understanding is that the domain is something like rent / lease a car / truck / limo / bulldozer. I think that HireContract may not be a part of Car aggregate because they may have different lifecycles and HireContract just makes sense on its own, without a Car. It seem to be more of a Order-Product relationship that is also a classic example of two different Aggregates referencing each other. This theory is also confirmed by the fact that business needs to see "All Contracts". They probably don't think of Car containing all Contracts. If this is true than you need to keep your ContractsRepository.
On an unrelated note, you might be interested in reading this answer about repository interface design.
Separate the concept of read/query from the write/command, as guided by CQRS it is preferable to design the application by separating read model which consists of read only queries and the write model on the other hand which consists of commands to execute certain logic on the domain model.
thus querying all aggregate roots or creating custom queries to join sets of data is not a good candidate of domain repository, instead put these queries into read repository (or better named Finders).
if you find yourself wanting to query a collection of objects in order to execute some domain logic then it is an indicator that you have to abstract this collection and put it into an aggregate root to encapsulate them and make the business operation or method act on them.
check out (http://moh-abed.com/2011/09/13/pure-old-ddd-with-a-twist-from-cqrs/) and (http://simon-says-architecture.com/2011/08/23/repository)