Let say that we have the following entities and the enum of languages:
entity Resources{
title String required,
text Language,
audio Language
}
enum Language{
SPANISH, ENGLISH, FRENCH, GERMAN
}
And we would like that the audio is a dropdown list where you can choose only one, but the text could be a list where you can choose more than one.
How can you tell Jhypster-JDL that you want to use an array of Languages?
It only lets you choose one... should it be done in the code once it is created?
Thanks
PD: I thought about that, but the problem with creating a language entity and define audio as a one-to-one relationship while text would be a one-to-many relationship like this is that the name variable gets repeated and crashes:
entity Resource{
title String required
}
entity Language{
languages Languages
}
enum Languages{
SPANISH, ENGLISH, FRENCH, GERMAN
}
// RELATIONSHIPS:
relationship ManyToOne {
Language{resource(closedcaption)} to Resource
}
relationship OneToOne {
Resource{language} to Language{resource(video)}
}
// Set pagination options
paginate Resource with pagination
// Set service options to all except few
service all with serviceImpl
#ManyToOne
private Resource resource; <---
#OneToOne(mappedBy = "language")
#JsonIgnore
private Resource resource; <---
So, I might be making a mistake, but I would like to know if besides this solution, is there a way to have an array of something defined in JDL? Let's say an array of Strings?
Thanks again, you are really helpful!
You could define Language as an entity and define audio as a one-to-one relationship while text would be a one-to-many relationship.
Related
Regarding below excerpt, concerning cqrs and ddd, from Patterns, Principles, and Practices of Domain-Driven Design by Nick Tune, Scott Millett
Does it mean that domain model on command side can omit most of business attributes ?
How would it look like for eg Customer Entity?
Could Customer entity omit FirstName, Surname etc?
If so, where would these business attributes be? Only in read model in CustomerEntity?
Or maybe apart from CustomerEntity containing all business attributes there would also be CustomerAggregate wrapping CustomerEntity with 1:1 relation, and command object would operate on CustomerAggregate? (seems strange to me).
What does it mean "Customer entity desn't make sense"?
The text you pointed means that you do not have to model a reusable Entity for your whole system or even for your whole bounded context (Do not model reusable real life things). Doing this is a bad design.
You have to model an Aggregate that performs an action. You feed the Aggregate with only, and just only, the data needed to perform that action and the aggregate response, the changes the domain suffered, is what you have to persist.
Why Entities and V.O.'s then?
To model consistency, encapsulation and decoupling is the basic part but these are implementation details. For DDD what matters is that are different roles (or concepts).
When feeding the aggregate (constructor, function call parameters, etc) the aggregate has to know if it is working with entities and/or with V.O. to build its response.
If the domain action means a change in an attribute of a entity (something with unique identification in your whole system) the response of the aggregate (once all rules and invariants has been checked) should include the new attribute value and the identification of that entity that allows persist the changes.
So, by default, every aggregate has its own entity with the unique identification and the attributes needed for the aggregate action.
One aggregate could have a Customer entity with ID and its Name.
Another aggregate could have a Customer entity with ID and its Karma points.
So every aggregate has its own inner Customer entity to work with. When you feed an aggregate you pass Customer data (i.e. ID and name or ID and Karma points) and the aggregate treats that info as a entity (It is a matter of implementation details if there is a struct, class, etc internally to the aggregate to represent the entity).
One important thing: If you just need to deal with entities ID's then treat it as a V.O. (CustomerIdentityVO) because the ID is immutable and, probably, in that action you just need to write this CustomerIdentityVO in some field in persistence, not change any Customer attribute.
This is the standard vision. Once you start to identify common structures relevant to several aggregates or one aggregate that can perform several actions with the same data fed you start to refactoring, reusing, etc. It just a matter of good OOP design and SOLID principles.
Please, note that I am trying to be higly above of implementation details. I know that you almost always will have unwanted artifacts that depends of programing paradigm type, chosen programing language, etc. but this approach helps a lot avoiding the worse artifact you could have.
Recommended readings:
http://blog.sapiensworks.com/post/2016/07/29/DDD-Entities-Value-Objects-Explained
http://blog.sapiensworks.com/post/2016/07/14/DDD-Aggregate-Decoded-1
http://blog.sapiensworks.com/post/2016/07/14/DDD-Aggregate-Decoded-2
https://blog.sapiensworks.com/post/2016/07/14/DDD-Aggregate-Decoded-3
and
https://blog.sapiensworks.com/post/2016/08/19/DDD-Application-Services-Explained
for a complete puzzle vision.
If you are using Event Sourcing then it's true that you can model aggregates without adding attributes that they don't need for implementing the business logic.
Here's an example:
class Customer {
public Guid ID { get; private set; }
public Customer(Guid id, firstName, lastName, ...) {
ID = id;
this.AddEvent(new CustomerCreatedEvent(id, firstName, ....);
}
public void ChangeName(firstName, lastName) {
this.AddEvent(new CustomerRenamedEvent(this.ID, firstName, lastName),
}
}
Custom only has ID attribute because it needs it to add it to every event that it generates. FirstName and LastName are omitted as they are not needed even when ChangeName method is called. It only records an event that this happened. If your logic requires the FirstName then you can add it. You can omit any properties that you don't need.
Your Repository in this case will save only the events and won't care about the values of the attributes of the Customer.
On the Read side you will probably need these properties as you will display them to your users.
If your aggregates are not event sourced, then you probably will need more attributes on your aggregate to implement it's logic and they will be saved to the database.
Here's an example:
class Customer {
public Guid ID { get; private set; }
public string FirstName { get; private set; }
public string LastName { get; private set; }
public void ChangeName(firstName, lastName) {
FirstName = firstName;
LastName = lastName;
}
}
In this case your Repository will need these properties as it will generate a query to update the database with the new values.
Not sure what "Customer entity doesn't make sense" means.
Let's say I have an entity Book
I want Jhipster to generate a Books Entity something like
class Books{
List<Book> books;
}
And Generate corresponding rest controllers like
Books saveAllBooks(Books books)
Books updateAllBooks(Books books)
There's no need to create a Books entity if it contains only a list of Book entities, you could just add manually the list methods to generated REST controllerBookResource.java as you don't need any additional repository.
But if Books has other fields that you want to persist in database, you could generate 2 entities with one-to-many relationship. I wouldn't recommend using plural as it could probably conflict with other generated code.
entity Book{
title String required
}
entity BookBatch{
name String required
}
// RELATIONSHIPS:
relationship ManyToOne {
Book to BookBatch
}
I need to create my own entities using the JHipster using the command "yo jhipster:entity myEntity" that have many-to-one relationship with the User entity that comes by default in JHipster.
I have tried unsuccessfully to create in the wizard a relationship with the entity "user" and the field "login" but it is not working.
What is the good way to do this with JHipster? Or do I have to create the entity without JHipster tool (but I need the CRUD!).
Thanks,
Yann
Just an update - jhipster 2.5.0 was released a few days ago adding support for this. Created this answer since the formatting in comments make i pretty hard to read.
When creating a relation for your entity simply answer the questions like this
? Do you want to add a relationship to another entity? Yes
? What is the name of the other entity? user
? What is the name of the relationship? owner
? What is the type of the relationship? many-to-one
? When you display this relationship with AngularJS, which field from 'user' do you want to use? login
Possible values on how to display the relation could be: id, login, first_name, last_name, email
See https://jhipster.github.io/2015/03/01/jhipster-release-2.5.0.html for moreinformation
Just to add to the correct answer by #stoffer, if you're using the jdl it will look like:
relationship ManyToOne {
Owner{user(email)} to User{owner(name)}
}
at a good sample in an official document is say :
entity Blog {
name String required minlength(3),
handle String required minlength(2)
}
relationship ManyToOne {
Blog{user(login)} to User
}
jdl-samples/blog.jh
If you are using the 1.x version, this wasn't made to work, so basically you should do it by hand, without the generator (but it is definitely doable).
For the 2.x version, we have refactored the User object to have an ID field -> this should make this a lot easier, but as this is not released yet, we don't have a feedback at the moment.
I have come into this issue and solved it by using a simple one-to-one relationship first that will extend the user entity, because it is simple and manageable easily and can make the extended entity be the owner of the relationship, then you can create the many-to-one relationship with your entity, like this example:
entity MyEntity {
MyField Type
...
}
entity ApplicationUser {
additionalField Type
...
}
relationship OneToOne {
ApplicationUser{internalUser} to User
}
relationship ManyToOne {
MyEntity{appUser} to ApplicationUser{myEntities}
}
For more details and approach refer to this jHipster page.
Is there any way to get the name of a relationship given the from and to entities?
I have a fairly dynamic piece of code that needs to Associate or Disassociate entities. In order to call these functions, I need to know the name of the relationship. I am not sure how to determine the relationship name just given the two entities.
For example, my code might need to disassociate an account with a contact. How can I determine the relationship name of "account_primary_contact"?
In the interest of answering the question despite my not understanding why you would want to do this:
foreach (OneToManyRelationshipMetadata relationshipMetaData in primaryEntityMetadata.ManyToOneRelationships)
{
if (relationshipMetaData.ReferencingEntity == relatedEntity.LogicalName)
{
string relationshipName = relationshipMetaData.SchemaName;
//Do something with your relationship?
}
}
Where primaryEntityMetadata is of type EntityMetadata and ReferencingEntity is of type Entity. Then use similar logic for checking Many to One relationships.
I am using domain-driven design and I have a pretty clear picture of my domain model. It contains over 120 classes and it is quite stable. We will implement it in .NET 4 and C#. The thing is, we need the model to be multilingual; some of the attributes need to be stored in multiple languages. For example, the Person class has a Position property of type string which should store a value in English (e.g. "Librarian") and Spanish (e.g. "Bibliotecario"). The getter for this property should return the English or Spanish version depending on some language parameter.
And here begin my questions. I am not sure how to parameterize this. I have exlpored two major ways to do it:
Use property collections. Position would not be a string but rather a Dictionary<Language, string>, which would let clients retrieve the person's position by language.
Keep simple, scalar properties, but make them return (or set) the value for one language or another depending on a globally known "current language" setting. The client code would set the working language, and then all objects would set and get values in that language.
Option 1 avoids global state, but it messes up the interface of almost every class in my model. On the other hand, option 2 is less expressive, since you can't tell what language you're going to get without looking at the global setting. Also, it introduces a dependency into every class on the global setting.
Please note that I am not interested in database or ORM implementations; I am working at the domain model level only.
I have two specific questions then:
Which is the best option (1 or 2) to achieve my goal of a multilingual domain model?
Are there other options that I haven't considered, and which are they?
Thank you.
Edit. Some have suggested that this is a user interface related issue, and thus can be tackled through globalisation/localisation support in .NET. I disagree. UI localisation works only if you know the localised literals that must be shown to the user at compile time, but this is not our case. My question involves multilingual data that is unknown at compile time, because it will be provided as user data at run-time. This is not a UI-related issue.
Edit 2. Please bear in mind that the Person.Position is just a toy example to illustrate the question. It's not part of the real model. Don't try to criticise it or improve upon it; there is no point in doing that. Our business requirements involve a lot of attributes that cannot be encoded as enum types or similar, and must stay as free text. Hence the difficulty.
Given the following:
Some use case involve setting the values for an object in all the
supported languages; others involve looking at the values in one given
language.
I would suggest going for both options. That means that the Person and all classes that hold multilingual content should keep that content in their state and:
The Position property should set/get the person's position in the
current user's language.
There should be a corresponding property or method for all
language setting/getting.
There should be a method for setting (or even switching if needed)
the user language. I would create an abstract class (e.g.
BaseMultilingualEntity) with an abstract SetLanguage(Language
lang) method and a CurrentLanguage getter. You need to keep
track of all the objects that derive from BaseMultilingualEntity
in some sort of registry that would expose language setting.
EDIT WITH SOME CODE
public enum Language {
English,
German
}
// all multilingual entity classes should derive from this one; this is practically a partly implemented observer
public abstract class BaseMultilingualEntity
{
public Language CurrentLanguage { get; private set; }
public void SetCurrentLanguage(Language lang)
{
this.CurrentLanguage = lang;
}
}
// this is practically an observable and perhaps SRP is not fully respected here but you got the point i think
public class UserSettings
{
private List<BaseMultilingualEntity> _multilingualEntities;
public void SetCurrentLanguage(Language lang)
{
if (_multilingualEntities == null)
return;
foreach (BaseMultilingualEntity multiLingualEntity in _multilingualEntities)
multiLingualEntity.SetCurrentLanguage(lang);
}
public void TrackMultilingualEntity(BaseMultilingualEntity multiLingualEntity)
{
if (_multilingualEntities == null)
_multilingualEntities = new List<BaseMultilingualEntity>();
_multilingualEntities.Add(multiLingualEntity);
}
}
// the Person entity class is a multilingual entity; the intention is to keep the XXXX with the XXXXInAllLanguages property in sync
public class Person : BaseMultilingualEntity
{
public string Position
{
set
{
_PositionInAllLanguages[this.CurrentLanguage] = value;
}
get
{
return _PositionInAllLanguages[this.CurrentLanguage];
}
}
private Dictionary<Language, string> _PositionInAllLanguages;
public Dictionary<Language, string> PositionInAllLanguages {
get
{
return _PositionInAllLanguages;
}
set
{
_PositionInAllLanguages = value;
}
}
}
public class Program
{
public static void Main()
{
UserSettings us = new UserSettings();
us.SetCurrentLanguage(Language.English);
Person person1 = new Person();
us.TrackMultilingualEntity(person1);
// use case: set position in all languages
person1.PositionInAllLanguages = new Dictionary<Language, string> {
{ Language.English, "Software Developer" },
{ Language.German, "Software Entwikcler" }
};
// use case: display a person's position in the user language
Console.WriteLine(person1.Position);
// use case: switch language
us.SetCurrentLanguage(Language.German);
Console.WriteLine(person1.Position);
// use case: set position in the current user's language
person1.Position = "Software Entwickler";
// use case: display a person's position in all languages
foreach (Language lang in person1.PositionInAllLanguages.Keys)
Console.WriteLine(person1.PositionInAllLanguages[lang]);
Console.ReadKey();
}
}
A domain model is an abstraction - it models a specific part of the world, it captures the concepts of a domain.
The model exists so developers can communicate in code the way domain experts communicate - using the same names for the same concepts.
Now, a Spanish expert and an English expert may use different words for the same concept, but the concept itself would be the same (one hopes, though language can be ambiguous and people do not always understand the same concept in the same way, but I digress).
The code should pick one human language for these concepts and stick to it. There is absolutely no reason for the model to consist of different languages in order to represent a single concept.
Now, you may need to show users of the application data and meta data in their language, but the concept does not change.
In this regard, you second option is the thing you should be doing - with .NET, this is normally done by looking at the CurrentThread.CurrentCulture and/or CurrentThread.CurrentUICulture and by using satellite assemblies that will contain localized resources.
My question involves multilingual data
[...]
Please note that I am not interested in database or ORM
implementations;
I can see a bit of contradiction in these 2 statements. Whatever the final solution, you'll have multilingual-specific structures in your database anyway as well as a mechanism that queries them to do the translation, right ?
The thing is, unless your domain really is about translation, I would try to keep it away from multilingual concerns as much as possible, for the same reason that you would try to make your domain persistence ignorant or UI ignorant.
Thus I would at the very least place the multilingual resolution logic in the Infrastructure layer. You could then for instance use aspects to only attach multilingual behavior to some properties, if you really need a trace of multi-language in your entities and don't want your persistence layer to handle all that transparently :
public class Person
{
[Multilingual]
public string Position { get; set; }
}
It contains over 120 classes and it is quite stable.
Not directly related to question, but you might want to consider the existence of multiple bounded contexts in your domain.
I agree with Oded that it seems in your scenario, language is a UI concern. Sure, the domain may be declared via combination of C# and English, what it represents is abstract. The UI would handle language with CultureInfo.CurrentCulture - effectively option #2.
A Person entity having a Position property doesn't govern the natural language used to represent the position. You may have a use case where you'd want to display a position in one language while it is originally stored in another. In this case, you can have a translator as part of the UI. This is similar to representing money as a pair of an amount and currency and then converting between currencies.
EDIT
The getter for this property should return the English or Spanish
version depending on some language parameter.
What determines this language parameter? What is responsible for ensuring that, say Position, is stored in multiple languages? Or is translation to be performed on the fly? Who is the client of the property? If the client determines the language parameter, why can't the client perform the translation without involving the domain? Are there any behaviors associated with multiple languages or is this only a concern for reading purposes? The point of DDD is to distill your core behavioral domain and shifts aspects related to querying data into other areas of responsibility. For example, you can use the read-model pattern to access the Position property of an aggregate with a specific language.
Make the User explicit!
I already encountered domains where the user's culture is a first class citizen in the domain but, in such situations, I model a proper value object (in your example I would use a Position class properly implementing IEquatable<Position>) and the User that is able to express such values.
Sticking to your example, something like:
public sealed class VATIN : IEquatable<VATIN> { // implementation here... }
public sealed class Position : IEquatable<Position> { // implementation here... }
public sealed class Person
{
// a few constructors here...
// a Person's identifier from the domain expert, since it's an entity
public VATIN Identifier { get { // implementation here } }
// some more properties if you need them...
public Position CurrentPosition { get { // implementation here } }
// some commands
public void PromoteTo(Position newPosition) { // implementation here }
}
public sealed class User
{
// <summary>Express the position provided according to the culture of the user.</summary>
// <param name="position">Position to express.</param>
// <exception cref="ArgumentNullException"><paramref name="position"/> is null.</exception>
// <exception cref="UnknownPositionException"><paramref name="position"/> is unknown.</exception>
public string Express(Position position) { // implementation here }
// <summary>Returns the <see cref="Position"/> expressed from the user.</summary>
// <param name="positionName">Name of the position in the culture of the user.</param>
// <exception cref="ArgumentNullException"><paramref name="positionName"/> is null or empty.</exception>
// <exception cref="UnknownPositionNameException"><paramref name="positionName"/> is unknown.</exception>
public Position ParsePosition(string positionName) { // implementation here }
}
And don't forget documentation and properly designed exceptions!
WARNING
There are at least two huge design smells in the sample model that you provided:
a public setter (the Position property)
a System.String holding business value
A public setter means either that your entity exposes its own state to clients regardless of its own invariants, or that such a property has no business value for the entity and thus should not be part of the entity at all. Indeed, mutable entities should always separate commands (that can change the state) and queries (that cannot).
A System.String with business semantic always smells of a domain concept left implicit, typically a value-object with equality operations (that implements IEquatable, I mean).
Be aware that a reusable domain model is quite challenging to obtain, since it requires more than two domain experts and a strong experience in ddd modeling. The worst "domain model" that I faced in my carreer was designed by a senior programmer with huge OOP skills but no previous modeling experience: it was a mix of GoF patterns and data structures that, in the hope to be really flexible, proved to be useless. After 200k €, spent in that effort, we had to throw it away and restart from scratch.
May be that you just need a good data model directly mapped to a set of simple data structures in C#: you'll never have any ROI from an upfront investment in a domain model, if you don't really need it!
It might be worth mentioning Apache's MultiViews feature and the way it delivers different content based on the browser's Accept-Language header.
So if a user requests 'content.xml', for example, Apache will deliver content.en.xml or content.sp.xl or content.fr.xml or whatever is available based on some prioritization rules.
Given the requirements I would probably try to model the position as an entity/value on its own. This object would not be a dictionary of translations but rather just be usable as a key into a domainDictionary.
// IDomainDictionary would be resolved based on CurrentThread.CurrentUICulture
var domainDict = container.Resolve<IDomainDictionary<Position>>();
var position = person.Position;
Debug.Writeline(domainDict.NameFor(position, pluralForm: 1));
Now assuming you need to dynamically create new positions when a suitable synonym doesn't exist you could probably keep the data somewhat tidy by using the IDomainDictionary as an source for auto complete suggestions in the UI.