I am at beginner stage of OOP. Got an academic project, need to make a UML Class Diagram of C# Code.
I am developing a project which will use database, I am confused about 1 thing. In UML we use inheritance like department and student, we create 2 classes and put department ID in student class.
Coming to my confusion, I will make some classes like department, student and teacher, and also a database with same tables. How can I use classes, because I know that on user request I can process data on database (on runtime), Like adding teacher or student to department, getting all students, etc. I am supposed to get all data from database when program loads? and save data in variables and put it in database when required? Simplifying my confusion, How to use classes when we use database to get data dynamically?
What you are talking about is a transition, which is not inheritance. At least not really. Once you have developed a class model you will think about persistence. The persistence can be designed in many ways (in most cases you will derive just one persistence scheme, though). Now what you do is to "copy" your classes from your design model to a new package for the persistence. Thereby <<trace>> from the persistence back to the design class. Now you almost independently optimize your persistence towards your desired schema. You will introduce primary and foreign keys, redundancy and things like that. Anyhow, your persistence model only remembers where it came from (via the <<trace>>) but it now has a living on his own.
Note that some UML tools offer automated transition from design models to various derivates.
Related
While i am practicing DDD in my software projects, i have always faced the question of "Why should i implement my business rules in the entities? aren't they supposed to be pure data models?"
Note that, from my understanding of DDD, domain models could be consist of persistent models as well as value objects.
I have come up with a solution in which i separate my persistent models from my domain models. On the other hand we have data transfer objects (DTO), so we have 3 layers of data mapping. Database to persistence model, persistence model to domain models and domain models to DTOs. In my opinion, my solution is not an efficient one as too much hard effort must be put into it.
Therefore is there any better practice to achieve this goal?
Disclaimer: this answer is a little larger that the question but it is needed to understand the problem; also is 100% based on my experience.
What you are feeling is normal, I had the same feeling some time ago. This is because of a combination of architecture, programming language and used framework. You should try to choose the above tools as such that they give the code that is easiest to change. If you have to change 3 classes for each field added to an entity then this would be nightmare in a large project (i.e. 50+ entity types).
The problem is that you have multiple DTOs per entity/concept.
The heaviest architecture that I used was the Classic layered architecture; the strict version was the hardest (in the strict version a layer may access only the layer that is just before it; i.e. the User interface may access only the Application). It involved a lot of DTOs and translations as the data moved from the Infrastructure to the UI. The testing was also hard as I had to use a lot of mocking.
Then I inverted the dependency, the Domain will not depend on the Infrastructure. For this I defined interfaces in the Domain layer that were implemented in the Infrastructure. But I still needed to use mocking for them. Also, the Aggregates were not pure and they had side effects (because they called the Infrastructure, even it was abstracted by interfaces).
Then I moved the Domain to the very bottom. This made my Aggregates pure. I no longer needed to use mocking. But I still needed DTOs (returned by the Application layer to the UI and those used by the ORM).
Then I made the first leap: CQRS. This splits the models in two: the write model and the read model. The important thing is that you don't need to use DTOs for models anymore. The Aggregate (the write model) can be serialized as it is or converted to JSON and stored in almost any database. Vaughn Vernon has a blog post about this.
But the nicest are the Read models. You can create a read model for each use case. Being a model used only for read/query, it can be as simple/dump as possible. The read entities contain only query related behavior. With the right persistence they can be persisted as they are. For example, if you use MongoDB (or any document database), with a simple reflection based serializer you can have a very thin architecture. Thanks to the domain events, you won't need to use JOINS, you can have full data denormalization (the read entities include all the data they need).
The second leap is Event sourcing. With this you don't need a flat persistence for the Aggregates. They are rehydrated from the Event store each time they handle a command.
You still have DTOs (commands, events, read models) but there is only one DTO per entity/concept.
Regarding the elimination of DTOs used by the Presentation: you can use something like GraphSQL.
All the above can be made worse by the programming language and framework. Strong typed programming languages force you to create a type for each custom returned value. Some frameworks force you to return a custom serializable type in order to return them to REST over HTTP requests (in this way you could have self-described REST endpoints using reflection). In PHP you can simply use arrays with string keys as value to be returned by a REST controller.
P.S.
By DTO I mean a class with data and no behavior.
I'm not saying that we all should use CQRS, just that you should know that it exists.
Why should i implement my business rules in the entities? aren't they supposed to be pure data models?
Your persistence entities should be pure data models. Your domain entities describe behaviors. They aren't the same thing; it is a common pattern to have a bit of logic with in the repository to change one to the other.
The cleanest way I know of to manage things is to treat the persistent entity as a value object to be managed by the domain entity, and to use something like a data mapper for transitions between domain and persistence.
On the other hand we have data transfer objects (DTO), so we have 3 layers of data mapping. Database to persistence model, persistence model to domain models and domain models to DTOs. In my opinion, my solution is not an efficient one as too much hard effort must be put into it.
cqrs offers some simplification here, based on the idea that if you are implementing a query, you don't really need the "domain model" because you aren't actually going to change the supporting data. In which case, you can take the "domain model" out of the loop altogether.
DDD and data are very different things. The aggregate's data (an outcome) will be persisted somehow depending on what you're using. Personally I think in domain events so the resulting Domain Event is the DTO (technically it is) that can be stored directly in an Event Store (if you're using Event Sourcing) or act as a data source for your persistence model.
A domain model represents relevant domain behaviour with the domain state being the 'result'. An entity is concept which has an id, compared to a Value Object which represents a business semantic value only. An entity usually groups related value objects and consistency rules. Not all business rules are here , some of them make sense as a service.
Now, there is the case of a CRUD domain or CRUD modelling where basically all you have is some data structures plus some validation rules. No need to complicate your life here if the modeling is correct. Implement things as simple as possible.
Always think of DDD as a methodology to gather requirements and to structure information. Implementation as in code (design) is something different.
In many case, I need write a lot of class work with CRUD for some class. For example CRUD with pure object User, Book, Tag.
I usually make a directory named models, put all the CRUD classed into the models folder.
But I feel that the word model is not show essence. Is the word model well-defined in computer science? It means the pure object of User, or the means of CRUD of User?
I also use another name services for more complex logic, For example UserService may require other models than UserModel. But the word service is often conflict with some other case like an online service, backend service.
Are there any good names for the model and service in my case? BTW, I am most using Node.js; it may not conflict with the general conventions used in Node.js.
Ultimately, it will come down to what makes the code the most understandable both to you and to someone down the road who may have occasion to work on your code. If 'model' and 'services' convey the thought of what lies within in an obvious way to anyone coming in to the code, then they are probably fine. As far as standards, I don't know if there is a 'defined' set of names you have to use. In MVC, for example, you will use 'Models' as one of your folders in order to store all of the actual models you will be feeding your views, and this is understood in the MVC architecture that those names (Models, Views, Controllers) are the standard.
I agree with you that Model is a little ambiguous. Sometimes it is used to indicate domain objects such as User/Book/Tag, but sometimes it is used to indicate objects that deal with business logic, such as "Buying a book","Authenticating a user".
What's common to both uses is that "Model" is clearly separated from UI, that is handled entirely by the Views and the Controllers.
Another useful name is Entities. In Robert Martin's work on Object Oriented Design, he speaks of use-case-driven design, and distinguishes between three kinds of objects: Entity Objects, Interactor objects and Boundary objects.
Entity objects are useful in multiple use-cases. For example, in a book selling system, entities can be Book/User/Recommendation/Review.
Interactor objects implement use-cases, and they typically use multiple entity objects. For example, Purchase_Book/Login/Search_Books can be such objects.
Boundary objects are used for transferring data across module boundaries, and are used for building interfaces between parts of the system, which should be decoupled from one-another. For example, a controller may need to create a Purchase_Book object, and in order to create it, it needs to pass data about what book ID needs to be purchased, by what user ID, etc... and this data can be packed in a boundary object called Purchase_Request.
While Interactor and Boundary require more explanation, I find that the word Entities is meaningful and can be grasped intuitively without reading any explanation.
I have homework and I'm supposed to draw a class diagram AND data model. I wrote the class diagram. I don't know what to do about the data model. What are the differences?
According to texts on the Internet they seems to me, ie: class diagrams and data models are the same thing.
What is the difference between class diagrams and data models.
Unified Modelling Language, as you may already know, is a means of describing systems with diagrams. They don't just relate to software, but can also relate to hardware, economics, everyday items, in fact anything, although they are more generally used with software systems.
A class diagram details how you have split your system into discrete objects, how those objects relate to each other and any know interfaces that they may have. Each class in a class diagram can hold both data and function.
For example a Car class has an Engine, a Steering Wheel class and multiple Wheel, Door, Seat and Pedal classes linked to it. In all of this a class diagram is static.
I'm not exactly sure what you mean by data model.
I've seen class diagrams used to model database tables, usually these are without any functional element and just show how the data tables relate to each other.
There are those that argue that there needs to be an addition to the UML standard for Data Diagrams, but as yet none have been ratified.
This is because persistence of data, key relationships and constraints between tables can be difficult to model with a standard class diagram and most UML tools implement tweaks to the standard in order to allow this.
Then there are dataflow diagrams which are really Activity diagrams, used to show the flow of data between processes within a system.
Now if we go back to class diagrams and assume that a data diagram is used to model a database then you'll notice that there a few differences that may be overlooked.
A class on a class diagram can have data properties (code variables etc) and functional properties (methods, procedures, functions etc.) but these elements of a class can also have access properties (private, public etc.). A class diagram can also show inheritence e.g. a Volkswagon is a Car, so is a Ford, both will inherit from Car and this can be shown.
A data diagram in the database sense will show data items (columns/fields in database tables) but the idea of access properties (public, private etc.) or the idea of inheritence has no meaning and thus can't be shown.
This is because it isn't modelling discrete objects that have both data and function but the data associated with those objects. For example a Car table may have a relational link to a Manufacturers table in which is stored the values Volkswagon and Ford. It may have a Wheels column, but this will only show the number of wheels. Stored procedures for the database exist at a level labstracted from the data - they utilise the data, but are not governed or owned by the data tables that they get the data from.
I've probably not explained myself very well, but I hope that I've helped.
Here's a useful site
And here's another and on that site data modelling specifically.
Generally data models define how the database is implemented. Those diagrams are entity diagrams. A class model is the functional relationships between objects in your system. A class has data but it isn't the data model. A design has both a class model and a data model. As a simple example, a data model exists for a customer. That data model was the design for our customer database. A class model design exists to implement how to process a customer order. The data model is what the database designer uses. The class model is what the software designer uses to implement a ordering business function. Both the data model and class model have diagrams. They use different symbols and rules. Class diagram vs Entity diagram. Two different kinds of diagrams.
Datamodeling is not UML which is focused on object approach.
Having said that you can model inside a class diagram at object level and create your database using Hibernate annotations in the Java code.
I mean that you create your code and add persistence annotation at the same time. This would create your database at deployment.
UML which is not supposed to be datamodeling can also create data at deployment level if you use the Omondo Persistence profile. It means that you can model at object level and also create your database. Very powerful approach because the data creation stage is now joined with the object
This is still an initiative but it could become a standard if bigger companies adopt this approach which is for me one of the best practices when codding in Java that I would recommend.
What is the difference between a domain model and a data model?
A datamodel is a design model that only describes data and it's relations. The model contains entities, but they are described in terms of what data they own not how they act on this data or what their responsibilities are.
An domain model on the other hand, is a conceptual model used in analysis of a problem domain. It describes the domain in terms of entities that have relations, data and behaviour. It describes the responsibilities of those entities as relevant for understanding the problem domain.
BTW an excelent and very short introduction to UML is:
UML Distilled: A Brief Guide to the Standard Object Modeling Language
A data model is focused on the DB schema definition, including tables, columns, and relationships.
A domain model is focused on the business domain, including concepts (classes of objects), behavior (methods/logic), and relationships.
In both cases, the cardinality is used for relationships (e.g. 1:1, 1:Many, 0:Many, ...).
That said, you would ideally like the data model and domain model to be closely related, i.e. a Person with name, ... and a MailingAddress, ... relates to a PERSON table with a NAME column and a FK to a MAILING_ADDR table entry. You have to decide where logic is hosted - in the objects in the software system vs. in the DB via procedures, triggers, and such.
I think it's important to provide some clarity here for posterity.
A data model is a design for how to structure and represent information. By structure, I mean concerns like "fifth normal form". By representation, I mean choosing a computer serialization, such as integer, floating point, or string.
The term domain model actually has two conflated meanings.
A model of essential characteristics of real or imaginary things in the world. In this kind of model, classes represent human conceptualizations and instances are things in the world. For example, a "Person" class would have instances including you and me, and an essential characteristic might be that every Person has a mother. This kind of model is often called an conceptual ontology or concept model and is intended to provide meaning.
A model of required information about things in the world, usually with some system in mind. In this kind of model, classes represent information that must be stored about things in the world. For example, a "Person" class would have instances representing required information about you and me, such as first name, last name, date of birth, current height, and current weight. This information often does not include all essential characteristics, such as our mothers, because, for the purposes of a particular system, that information is not required. This kind of model is often called an information model, conceptual data model, or operational ontology.
Both the UML and OWL languages can be used to represent either kind of domain model. Both can be considered analysis models, as they are used to analyze a domain. One is used to understand things in a domain, the other is used to gather requirements to build a particular software or database system for things in a domain. Both are necessary, and, unfortunately, they are usually conflated such that people building an analysis model are themselves confused about what they are modeling!
I think that domain model and data model are now pretty much the same with new top down modelling technologies. I mean that you can model in a class diagram and only add database stereotypes in your diagram. If you use the tool that I use then your ejb3 annotation would be immediately synchronized with your code. The next step is only to use a mapper to create your database. This technology only works with Java
I am 80% sure I should not be asking this question because it might come across as negative and I mean no disrespect to anyone, especially the author of this book. I have seen several posts recommending this book and its companion project. I have not read the book, but I have spent a few hours today studying the project. And while it does look very complete, I am having a very hard time with how much the details of various things are scattered around. I am struggling in my own designs with how much I have to change if an entity changes, and this project does not make me very comfortable as a solution.
For example, there is a Employee object that inherits from a Person. Person has a constructor with first-name, last-name, etc. and therefore, so does Employee. Private to Employee are members for first name, last name, plus public properties for the same.
There is an EmployeeFactory that knows about both Employee and Person properties, as well as the SQL column names (to pull values from a reader).
There is an EmployeeRepository with unimplemented PersistNewItem and PersistUpdatedItem methods that I suspect, if implemented, would build SQL for INSERT and UPDATE statements like I see in CompanyRepository. These write the properties to strings to build the SQL.
There is a 'Data Contract' PersonContract with the same private members and public properties as Person, and an EmployeeContract that inherits from PersonContract like Employee does Person, with public properties mirroring the entities.
There is a static 'Converter' class with static methods that map entities to Contracts, including
EmployeeContract ToEmployeeContract(Employee employee)
which copies the fields from one to the other, including Person fields. There may be a companion method that goes the other way - not sure.
I think there are unit tests too.
In all I count 5-10 classes, methods, and constructors with detailed knowledge about entity properties. Perhaps they're auto-generated - not sure. If I needed to add a 'Salutation' or other property to Person, I would have to adjust all of these classes/methods? I'm sure I'd forget something.
Again, I mean no disrespect and this seems to be a very thorough, detailed example for the book. Is this how DDD is done?
Domain Driven Design is really simple. It says: make your Model classes mirror the real world. So if you have Employees, have an Employee class and make sure it contains the properties that give it its 'Employee-ness'.
The question you are asking is NOT about DDD, but rather about class architecture in general. I think you're correct to question some of the decisions about the classes you're looking at, but it's not related to DDD specifically. It's more related to OOP programming design patterns in general.
DDD s new enough (at least in some senses) that it may be a little early to say exactly "how it's done." The idea's been around for a fair long while, though, although we didn't make up a cool name for it.
In any case, the short answer (IMAO) is "yes, but...." The idea of doing a domain-driven design is to model the domain very explicitly. What you're looking at is a domain model, which is to say an object-oriented model that describes the problem domain in the problem domain's language. The idea is that a domain model, since it models the "real world", is relatively insensitive to change, and also tends to localize change. So, if for example your idea of what an Employee is changes, perhaps by adding a mailing address as well as a physical address, then those changes would be relatively localized.
Once you have that model, though, you have what I maintain are architectural decisions still to be made. For example, you have the unimplemented persistence layer, which might indeed be simply construction of SQL. It could also be a Hibernate layer, or use Python pickling, or even be something wild like a Google AppEngine distributed table structure.
The thing is, those decisions are made separately, and with other rationales, than the domain modeling decisions.
Something I've experimented with to some good result is doing the domain model in Python and then building a simulator with it instead of implementing the final system. That makes for something the customer can experiment with, and also potentially allows you to make quantitative estimates about the things the final implementation must determine.
to me, what makes DDD different from "mere" model-driven design is the notion of "aggregate roots", i.e. an application is only allowed to hold references to aggregate roots, and in general you will only have a repository for the aggregate root class, not the classes that the aggregate root uses
this cleans up the code considerably; the alternative is repositories for every model class, which is "merely" a layered design, not DDD