Having a monolithic business application with complex business logic implemented in Visual Dataflex, we are facing the challenge of maintaining our business logic across programming languages as certain features are written in other programming languages (mainly .NET).
So I am looking for strategies to "synchronize" business logic across different programming language implementations, in order to avoid mismatches. Avoiding duplication is a plus, but this may be compensated by automated testing.
EDIT: SOA is a great suggestion. But what about those cases where a service will not be fast enough?
EDIT 2: Any suggestions for using a metalanguage?
Looks like you're looking for Service Oriented Architecture (SOA). With SOA, you can define your business logic as Services, which can be called from any program, in any language. When the business logic changes, change your Service and the behavior will change in everything that uses it. SOA also minimizes code duplication, because the logic only appears in one place (the service).
Related
If I need to write a simple webapi which need to get/create/update/delete of the products. Is this really need a business layer.
I am using Entity Framework which I understand this is similar to Repository Pattern.
If my webapi application is very simple which not much complex business logic e.g. bank reconciliation etc
Do i really need to have a business logic layer? Can i just have a service layer which create products / remove the products etc..
No, it is not necessary at all to have a business layer! (with a disclaimer)
Let me support my argument and address your concern
One of the most basic design principles of software engineering is KISS. If you feel the business problem you are solving is pretty simple then why to make code complex by introducing unnecessary layers.
Not having the 'business layer' is not a crime. It is well supported by the community as well that's why in one of the community and industry loved framework Spring there is a module called spring-data-rest exactly supporting design you are proposing (simple code with business layer and on top without explicit web layer)
The last argument evolutionary approach. With the increasing complexity of system and technology community released that system and code complexity should be evolved (thought process every well explained here). Don't try to think about future today (again referring to another basic design principle YAGNI). (Explaining disclaimer here) So start from simple and if in future you felt the need of having separate business logic layer because you got to write some actual business solving code then introduce that layer and evolve it!
I just finished reading Uncle Bob's "Clean Architecture" and now wondering how to apply it in the context of microservices!
On one hand, I think that microservices fall in the "Framework-Drivers" layer since it's an implementation on top of use-cases (they are ways to serve use-cases.) This way, we focus on the core of the app (Entities and Use-cases) and stay flexible in the implementation of the outer layers (including microservices). But since each microservice can be maintained by a different developer/team of developers, they will have a bad time when use-cases change (harder to predict who will be impacted).
On the other hand, we can split our app into multiple microservices, decoupled from each other, and apply Clean Architecture inside each microservice. The pro of this approach is that we can focus on each microservice doing one thing, and doing it well. But the problem is that we started designing using technical separations (microservices) which violates the main Clean Architecture principle of focusing on the business. Also, it will be hard to not duplicate code if two microservices uses the same entity or use-case!
I think the first scenario is the best, but I would like to have feedback from fellow developers on the long-term benefits of both scenarios, and potential troubles.
My two cents:
From Uncle Bob's words, "Micro-services are deployment option, not an architecture". Each micro-service should be deployable, maintainable by different teams (which can be in different geographical locations). Each team can choose their own architecture, programming language, tools, frameworks etc... And forcing each team to use single/same programming language or tool or architecture does not sound good. So each micro-service team must be able to pick their architecture.
How can each team code/maintain/deploy their own micro-service without conflicting with other teams code? This question brings us to how to separate micro-services. IMHO it should be separated on feature based (same principle applies to modularization of mobile application projects where independent teams should be able to work on separate modules/micro-services).
After separating micro-services, the communication between them is implementation detail. It can be done through web-socket/REST API etc... Inside each micro-service, if team decides to follow Clean Architecture, they can have multiple layers based on Clean Arch Principles (Domain/Core - Interface Adapters - Presentation/API & Data & Infrastructure). There can/will be duplicate codes on micro-services, which are OK for micro-services.
As #lww-pai-long said in his answer here splitting based on the Domain responsibilities and DDD is in most cases the best solution.
Still if you worked with a system using micro-services you soon realize that there are other things involved here as well.
DDD Bounded Context as base for micro-services
In most cases splitting your application to micro-services based on Bounded Context is the safe way to go here. From experience I would even say that in some parts of Domain you could go even further and have multiple micro-services per Bounded Context. Example would be if you have quite big part of Domain which represents one Bounded Context. Other example would be if you use CQRS for a particular Domain. Then you can end up having a Write/Domain and Views/Read micro-service.
You can read in this answer how you can split your Domain to micro-services.
It would be advisable as you said to "apply Clean Architecture inside each microservice".
Also, it will be hard to not duplicate code if two microservices uses
the same entity or use-case!
This is something that you have to deal with when working with micro-services in most cases. Duplicating code and/or data across multiple micro-service is common drawback of working with micro-services. You have to take this into account as you on the other hand get isolation and independence of the micro-service and its database. This problem can be partly solved by using shared libraries as some sort of packages. Be careful this is not the best approach for all cases. Here you can read about using common code and libraries across micro-services. Unfortunately not all advice's and principles from Uncle Bob's "Clean Architecture" can be applied when using micro-services.
Non Domain or technical operation micro-services
Usually if your solution is using micro-services you will more or less have micro-services which are not Domain specific but rather some kind of technical task's or non business operations directly. Example could be something like:
micro-service for report generation
micro-service for email generation and forwarding
micro-service for authorization/permission management
micro-service for secret management
micro-service for notification management
These are not services which you will get by splitting your solution based on DDD principles but you still need them as general solution as they could be consumed by multiple other services.
Conclusion
When working with micro-services you will most of the time have a mixture of Domain specific and Domain agnostic micro-services. I think the Clean Architecture could be looked from a little different prospective when working with micro-services.
On one hand, I think that microservices fall in the
"Framework-Drivers" layer since it's an implementation on top of
use-cases (they are ways to serve use-cases.)
It kind of does but it also falls into the other layers like Entities and Use Cases. I think it goes in the direction that if you work on Domain specific services this Diagram becomes the Architecture of each micro-service but not a concept above all micro-services. In the applications where I worked with micro-services each micro-service(the ones which are based on the DDD Bounded Context) had most of this layers if not all of them. The Domain agnostic services are an exception to this as they are not based on Domain Entities but rather on some tasks or operations like 'Create an Email', 'Create a PDF report from html template' or similar'.
I think this question may be better on Sofware Engineering but I'll answer anyway.
My approach would be to use DDD and define each microservice as a Domain Services grouping Use Cases semantically, then link Domain Services with Bounded Context.
Sam newman talk about the importance of separating microservice by domain abraction and not technical one in Building Microservices
The point he makes basically is that defining scaling strategies for microservice based on subdomain will better match the "real live" constraints observed on the production system than using technically based microservice and try to defined a abstract strategy.
And if you look at how something like Kubernetes works it seems to push to that direction. A pod end up being a microservice with multiple containers defined as a complete stack matching a sub-domain if the overhaul application.
It then gets easier in an e-commerce application, for example, to scale the Payment service independently of the Cart service based on customer activity than to scale the web services independently of the job queues in an abstract way.
The way those Bounded Contexts will communicate, i.e request based or event based, depends on the the specific relation between them. To use the same example a Cart may generate an event that will trigger the Payment, while the same Cart may need to request the Inventory before validating the order.
And at the end of a day those Domain Services* and Bounded Contexts can be implemented the same when starting with a monolith, even the Bounded Contexts communication can be. The underlying communication protocol becomes an implementation detail that can easily(kinda) be switch when transitioning to a distributed a.k.a microservices architecture.
I have a question about microservice implementation. right now I am using an api gateway to process all get request to my individual services and using kafka to handle asynchronous post put and delete request. Is this a good way of handling of handling request in a microservice architecture?
Your question is too unspecific to give a good answer. What is a good architecture totally depends on the details of your use cases. Are you serving web pages, streaming media, amass data for analysis, or something completely different? We would also need to know what are you requirements in terms of concurrency, consistency and scalability? What are the constraints for budget/size of development teams, ease of development, dev skills, etc?
For example the decisions you have taken may be considered good if you have strong requirements for a highly scalable input of large data sets and very frequent data collection as well as the team to support it. But it may be considered bad if you have a small team only and are trying to get a quick and cheap MVP for a new service that has limited scalability requirements (because the complexity of the solution slows down your development unnecessarily).
It may be good because the development team is familiar with those technologies and can effectively develop with those. Or it may be bad because your team does not know anything about those and the investment in learning those will not be justifiable by long term gains.
Don't forget that one of the ideas of the microservices architectural style is that each service can be owned by a distinct team that makes its own decisions about what technology to use for implementation (for whatever reason: ease of development, business reasons etc). So in other words the microservices style embraces the old wisdom architecture follows organization.
Here a link to a recommended further read.
I am sorry for my question may looking a old repetitive questions but I as I am starting Linq to SQL I want to discuss how many layers (architecture) should I use ?
I am working on web mostly web sites and small to medium scale web applications. I understand dividing application into layers help its maintainanace and enhancement but frankly I want some balance way which give me rapid development and code reuse-ability as well. I cannot spare so much time on unwanted management of layers.
Before I was using 4 layers (business objects, BLL,DAL and user itnerface.) I became confuse on it as different people have described different layers. Please guide me what and how many layers I should use ? Thanks
Don't use the layer architecture. Use the onion architecture.
The most important aspect from architecture perspective is the separation of concerns. Separation of concerns leads to clean code, easy maintenance, extensible, etc. That said, I recommend to base your decisions based on the following criteria:
Try to architect your system in a loosely coupled way. Use messaging instead of RPC as messaging is reliable, scalable, asychronous, loosely coupled, etc. You can either use MSMQ or NServiceBus (for service bus based architecture).
Create layers based on the separation of concerns concept. For e.g. you can go for typical 3 layered architecture which will have just UI layer, business logic layer (business rules+workflow) and data access layer or more granular such as UI layer, services layer (facade), business logic layer, data access layer, etc. Using IoC / Dependency injection will make life easy as none of the layers will have direct dependency. Moreover, it promotes unit testing easy as you inject mocks instead of the real implementations for the unit test. There are so many IoC frameworks available (NInject, Autofac, Castle Windsor, Structure Map, etc...)
Try to use EF instead of Linq to SQL as the later works only with SQL, while the EF works with any database. Moreover, in my opinion, EF is where microsoft is innovating and I would assume that Linq to SQL may be retired one day.
Great question haansi. This is something that I have wrestled with quite often when building small to medium sized sites. Finding that balance of creating a architecture that gives you the greatest flexibility and allows for rapid deployment is what I think we all need to strive for in all of our work.
With that being said, I have found that using the Repository Pattern to be quite helpful with LINQ to SQL projects. I couple that with the Model View Presenter pattern (for WebForms or other projects) and it provides a great foundation for reuse with minimal layers.
My Webform calls a Presenter class, which in turn is responsible for populating the View. To populate that View the Presenter can call N number of Repositories. The Repository is where you encapsulate your DataContext class and your LINQ to SQL calls. These calls return the model classes.
One huge benefit to this regardless of the size of the app is that get great re-use out of your Repository, you get to maximize the use of LINQ and you have used some patterns that other software developers could easily read and support.
Another big benefit is that you now have created a simple architecture that can benefit from using Unit Testing to test from the Presenter back to the Repository without a ton of effort.
Good luck!
I decided to use one layer (DAL + BLL) for small projects and for large applications will use Different layers for DAL & BLL. I will use Linq in DAL and funtiosn will return IQueryable.
I am trying to coach some guys on building web applications. They understand and use MVC, but I am interested in other common patterns that you use in building web apps.
So, what patterns have you found to fit nicely into a properly MVC app. Perhaps something for Asynchronous processes, scheduled tasks, dealing with email, etc. What do you wish you knew to look for, or avoid?
Not that it matters for this question, but we are using ASP.NET and Rails for most of our applications.
Once you get into MVC, it can be worthwhile to explore patterns beyond the "Gang of Four" book, and get into Martin Fowler's "Patterns of Enterprise Application Architecture."
The Registry pattern can be useful to make well-known objects available throughout the object hierarchy. Essentially a substitute for using global data.
Many MVC frameworks also employ the Front Controller and the Two-Step View patterns.
The "Model" in MVC is best designed as the Domain Model pattern, although some frameworks (led by Rails) conflate the Model with the ActiveRecord pattern. I often advise that the relationship between a Model and ActiveRecord should be HAS-A, instead of IS-A.
Also read about ModelViewController at the Portland Pattern Repository wiki. There is some good discussion about MVC, object-orientation, and other patterns that complement MVC, such as Observer.
This question is so open that it's hard to give a correct answer. I could tell you that Observer pattern is important in MVC (and for webapplication) and it would be a good answer.About all design pattern that exist are common in big web application. You will require to use some Factory to build complexe object and to access some section require some Facade.
If you want more "tips" or good practice instead of design pattern, I would suggest you to use IoC and the use of good Framework instead of starting from scratch. I can suggest you to explain the benefit of having a good ORM engine to drive you persistance layer faster too (usually can come from the Framework too).
Don't look at it from the aspect of what patterns to use with your development approach, but look at it more as how to apply patterns on a problem-by-problem basis. The architectural decisions made for the project provide just as much indication of what patterns to use as other people's experience will dictate.
That said, I have found that I am a fan of the Provider model for having multiple choices to accomplish a single task with ease of deployment added in. Also, the Unit of Work pattern is great for setting transactional boundaries. Largely, though, the architecture and business needs dictate the approach that is taken for any given code change or new development.
As much as I love patterns, I always fear seeing them overused. I have personally seen people that have used them just for the sake of using them, and it has actually made the code harder to maintain and more tightly coupled than it should have been. Also, it is good to know both sides of the patterns argument. A good pattern knowledge should be rounded out with (often considered a pattern, on its own) anti-pattern knowledge, as well.
I would most likely recommend some kind of Dependency Injection as well (Inversion of Control). Probably the single most important supplementary "pattern" to use.