The microservice architecture is well known and will not be repeated here. When we create microservices, we need to create a microservice with high cohesion and low coupling. The bounded context in DDD perfectly matches the requirements of microservices, and the bounded context can be understood as a microservice process.
The above is to describe the similarities between the two from a more intuitive point of view.
After the system is complicated, we all need to use divide and conquer to disassemble the problem. There are generally two ways, the technical dimension and the business dimension. The technical dimension is similar to MVC, while the business dimension refers to dividing the system by business areas.
The microservice architecture emphasizes dividing and conquering from the business dimension to deal with system complexity, and DDD also focuses on the business perspective. If the goals (business dimensions) pursued by the two achieve the unity of the context, what are the connections and differences in specific practices?
DDD is a strategy based on modeling your business using OOP, implementing business requirements directly within the model. DDD helps building software more effective, by allowing better mutual understanding between software programmers and business experts.
Microservices is a software architecture. It drives how to technically structure your software to achieve good execution performance, scalability, security and maintainability of a growing code base without expanding the technical debt. It helps building software more efficient.
Actually the two concepts are very orthogonal although both are needed for good software quality. You could, however, make a non DDD microservice, or a monolithic DDD application.
In my opinion, when we think of distributed systems and microservices we think of DDD as well. Both approaches don't live alone, they are a complement of each other.
There are a lot of reasons why we segregate our applications in microservices, which may get for business or technical approach and we always use the DDD concepts to translate the business world for our tech world.
In a context of several spring boot apps, sharing some components, is that considered as a bad practice to publish an artifact used in those apps?
I'm planning to reuse controllers and services abstracts and low level classes (for statistics requiring fast write access, so webservices are excluded).
There are two contrary paradigms, both definitely make sense on their own, but in this case they front each other. Hardcore microservice evangelists would roughly claim that there should be no common dependencies at all to reduce coupling between the different services / applications. That means although in case the services share many architectural patterns, you have a lot of "copy and paste" code. And exactly that would make the don't repeat yourself faction angry, because it makes also sense thinking about why not sharing already implemented functionality.
So the correct answer is: "It depends." It will always be a tradeoff between following the one law by violating the other. You can just make an economical / cost-effective decision and figure out what is feasible for your infrastructure and what causes less technical debt.
What are the best practices of designing API for your application model? Application should be separated as much as possible from user interface through such API.
What you need is a sort of MVC pattern for your application. I don't know are the namings same in the Java world, you have MVP / MVVM patterns at your disposal.
Of course, this is just for presentation part, you must take into account the size and needs of your application, so you can have service layers, database layers, network layers etc...
Check out Fowlers Patterns of Enterprise Application Architecture, check Domain Driven Development, check Onion architecture. It is a lot, but gives you some directions.
I've been given an assignment to create a visual component for a software competition. The only solid requirements I have are that
1. It needs to visualize data given through ActiveMQ
2. The information needs to be organized and visually appealing (information is presented as charts and graphs, and some nice UI elements are desireable, like tabs, accordion menus etc.)
At first, SmartGWT seemed like a good choice, but it seems that I cannot connect it to any messaging service before upgrading to a paid license, for which I do not have the funds.
Considering the fact that the requirements haven't yet been clearly stated and will be redefined probably in the near future, I cannot waste anymore time studying new technologies only to find out that I cannot use them for my needs. I'm considering something as close to Java (or JVM) as possible, as the software competition is Java based.
So, what framework would you recommend for me and why?
Grateful in advance!
Spring MVC ala the Spring framework.
It works in conjunction with ActiveMQ which meets your initial request. In addition the level of separation via the MVC pattern it provides is very nice as well as the ability to plug-in 3rd party components as needed.
Here is an article stating reasons to make use of Spring. You can ignore the J2EE stuff unless it is applicable to you; however note the Dependency Injection, Inversion of Control, and Aspect programming sections.
I've done lots of java web development using jsps and servlets, and I have found this approach to be straightforward and flexible. Some of the groundwork involved though - such as managing database connections - is rather tedious, and it takes a fair amount of work just to get a new web app off the ground.
I'm therefore considering using a framework for the first time, but my impression of frameworks is that they're mostly used for large J2EE applications and involve a lot of complex configuration. What I'm looking for is something simple that (after the initial learning curve) will enable me to get up and running with a new web app as quickly as possible.
So my question is - does it make sense to use a framework for a simple java web app?
Note that I'm not asking which framework to use (if indeed a framework is recommended), as it has already been asked here.
If you don't use a web framework you'll usually end up writing one - poorly.
It makes a lot of sense. My team has spent the better part of five years with our open source stack and no matter and we have a "seed" project (works like appfuse) that we use to create all new web apps. Even the simple two pagers from the pov of maintaining the app, it looks like every other app, just smaller.
The short is you won't get any return on the investment right now, but you will as the project evolves and you maintain it.
Yes, I would use a web framework for the following reasons:
Increased navigation capabilities and controls. Even though you may not need them, they are there for you to use should you require them at any time
As others have indicated, apps grow over time and you will feel the need for the framework at some point in time in the future. When you need to add additional pages and navigation
Features that allow you to plug into other frameworks such as security and DB access frameworks. Spring is a prime example in the Java world. You never have to use Spring but it plugs in so well with Struts, Spring MVC, Hibernate, Acegi etc. It ends up saving you the hassle of doing all of the plumbing on your own.
Support!!! Good frameworks almost always have a vibrant community to support them and ask and answer questions.
It may seem like too much hassle initially but definitely saves you much time in the future
I'd say it actually matters quite a lot which framework you go for. Something like Spring MVC is fairly unobtrusive in your code and allows you existing stuff to run quite a lot as-is. Other frameworks have much more specific ideas about how you should do things.
Yes it does make sense. Apps can grow and change and might require something a framework can provide easily in the future.
For example at my workplace we have simple jsp / servlet app. It needs to be rewritten just because of what I explained above. If someone would have taken the time to just get the framework setup we would be in better shape today.
Yes it makes sense. However implicit in your question is that the wrong (for you) framework can be more pain than it's worth - and that's true. There is a world of difference between some heavy J2EE framework and something light and cheerful like grails.
What's the alternative? Rolling your own? Embedding all the navigation and logic in the JSPs?
I agree with those who say that a web framework is worth it. There are literally hundreds now (e.g., Struts, JSF, Spring, Wicket, etc.). Pick one that suits you.
There are two kinds of applications:
1) the kind that you throw away and never use again, and therefore should not worry about modularity, maintainability and clarity.
2) the real kind.
It may sometimes seem that your app may never have to grow, scale, or service a larger feature set / user base than you currently are planning for....I assure you, that perception is always wrong.
Frameworks, specifically things like Struts for MVC in Java, Spring for MVC and Dependency Injection, Hibernate for Object-Relational Modeling are all extremely valuable tools that lead to modularity, maintainability and clarity in your code. So, to answer your original question.... Yes, emphatically.
No it doesn't unless:
you don't have any java experience
in your team
you are doing just a prototype that
must be ready in hours
you don't trust your developers
enough to let them write your
application
you don't plan to let your
developers learn and improve
Danger in using frameworks include but not limited to:
you'll get all framework defects on
top on your own
you'll be unable to do realistic estimates until you
know perfectly the framework
your team won't learn how to program a
web server
you'll find your team passing more
and more time on google instead that
solving problems by writing code.
The only thing that is worst that choosing a open source framework is having a separate R&D team in the company who should create the "big complete ultimate company framework".
but my impression of frameworks is that they're mostly used for large J2EE applications and involve a lot of complex configuration
Not necessarily true. The good frameworks are built to scale well so that they will take you from small apps to very large apps. Many of the frameworks today are moving towards zero configuration so you will find them easier and easier to use.
You are right that it does take an initial effort to learn the framework itself but that investment pays for itself in the very first application you build. And meta frameworks like AppFuse makes it even easier to get started since it pre-configures the frameworks for you.
Frameworks make sense for most applications. It may be necessary for you to build your own or adopt some other framework. The most important questions is the granularity of your data structures. What I mean by this is do you need to just enter data or do you need to parse, compile and execute dynamic code?
If you think of a frame works as a gauge and to the left is an all ready existing frame work open source or closed and to the right is all custom framework then super impose your code on top of that frame work where the level of complexity increases to the right. The farther right you go the more of a stuggle you will have with the frame work (IMO).
However, you can also slowly migrate from existing to custom framework.
There is also the question about your business. If you work for a business that does not look at software as it's core compentency such as a bank or hospital then you need to way that into how much of a frame work you want to build.
Bottom line a framework of some type will always be useful.
Using a framework may add some overhead to your web-app development due to the learning curve. However, depending on the framework you choose, you may be able to realize the following benefits:
Scalability
Maintainability
Clear Division of your model (e.g. MVC)
Out-of-the-box components(SessionManagement,authentication,etc )
Third party plugins
Modularity inherited from the framework
Many others.
Besides, the learning curve is a variable factor. Some frameworks may be easier to learn than others depending on your skills.
It definitely makes sense to look into using a framework even if for no other reason than it'll give you a new area of knowledge. If you've got the time to invest in learning a framework then you may well find in time that it's easier and faster to use that for new projects no matter how simple they are.
Also, if I could vote for SamBeran's post then I would. Getting started with a framework will involve several moments of "oh great! I don't need to write all that boilerplate again!".
I'd say use one - like you said, it's rather tedious to get stuff up and running for even a simple java web app. If the framework helps you get the job done faster and provides the services you need, I'd say it makes sense.