What is the difference between an SOA service and other kinds of services like an application or domain service ?
Have a look here. http://www.bennadel.com/blog/2385-application-services-vs-infrastructure-services-vs-domain-services.htm
Short answer
DDD Domain Services operate on Domain Entities. Usually where the work that needs to be done spans multiple Aggregate roots.
DDD Application Services drives workflow. For example if you want to do some work on a domain entity, the Application Service would be responsible to fetch the entity from the data store, call the domain service to do the work, do some work via an integration service if needed, and then lastly persist the change.
This is an interesting question since SOA is such as broad and overloaded term.
If we take SOA to mean any implementation that results in a mechanism to reach 'services' then even application and domain services will form part of SOA services. Application and domain services will even fall within the realm of micro-services although application services are usually surfaced through some integration mechanism.
I like to think of these things in terms of 'reachability'. WikiPedia:
In graph theory, reachability refers to the ability to get from one vertex to another within a graph
So, it depends on how reachable your code is. A bunch of domain services could, theoretically, form a service-oriented architecture.
The only differences is in how you surface your services.
Related
I have 2 years in the IT industry,i love to read a lot ,but when i go deep in some subjects i see a lot of contradiction in somes articles,forum or terms that are used interchangeable.
I understand the difference between Soap and Rest.
When we want to communicate between backends, we can use either of these 2 approaches, each with its advantages and disadvantages.
Situation :
If i have an application, which can be monolithic or not, where I have a backend and I will only have a front end that consumes it. Usually we create a Rest Api so that our front end can consume it. But we will never think about exposing our backend with Soap.(Lot of reasons)
Questions:
1 -Is it okay if I say that Rest , in addition to allowing us to exchange information between application and application (backend to backend ), is it also useful when exposing services for our front end? And SOAP is only useful for Server - Server communication?
2 -And finally, if I expose a backend only for a front end, it is ok to say that we expose a web service or conceptually we say that it is a backend for frontend ?
Question 1: No the First question is wrong Assumption. We can say that in SOAP, XML is the only means of communication, while in Rest, the accepted means is JSON, while there are other formats like XML, JSON, PDF, HTML etc. and Ofcourse, XML can be converted back from server into UI Language and XML Request deciphered at Server for a Response. So, its not Ok to say that SOAP is only for Server - Server Communication.
2. No, when you have typically exposed backend only for consumption by a Front end, you can typically say that it is a backend for numerous front end client requests. But IMO, Backend for a front end is a monolithic webapplication, both bundled in WAR. so in that sense, any UI Request can request response from the Back end web service. Hope i am able to clear your understanding about web services.
I see that in your question there are actually 4 embedded independent topics. And probably because they are always used in conjunction it is sometimes tough to understand.
I will give a short answer first:
REST and SOAP both can be used for Client-Server and Server-Server integrations. But the choice will be dependent on the questions like where you want server-side UI technology/client-side UI technology or is it a single page application/portal technology, etc.
If you expose a single-backend for a single-frontend it's technically a BFF although the term BFF is used only in the case where you have separate-backends for each type of frontend application. e.g. one for mobile, one for web, one for IoT devices, etc.
The long answer is to clarify the 4 principles. Let me give a try at this by separating the topics into the below four headings:
1. Backend(Business Layer) vs Backend for frontend(BFF)
In classical 3-tier architecture (UI-Business Layer-Database) world, the middle-layer that consists of the business and integration logic is mostly referred to as backend/business layer.
This layer can be separated from the UI/Frontend using multiple different options like APIs(REST/SOAP), RPC, Servlet Technology, etc. The limitation with this 3-tier architecture is that, it is still tightly coupled to the type of users and use-cases are limited to web/browser based. It is not a good choice when you want to reuse the business-layer for both web and mobile as the mobile applications are required to be light-weight by principle.
That's where we lean on to multi-tier architecture with Backend For Frontend(BFF) as a savior. It's just a methodology to segregate the business-layers based on consumers.
2. Monolith vs SOA vs Microservices(Optimized SOA)
In a monolith world all the code components mostly UI and Business Layer sits in a tightly coupled fashion. The simplest example would be a Java Servlet Pages(JSP) application with Java as Business Layer. These are typically server-side UI technologies.
In Service Oriented Architecture(SOA), the usecases revolve around leveraging reusable business layer functions aka services. Here one would have to deal with UI-Server, Inter-Service and Server-Server integration scenarios. It's heavily service dependent, meaning it's like a spider-web of dependent applications.
The Microservices is an extension of SOA, but the approach is to keep a resource in focus instead of services to reduce the spider-web dependencies. Hence, self-sufficient and standalone service-clusters are the base of micro-services architecture.
3. SOAP vs REST Webservices
SOAP stands for Simple Object Access Protocol, typically used by the business-layer to provide user-defined methods/services to manipulate an object. For example look at the names of the services for accessing a book collection
To get a book getABook()
Get the whole list of books listAllBooks()
Find a book by name searchABook(String name)
Update a book's details updateABookDetails()
On the other hand, REST is representational state transfer which transfers the state of a web-resource to the client using underlying existing HTTP methods. So the above services for accessing a book collection would look like
To get a book /book(HTTP GET)
Get the whole list of books /books(HTTP GET)
Find a book by name /book?name={search}(HTTP GET)
Update a book's details /book/{bookId}(HTTP PATCH/PUT)
4. How to make a correct choice of architecture?
Spot the diversity of the application user groups and usages: This will help to understand the platform(web/mobile/IoT/etc), nature of the application and session-management.
Determine the estimated/required throughput: This will help you to understand the scalability requirements.
How frequently and who will be maintaining the application: This will help to gauge the application and technology complexity, deployment cycles, deployment strategy, appetite for downtime, etc.
In conclusion, always follow the divine rule of KISS: Keep it simple, stupid.
1.)
A webapplication is for H2M communication a webservice is for M2M communication through the web. The interface of the service is more standardized, more structured, so machines can easily use it and parse the messages.
I don't think it matters where your service consumer is, it can run in a browser or it can run on the server. As long as it can communicate with the service on a relative safe channel it is ok.
You design a service usually to decouple it from multiple different consumers, so you don't have to deal with the consumer implementations. This makes sense usually when you have potentially unknown consumers programmed usually by 3rd party programmers you don't even know or want to know about. You version the service or at least the messages to stay compatible with old consumers.
If you have only a single consumer developed by you, then it might be too much extra effort to maintain a service with a quasi-standard interface. You can easily change the code of the consumer when you change the interface of the service, so thinking about interface design, standardization, backward compatibility, etc. does not make much sense. Though you can still use REST or SOAP ad hoc without much design. In this case having a RESTish CRUD API without hypermedia is a better choice I think.
2.)
I think both are good, I would say backend in your scenario.
I am developing a bookstore application based on microservices architecture with Spring and Netflix OSS.
I made a shopping service, with all the stuff necessary to buy a book. But I need to integrate with two services.
One service is a shipping service, this is an internal service. Connected through a Feign client.
The other service is an inventory service, this is an external service. Connected through an external library. This is a problem because it's more difficult to mock.
In order to connect with this services from shopping service, I thought that the adapter pattern was a good idea. I made another service, a shopping adapter service, that is used to connect with the other two services. And with this architecture, I can test the shopping service mocking the adapter service.
But now I think that is a bit awkward solution.
Do you know which is the best architecture to connect with external or internal services?
First, is it correct that’s what I understand?
Compound Service --(use)--> shipping service
----------------------------(use)--> inventory service ( this project uses external
library )
If it is right, I think it is not difficult to mock.
Create an inventory microservice project for wrapping external library.
Because compound service doesn`t need to care what we need to use a certain library for inventory. Your Inventory microservice project just exposes endpoint for using inventory service.
In the microservices world, services are first class citizens. Microservices expose service endpoints as APIs and abstract all their realization details. The internal implementation logic, architecture, and technologies, including programming language, database, quality of services mechanisms, and more, are completely hidden behind the service API.
Then, You can mock Inventory service at your compound service test code.
#Configuration
class MessageHandlerTestConfiguration {
#Bean
public InventoryClient inventoryClient() {
return Mockito.mock(InventoryClient.class);
}
I don't think creating another microservice which you should maintain and monitor and keep resilient and high available etc. just to have a kind of facade or adapter is a good idea. This statement may be proved wrong for some very special cases but generally if you don't have a context to maintain then it is not a good idea to create a new microservice.
What I could recommend would be directly calling shipping service by paying attention to anti corruption layer pattern which keeps your actual domain's service code clean from other microservice's domain entities.
You can find some more information about anti corruption layer here https://softwareengineering.stackexchange.com/questions/184464/what-is-an-anti-corruption-layer-and-how-is-it-used
I am learning about microservices and I don't understand what the real difference
between creating a REST API and creating microservices?
I’m working in Go, but my question applies over all languages.
The Microservices approach is about breaking your system ("pile of code") into many small services, each typically has its own:
Clear business-related responsibility
Running process
Database
Code version control (e.g. git) repository
API (the protocol how other services / clients will contact the Microservice)
UI
The services themselves are kept small so as your system grow, there are more services - rather than larger services.
Microservices can use REST, RPC, or any other method to communicate with one another, so REST or an API is really orthogonal to the topic of microservices...
Reference: What is an API? In English, please.
API = Application Programming Interface
Microservices = an architecture
In short
Microservice should expose a well-defined API.
Microservice is the way you may want to architect your solution
API is what your consumers see.
You can expose API without microservices in the backend (in fact, most non-training scenarios don't require microservices).
You may want to read http://samnewman.io/books/building_microservices/ before you decide on using microservices (unless this is for training purposes).
Microservice is well defined when you are following SOC - seperation of Concern on the entity/domain level ,where each entity / domain are independent of any other service.
for example user service will only be responsible for storing, updating and deleting user related informations.
Microservice backend and frontend microservice can further be splitted in 2 parts
frontend microservice which exposes rest endpoint just like Web API
backend microservice which actually perform all the operations.
Rest API is more of endpoints exposed to outer world and can be used with microservices as well, as explained above.
The majority of the answers is based on the old-school understanding of API as a programmatic interface. Nowadays, this meaning is melted and start confusing people becuase some developers started (for simplicit or by mistake) interpred the API of an application as the application per se. In such case, it is impossible to distinguish between the modern API and Microservices. Nonetheless, we can say that an API-application can comprise many Microservices, the most of which interact within the application via Microservice's APIs while others may expose their APIs as Applications's APIs. Also, a Microservice (as a service) may not include other Microservices (services), but may orchestrate a composition of Microservices via API-bases invocations. Applications may contain Microservices but, in the best practices, may not contain other Applications.
Microservices
A microservice architecture is about slicing an application logic into small pieces or "components" that can act between them and/or be exposed through an API.
API
A (web) application need to design the business logic with all set of object entities (model) and possible operations on them.
An (Application Programming Interface][https://en.wikipedia.org/wiki/Application_programming_interface) is a way of making the requests to an application by exposing specific entry-points that are in charge of invoking the appropriate application operations.
ReST(ful) APIs
("ReST" as in Representational State Transfer) are APIs complying with at least these 5 constraints:
User-interface is distinct from data storage and manipulation (Client-Server architecture)
No client context is stored on the server ("stateless")
Server responses must, implicitly or explicitly, define themselves as cacheable or not
Client does not have to be aware of the layers between him and the server
Response/request messages must be: be self-descriptive; allow to identify a resource; use representations allowing to manipulate the resources; announce available actions and resources ("Uniform interface").
"The real difference"
So, while these notions are obviously related, they are clearly distinct concepts:
Being ReSTful or not, an API exposes operations provided by a server that might (but not necessarily) be shelled into smaller components (microservices).
Also, while a typical web (ReST)API uses the HTTP protocol between the client and the server, components within a microservice architecture might communicate using other protocol(s) (e.g. WAMP, AMQP, JSON-RPC, XML-RPC, SOAP, ...)
In layman's term, if you have a web API server and you split them into several independent mini servers, use a proxy-server and load-balancer to clusterize them, and (optionally, give each a separate database entity), that is a microservice architecture.
There is a system with a rather big amount of different small services.
The idea is to hide them behind one, which is going to be an entry point to the system.
Is that considered a good practice?
Are there any common approaches/solutions for such case in asp.net core?
This is called an API Gateway pattern.
API gateway is the single entry point for all clients. The API gateway handles requests in one of two ways. Some requests are simply proxied/routed to the appropriate service. It handles other requests by fanning out to multiple services.
As the starting point, you may look into Proxy Middleware for ASP.NET Core.
We have started our projects with DDD design principles, I heard that any business logic needs two or more domain objects interaction should be written as domain services.
My question is:
Since my business logic includes saving of more than one domain or access many domain objects for validation purpose, can I pass repository inside the service method or can I access using DIContainer.
In case of operation A I will build List<Specification> (Specification classes which contain validation) and pass on to domain services from application layer. So my domain service validates and does business logic.
Can domain service use CRUD operation in itself.
I am really confused where to draw a line between application service and domain service.
Can I get any good samples which has application services, domain services, domain specifications with repositories involved.
Answer is here: http://gorodinski.com/blog/2012/04/14/services-in-domain-driven-design-ddd/
Actually these rules apply:
1) domain entities do the job
2) if in some function more entities are involved, changed - a domain service may be the solution
3) no, domain layer should not know anything about: transaction, saving, locking, etc. neither should load entities... if you need something like that use INeedSomeStuffFromRepo. Interface is defined in the domain layer, implementation is inside app. services. This way you could also doi locking, f.e. IExecuteThisFncToLockBeforeManipulatingWithAnObject
4) saving, transaction is in the app service side. i use persistence by reachability, so even if i have an aggregate, entity with other entities related, it's enough to save the parent...
Domain service actually is the Pure fabrication in GRASP. everything does not fit in an entity or a value object.