I read a book by OOP. And it uses domain term frequently but I can't get clearly what is it in OOP. Is it a namespace?
I found a description for the domain model but I don't sure that is same.
Can a someone explain, pls?
P.S. Book explains OOP paradigmas so it doesn't relate to the Internet terms.
Link to the book
Suppose you have an ice cream van. Your domain named entity will contain your ice cream interface and different kinds of ice cream classes.
And suppose you're keeping track of sold ice cream with help of your notebook. That will be your DB domain. In OOP languages like Java you'll have something like dao domain or repository domain, depending on what kind of design pattern you prefer most.
At last, you have yourself, kind of connecting ice cream with your customers. The interface if Ice cream guy and particularly your implementation will lie in something like connector domain.
UPD. Well, you should think towards domain driven design. You put all models, entities in one package and call it model, you can have multiple different interfaces/abstractions and their implementations there, it's not about having a single one, and that's your model domain. You create service package in your root folder and create an operating class to your models - that's your service domain. You create an action domain to operate with methods of services created previously - and that's your new action domain.
Related
This is what understand about an API, and this what I tell myself.
Forget about first two terms, just focus on interface. What an interface? It's an medium to connect two or more things which wants to communicate. You using your phone, TouchPad is that interface. For client and server architecture Urls or endpoints are an interface.
So, I have been forgetting the two terms. Some days ago I explained that to someone How I take them, but that someone asked-
What is the meaning of the two terms if they are there to be ignored?
You have all kinds of interfaces in computing. A fairly common one is a network interface. In your case, it's a programming interface for the application. An interface between your application and another entity.
What the writer is trying to convey to you is that this is an interface and that's the most important thing to think of.
I haven't found anything concrete on the topic from the gurus, except
There are other ways to implement an Anticorruption Layer, such as by
means of a Repository (12). However, since Repositories are typically used
to persist and reconstitute Aggregates, creating Value Objects by that means
seems misplaced. If our goal is to produce an Aggregate from an Anticorrup-
tion Layer, a Repository may be a more natural source.
from Vernon Vaughn.
What my concern is that mostly ORMs/queries are used as examples of Repositories in the DDD literature. My project is very scarce in domain logic cause it's mainly a wrapper on a couple of APIs and combines the outcome of those Contexts. The responsibilities of the project are broad and could fit many areas/contexts of the business as a whole. The only architectural rule forced from the beginning is the onion architecture and at least the DDD technical modeling concepts seem fitting for me. I must say it's hard to reason about the domain in this particular ongoing project.
Does an external service (API) fit the DDD definition of a Repository?
Maybe?
REPOSITORIES address the middle and end of the [domain object's] life cycle, providing the means of finding and retrieving persistent objects while encapsulating the immense infrastructure involved.
Repository is a pattern, motivated by the notion of separation of concerns -- you shouldn't have to fuss with the details of persistence when you are working on the domain logic.
DDD is about the domain only. Details of how your app persists entities are not of its concern. That's the reason why you define the interface (in the case of .NET) of your repository in your domain, but the actual implementation is part of the infrastructure of your code.
Repositories are nothing but a pattern for you to do "CRUD" operations on an entity without the concerns of how is done. Remember that your client class (the one using the repository) can only see the exposed public methods. Whatever happens inside, it's a mystery :)
DDD says, give me an interface for me to operate. How you do it, that's your problem. You can effectively persist your entities using an external API (think of Twitter API), a text file, ORM (direct connection to a database). DDD doesn't care.
take a modern JavaScript website as an example. You'll have plenty of REST calls to create/find/update/delete your domain objects.
In the case of a server application, you'll have a database and a DAO implementation as a client interface to your database. In your web application, you'll also have some REST-client functionality as client interface to your server application. Both are considered repositories, no matter if the implemenentation of the client interface access data in your database / your server / your file sytem etc.
I'm currently part of a project in which we host a WCF service to be accessed by certain clients. The WCF solution is split up into 4 different C# projects:
Host.csproj
DataContracts.csproj
Infrastructure.csproj
Model.csproj
Upon joining this project, I immediately wondered why there was a separate project for "DataContract" objects and one for "Model" objects. The two projects basically contain duplicates of the same objects. For example, in the DataContract project, there is a Customer object with 4 properties, and the model project also has a Customer object with the same four properties... I noticed that there is A LOT of automapper (mapping) being used in the application code to map datacontact objects to model objects and then re-map model objects back to data-contract objects while flowing through our typical service-repository pattern. The number of mappings necessary to produce results in this service has become extremely annoying.
After asking some teammates about why this route was chosen, I was told that datacontracts should not contain domain logic and that they are strictly objects to be used to send over the wire (and that all domain logic should be done using the model version of the object).
I feel like this approach is a bit unnecessary. Couldn't we just do away with the datacontracts project and use our model objects for both domain logic on the service side and also as datacontracts?
Somebody enlighten me...
Couldn't we just do away with the datacontracts project and use our
model objects for both domain logic on the service side and also as
datacontracts?
Yes it's physically possible for you to expose your domain objects out of your service, and it might save you a mapping or two.
However let's imagine in the future the domain model changes in response to business needs.
The existing consumers are happy with their contracts and don't want to have to change every time you release, so you are limited to a small non-breaking subset of possible changes you can make, or you have to wait until they're ready to release before you can.
One day another business consumer comes along who wants to leverage your domain capabilities. But they don't want the same contract as your existing consumers. How can you offer them what they want without breaking your existing consumers?
Another development team want to use your domain models in-process so you ship them an assembly, but their deployment server is .net 2.0 so it falls over trying to load System.Runtime.Serialization.dll
More generally, how can you evolve your domain capability when you're hard-wired to your external dependents?
If you think none of these situations apply to you and your service will always and forever be a simple facade on a repository for some ancient and unchanging business function then go for it.
Or,
The mappings you find irritating are there to protect you from inevitable change. As a consumer of a service, being coupled to that service's release schedule is a nightmare, and the same is true both ways. The mappings free you to be able to evolve your domain's business capability as you want to without having to worry about breaking anything. Want to rename a field? Do it. Tired of that massive single class? Refactor it into sub-types. The world is your oyster.
If you're worried about efficiency or performance, an in-process type mapping is several orders of magnitude faster than an out-of-process service call, as to be almost negligible.
So I'm going to have to say the advice your colleagues gave you:
datacontracts should not contain domain logic and that they are
strictly objects to be used to send over the wire
sounds pretty smart to me. Lots more here.
If you're finding the mappings tedious, I have used Omu ValueInjector before and it takes alot of the hassle out.
I am working on a project using DDD, I have some classes and I don't know where to put them.
The domain is about an existing game. This game has basic concepts, like Character, SkillTree. My domain class simply represent those concepts. I did not make this game.
My application/project is about having a software that represents those concepts, with some added values. At the moment, a name, and a description are the only possible added values (example, "Fire mage", and "Mana dependant, be careful !").
Question 1 : does it make sense to have two classes, or should I merge them ? In the former case, where should I put this class "with added value (name and description)" ? In the application layer ?
Question 2 : Am I right in saying that the domain layer represents the sphere of knowledge I am working on, and application layer represents all the things that do not exist in the domain, but I want to provide, as added value ?
(therefore, if my software simply represents the domain, the application layer is thin, and if my software provide a lot of non domain functionalities, the application layer is thick ?)
Additonal informations 1 : my project is about creating a character simulator. Therefore, in order to simulate a character, I have to represent it, as well as all of its dependencies. My domain layer responsability is to represent the game. It contains classes like Character, with some properties (Life, Mana, Attack, Defense, Class), and some enum (like CharacterClass, which lists all the available classes).
Now, I want my own project to provide, to the user, the ability to create a project, that represent a character of the game. The project also allows the user to save additional informations, like a name for the current project, a main (and secondaries) equipment set, a main (and secondaries) skilltree. Annotations are also available for any of the equipment set and skill trees, so the user can simply have a built-in memo/post-it. Secondaries equipment set and skill tree, annotations are not existing concepts in the game (and therefore, do not exist in my domain).
In question 1, the "class with added value" is a character project, that is an aggregate of multiple informations (character equipments, skill tree, annotations, etc). It can be saved on a physical support, opened and edited again later, if the user wants it.
Reformulation of question 1 : I have a Character class, and a CharacterProject class. The CharacterProject class is a composition of multiple informations. But it is specific to my application. Does it make sense to put it in the application layer, or the domain layer, or somewhere else ?
For you first question, I want to comment and help you with some humble design guidance. Humble meaning believe it at your own risk :D.
While designing classes for any layer or any type of software I usually approach it with generalization love (abstraction/interface contracting etc), You mentioned you have name and description which are 'values' that are going to be added to your domain models core object such as 'SkillTree' or 'Character', Ask yourself if you can generalize name and description classes as for example IAdditiveInformation interface. If most of what these two classes will do can be shared/contracted under IAdditiveInfromation generalization then you know that this is also in your domain core. If you use this interface in core of your domain model and point all dependencies towards this interface you wont have to answer hard and speculative design questions such as
Will I be adding more 'value' classes?
Will there be more 'GamePart' classes?
How can I design my 'value' and 'GamePart' classes so that I can implement their interaction with minimum effort.
For deciding classes to put at Domain model, Domain service or Application Layer and beyond. I use these as guidelines.
If a class is directly related to what your software is on like in a way that a account software is related to invoices, inseparable and crippled without it, then that class is in your domain model layer and at the core of the onion.
If a class operate on objects at your core and only on your domain core and they are reusable whenever you use a domain core like the current core. Then they are your domain services.
If a class operates on your domain services and/or your domain core and it feels a little bit more specialized for that application. Then it probably belongs into application layer. For something to be in application layer remember that this functionality should be critical for that particular application on domain and not for whole the domain. So you only need this functionality for that application.
Let me give you an example to make it a little easier to understand.
Imagine a gps based tracking system.
At it's core there is a class called GPSTrackable (an abstract class hopefully).
At the domain service level there is a class which operates/depends on GPSTrackable which is a geo location based query control where you give a GPS box and it returns you GPS trackables in that box. Lets call this class GPSTrackableQuery
Time to see magic of onion/DDD and correct OOD :). I have not told you what the application is and I have not even decided on the application yet. I don't have decide to capture core domain and domain services because they should be application independent(in an idealized architecture way).
Now with these at our onion core,
I can make a class in application layer, that calls to GPSTrackableQuery every 10 seconds and checks if there are any object in close proximity to a military base for a security system and you get a location based security system if you run that core at everyone’s phone.
I can make a class in application layer, that calls to GPSTrackableQuery when user wants to send mass SMS or e-mails to people near his store. Now I made a advertisement system from the same domain core.
You can add new examples to this. This is a simple thing, I imagine when I doubt my decisions.
One last note: You should also understand that placement of classes in layers have no meaning. We just put them in 'virtual' layers to have a feeling of their responsibilities and functional scope. If in too much doubt just put it somewhere, when you architecture or design or implementation evolves you will feel it's correct placement.
For your second question.
In my opinion, your suggestion is correct. Only thing I can comment is I would not use the term sphere of knowledge for the domain layer(I assume you mean both domain core and domain services). I view domain core as a representation of real world knowledge in computer terms or core idea's behind it.
As i grow in my professional career i consider naming conventions very important. I noticed that people throw around controller, LibraryController, service, LibraryService, and provider, LibraryProvider and use them somewhat interchangeable. Is there any specific reasoning to use one vs the other?
If there are websites that have more concrete definitions that would be great.
In Java Spring, Spring Boot and also .NET you would have:
Repository: persist data in the database and perform SQL queries.
Service: contain most of the business logic
Controller: define REST endpoints, which contains as little logic as possible.
Conceptually this means that the WHAT (functional) is separated from the HOW (technical) as much as possible. The services try to stay technologically neutral. By contrast a controller only wants to define an external contract for communication. And finally the repository only wants to facilitate the access to the database.
Organizing your code in this way keeps the business logic short, clean and maintainable. Unfortunately it is not always easy to keep them separated. e.g. It is tempting to pollute or enrich your objects with meta-data in the form of decorators/annotations. (e.g. database column name and data type).
Some developers don't see harm in this and get away with it. Others keep their objects strictly separated and define multiple sets of objects.
The objects for the database are often referred to as "entities" or "models".
For a REST controller they are often referred to as DTOs which stands for data-transfer-object.
Having multiple objects means that you need Mappers to convert one type of object to another. Some frameworks can do this for you (e.g. MapStruct).
It would be easy to claim that strictness is always a good thing, but it can slow you down. It's okay to strike a balance.
In Node.js, the concepts of controllers and services are identical. However the term Repository isn't used very often. Instead, they would call that a Provider or sometimes they would just generalize Repositories as a kind of Service.
NestJS has stronger opinions about this (which can be a good thing). The naming conventions of NestJS (a Node.js framework) are strongly influenced by the naming conventions of Angular, which is of course a totally different kind of framework (front-end).
(For completeness, in Angular, a Provider is actually just something that can be injected as a dependency. Most providers are Services, but not necessarily. (It could be a Guard or even a Module. A Module would be more like a set of tools/driver or a connector.)
PS: Anyway, the usage of the term Module is a bit confusing because there also are "ES6 modules", which is a totally different thing.)
ES6 and more modern version of javascript (including typescript) are extremely powerful when it comes to (de)constructing objects. And that makes mappers unnecessary.
Having said that, most Node.js and Angular developers prefer to use typescript these days, which has more features than java or C# when it comes to defining types.
So, all these frameworks are influencing each other. And they pretty much all agree on what a Controller and a Service is. It's mostly the Repository and Provider words that have different meanings. It really is just a matter of conventions. If your framework has a convention, then stick to that. If there isn't one, then pick one yourself.
These terms can be synonymous with each other depending on context, which is why each framework or language creator is free to explicitly declare them as they see fit... think function/method/procedure or process/service, all pretty much the same thing but slight differences in different contexts.
Just going off formal English definitions:
Provider: a person or thing that provides something.
i.e. the provider does a service by controlling some process.
Service: the action of helping or doing work for someone.
i.e. the service is provided by controlling some work process.
Controller: a person or thing that directs or regulates something.
i.e. the controller directs something to provide a service.
These definitions are just listed to the explain how the developer looks at common English meanings when defining the terminology of a framework or language; it's not always one for one and the similarity in terminology actually provides the developer with a means of naming things that are very very similar but still are slightly different.
So for example, lets take AngularJS. Here the developers decided to use the term Controller to imply "HTML Controller", a Service to imply something like a "Quasi Class" since they are instantiated with the New keyword and a Provider is really a super-set of Service and Factory which is also similar. You could really program any application using any of them and really wouldn't lose anything much; though one might be a little better than another in certain context, I don't personally believe its worth the extra confusion... essentially they are all providers. The Angular people could have just defined factory, provider and service as a single term "provider" and then passed in modifiers for things like "static" and "void" like most languages and the exact same functionality could have been provided; this would have been my preference, however I've learned not to fight the conventions and terminology of the frameworks your working no matter how strongly you disagree.
Looking myself too for a more meaningful name than Provider :)
And found this useful post
Old dev here that stumbled on this. My opinion and how I’ve seen it used over the last 20 years shows that it varies by language but the Java C# crowd mostly uses them as follows.
A service handles business logic and deals with domain objects. You find services in controllers and other services.
A repository does NOT handle business logic, but instead acts like a pool of domain objects (with helper methods for finding or persisting them. Services often contain repositories. Repositories often contain a context and are responsible for mapping from infrastructure shaped data to domain shaped data if the definitions have drifted apart. Controllers also often contain repositories for crud endpoints.
A context handles infrastructure the domain owns. Most often this is a database, but context means that anything that touches this data does so through (in) this context. A context returns infrastructure shaped data. A repository often contains a context. Context directly in services is sometimes appropriate. Context in controller is a hard no.
A provider provides access to infrastructure some other app owns. Most often these are rest apis, but can also be kafka streams or rpc classes that read data from or push data to someone else. If the source of truth for some of your domain objects fields changes you will probably see a provider next to a context in your repository, and your repository handles insulating the rest of your code from that change. Providers that provide rpc functionality are often found in services. In micro services or gateways or vertical slice architecture you sometimes see providers directly in controllers.
One old guy’s opinion but I hope it helps.