I have done some investigation around SOA and Component Based Architecture, and it seems one of the key differences is that a service should be independently deployable.
If I have services that are jar files, and these jar files don't start living until they are deployed as part of a larger application's ear file - is this really SOA? I.e. these service are jar files that cannot be deployed as independent services that can run independently of the ear file.
A service is an independent unit in terms of deployment but also versioning, scaling and data. The API (whether it is HTTP, messaging, events etc.)is "published" and public which many times comes with implication on security, backward compatibility etc.
In any event,I don't think it matters what you call them or even if you have an SOA or not. The point is to get an architecture that will serve your current needs and will enable you to evolve it when future needs will arise
If your code is communicating in process them I think you are just using components. A real SOA would have code communicating via some other mechanism like http. Not saying one is better than the other it just depends on the problem you are solving.
Related
I understand the need for abstraction and separating concerns and unit tests, however, it seems to me that separating entities and context into 2 projects is slight overengineering?
I could be missing something really, but is this because you want to be open for different ORM-s?
Much thanks for the clarification.
The main reason I prefer to have Infrastructure in a separate project, rather than just a separate folder, from the domain model (Core project) is simple: enforcing my design via the compiler.
I have a design rule, which is basically the Dependency Inversion Principle. Don't depend on low level implementations (such as those found in Infrastructure), instead depend on abstractions (interfaces). Also, don't have your abstractions depend on details; have details depend on abstractions. The details of how and which infrastructure is being used for a given abstraction are in the Infrastructure service implementations.
Abstractions say what; implementations say how.
What: I need to send an email.
ISendEmail interface
How: I want to do it using the SMTP protcol
SmtpEmailSender class (implements ISendEmail)
How: I want to do it using a SendGrid API
SendGridEmailSender class (implements ISendEmail)
So, in a single project, how would you ensure that the implementations depend on the interfaces, and not vice versa?
How would you ensure your domain classes didn't directly reference or use Infrastructure types?
I'm not aware of a way to do this.
But if you put them in separate projects, and you have the implementation details project depend on the abstractions-and-models project, you now have solved the problem. The compiler WILL NOT ALLOW the Core project to reference anything in the Infrastructure project, because it would create a circular dependency.
This constraint helps developers do the right thing and keeps them falling into the pit of success even if they don't completely grok how the dependency inversion principle works or why it's important.
And I've never found 3 projects (Core/Infra/UI) to be overengineering for any non-demo app I've built for real work. It's only 3 projects.
I recently started a side-project. It was supposed to be a virtual recipe-book with the capabilities to store and retrieve recipes (CRUD), rate them and search through them. This is nothing new, but i wanted to build it as a desktop application to learn more about databases, unit testing, UIs and so on. Now that the core domain is pretty much done (i use a DDD approach) and i implemented most of the CRUD Repositories, i want to make this a bit more extensible by hosting the core functionality online, so i am able to write multiple backends (desktop application, web application, web api, etc).
Service Oriented Architecture (or Microservices) sound like a good approach to me to do that. The problem i am facing is how to decide, which parts of my project belong into a separate service and how to name them.
Take the following parts of the project:
Core domain (Aggregates, Entities, Value Objects, Logic) -> Java
Persistence (DAOs, Repositories, multiple Database backend implementations) -> Java
Search (Search Services which use SQL queries on the persistence DB for searching) -> Java
Desktop Application -> JS (Electron) or JavaFX
Web Application -> Flask or Rails
Web API (Manage, Rate, Search for recipes using REST) -> ?
My initial approach would be to put the core domain, the persistence, the search and the web api into a single sub-project and host that whole stack on Heroku or something similar. That way my clients could consume the web interface. The Desktop and Web apps would be different projects on their own. The Dektop app could share the core domain if they are both written in Java.
Is this a valid approach, or should i split the first service into smaller parts? How do you name these services?
Eric Evans on GOTO 2015 conference ( https://youtu.be/yPvef9R3k-M) and I 100% agree with him, answered to your question. Microservice scope should be one or maybe more Bounded Context(s). Including its supporting classes for persistence, REST/HTTP API, etc.
As I understood, the microservice is deployment wrapper over Bounded Context, with adding the isolation, scaling and resilient aspects.
As you wrote, you didn't apply Strategic Design to define bounded context. So its time to check, before tearing the app to parts.
can any one explain java callout a little help will do.Actually i am having several doubts regarding where to add the expressions and message flow jar and where to add my custom jar.
Can i access the resources/java folder directly and can i use it to store my data?
First, check the docs on apigee at
Customize an API using Java
http://apigee.com/docs/api-services/content/customize-api-using-java
Keep in mind Java Callouts are only supported in the paid, Apigee Edge product, not the free Developer platform.
As you decide how to use Java, you should consider this basic hierarchy of policy management:
Policy Configuration First: Apigee policy configurations are in broad use and therefore tested daily by clients and most performant.
Javascript Callout: For stuff you can't do in a standard policy there is Javascript -- keep in mind this is "Compiled Javascript" which means at the time you deploy your project the JS gets interpreted by the Java Rhino engine and then runs like native code. Very fast, very scalable, and very easy to manage as your code is all in plain text files.
Java: You have to have a pretty compelling reason to use Java. Most common cases are where you have some complex connection that needs to be negotiated with custom encryption schemas or manipulating binary content. While perfomant, it's the most difficult code to manage (you upload compiled jars, so if someone takes over your work, the source code is in a separate place than your deployment bundle), and it's the most difficult to debug in the event of a failure.
To your specific question: All Apigee variables are available in Java and Java gives you pretty much god-like powers on the local server where the code is executed. Keep in mind, Apigee's physical architecture is distributed -- your jar may run on different servers for different API calls, so any persistent data (that you might want to store locally) should really be put into Key Value Map and read as needed. Keep your API development as stateless as possible.
Hope that helps.
I'm new to Biztalk. I wish to structure my artifacts into applications.
Should I go with one application per artifact type - for example 3 seperate applications, like 'BusinessProcess.Schemas', 'BusinessProcess.Maps', 'BusinessProcess.Maps', with all the assemblies related to these (typically just one), or do you think it best to just have one 'BusinessProcess' application, which would contain all assemblies related to the business process?
Should I go with one application per artifact type
I think in general, you mean one project per artifact type? Although artifacts common to more than one application should be split out into a separate application / solution.
The rationale for splitting BizTalk projects up into component projects (and assemblies) is similar to any other .Net project - separation of concerns, isolation for testing purposes, independent versioning, etc.
Most of these are addressed in Erik Westermann's great answer here
One point that to elaborate on is that the dependency chain usually looks something like this:
Schemas (Internal / Canonical, External)
^
Maps
^
Ports + Pipelines
^
Orchestrations
(plus other miscellaneous .Net assemblies with helpers)
On a server with multiple applications deployed, at some point you'll likely need to have cross-application dependencies (especially if you have chosen to couple to definite schemas and not loosely couple e.g. via multipart messages), usually on Internal / Canonical Schemas which are common to more than one project.
Unless these schemas are separated from the other assemblies, any time a monolithic application changes, you'll need to go through the pain of uninstalling / reinstalling all dependent apps every time any change is made to the monolithic app. Generally because the whole enterprise is dependent on the Canonical schemas, they are carefully deliberated and thus fairly stable, whereas an app's maps and orchestrations are more likely candidates for frequent change.
Here's a structure for this scenario:
Separate Common / Base Solution Projects:
Common internal schemas (event / EDA Meta information , internal
errors etc)
Canonical Domain schemas (i.e. the internal / enterprise
model of Invoices, Claims, Transactions etc of your business)
Helper assemblies for interacting with the above
Your application solution references the above, and then the commonly accepted separation is along the lines of the artifact types:
External system schemas (if more than one, then each in its own assembly)
Maps
Pipelines
Orchestrations
It's really a judgment call. If you have large app with lots of Schemas, Maps, Orchestrations, sure, it makes sense to split them out.
However, small apps, 10 or so artifacts, not so much.
For a new BizTalk Developer, I'd stick with stick with one "MyBusinessProcess" app. At some point, you'll see an when a multi-Project solution starts to make sense, then do it.
I am trying to implement modular design in an asp.net project dividing the application into different modules like HR, Inventory Management System etc. Since I am trying to keep different modules independent of each other, I separated these modules in such a way that each module is a separate Visual studio solution having UI, BLL, DAL and even a separate database schema.
Up till now I thought this as a common practice for developing Management systems and ERPs but I am searching the web for last three days but hardly found any help full stuff regarding developing modular applications. Most of what I found is mere theory explaining the concepts of cohesion and coupling but not real world scenarios. So I wonder
Is it the right approach of separating modules?
How the real world modular applications are developed?
How should the different modules communicate with each other yet they stay independent of each other.
I think there should be a core application which makes use of these modules, how should the core application communicate with these modules?
There is some data, entities , objects which are common to each module, should I put them in the core modules in order for other modules to use them (I think this will make the modules coupled to core) or should every modules maintain its own copy of data + define those object, (which I think voilates DRY)
Any thoughts, links are warmly welcome.
This is a personal opinion and is debatable.
I separated these modules in such a way that each module is a separate Visual studio solution having UI, BLL, DAL and even a separate database schema.
Sounds like a total overkill. Abstraction over abstraction makes your application pain in the neck to maintain, support, and enhance. Is it that large that you need to separate modules into separate solutions?
Is it the right approach of separating modules?
No, I think it is a total over-engineering. I would suggest using projects to separate modules. And not separate solutions. The problem with solution is that it will require external dependencies management tool, which requires a lot of effort to bring in and later maintain.
How the real world modular applications are developed?
Using abstraction (interfaces and abstract classes) and separate projects.
How should the different modules communicate with each other yet they stay independent of each other.
By using interfaces, DI, IOC, TDD
I think there should be a core application which makes use of these modules, how should the core application communicate with these modules?
Core does not communicate with modules. In fact it should ideally not depend on any other project/library. This makes it simple to reference and use in large solutions.
There is some data, entities , objects which are common to each module, should I put them in the core modules in order for other modules to use them (I think this will make the modules coupled to core) or should every modules maintain its own copy of data + define those object, (which I think voilates DRY)
I would highly recommend using a single copy from the Core project. See this questions for details of why.
This is one of those topics that is entirely subjective for the most part, but you may wish to consider a SOA (Service Oriented Architecture).
Using SOA, you can define a service (for this example, I'll stick to web services, though other service types exist depending on requirements) for each business area - an HR web service, a projects web service, a finance web service and so forth.
You can then bring all these together with a front end system that will communicate with and utilise these services, that would normally be your core application, though depending on your needs and requirements you may opt for multiple front end systems.
For the front end system I would recommend using ASP.NET MVC which has the concept of areas and will let you separate the front end into specific areas - an HR area, a projects area, a finance area and so forth that will contain the models and views for each specific area.
Doing this will let you build in a modular manner, you can build your first web service, say, the HR web service, that has methods for getting relevant HR data and so forth, and then build the HR area of your MVC application. Expanding then simply depends on building the web service, and creating the front end in the MVC application. There is nothing stopping say the HR area then accessing the finance web service if it needs finance information, but it still keeps everything in distinct independent modules.
Using this method can also be helpful in aiding future interoperability - it may be that other systems in the company will find it useful to interact with certain web services. For example, in a previous role it was useful for the companies engineering software to integrate with the projects team web service as it allowed for engineering related information to be linked to it's related project.
If the system grows in terms of resource requirements it should also be fairly scalable as it is trivial to say, offload the projects web service to another service if it starts eating a lot of system resources. It also allows you to switch modules out if need be - if you ever decided to move to say, a Linux/Java platform, you could trivially move by porting module by module with no real interruption of the overall system.
But of course, as I say, this is simply one such option and much of it depends on the specifics of your circumstances.
It is too late to answer but it seems interesting.
Since I am trying to keep different modules independent of each other, I separated these modules in such a way that each module is a separate Visual studio solution having UI, BLL, DAL and even a separate database schema.
It depends on your scale of application. If you create a very small-simple application with a little functionality, then it is safe to has a combined assembly. Or if you want, just separate the UI with other module. At least it can help you to emphasize SOC. Keep in mind that loading multiple assembly can be slower than a single assembly.
Is it the right approach of separating modules?
Module separation always has a drawback, that it is require mapping. It means slower performance in general (maybe negligible, but still there is), and slower development time. If your application will be large and complex enough, it is worth it, since you can create modular unit tests for each module.
How the real world modular applications are developed?
No exact practice though, every problem needs a solution. You won't need a heavy multi-threading or dependency injection architecture for a simple calculator application.
How should the different modules communicate with each other yet they stay independent of each other.
Using interface. You can make the implementation different later on. Example is, you currently use C# Winform for your application, communicate to the BLL using interface. Later on, you want to migrate to ASP.Net, then you just change the implementation, but keep the interface to communicate with the BLL the same.
I think there should be a core application which makes use of these modules, how should the core application communicate with these modules?
There is some data, entities , objects which are common to each module, should I put them in the core modules in order for other modules to use them (I think this will make the modules coupled to core) or should every modules maintain its own copy of data + define those object, (which I think voilates DRY)
I assume it is an enterprise level application which share the same modules / data such as employee. If it is really need to behave uniformly, then you should provide the very basic logic at the core Level. At the application / implementation level, you may has different implementation to fulfill each requirement.
Do not force to uniform all of the business logic to the core. If a specific application need a different implementation, it is hard to make the core configurable.