While MVC remains the go-to approach for designing a UI, many criticisms arose with its prevalence. Most critics are actually pointing a finger at the incorrect use of the pattern.
Eric Evans' influential book Domain Driven Design, also abbreviated as DDD, defines a set of architecture rules leading to a better integration of the business domain inside the code.
One of the core ideas is to take advantage of the object-oriented paradigms inside the domain objects. Going against this principle is sometimes referred to as Anemic Domain Model. A good definition of this problem can be found on Martin Fowler's blog (http://www.martinfowler.com/bliki/AnemicDomainModel.html).
An Anemic Model typically exhibits the following symptoms:
This can be a bad practice depending on the complexity of your business domain. Generally speaking, DDD practices require additional efforts to isolate the domain from the application logic.
Architecture is always a tradeoff. It is good to note that typical ways of designing a Spring application can lead to complicated maintenance somewhere along the road.
How to avoid domain anemia is explained here:
FirstName
class rather than a string.There is much more to DDD than these simple rules: Entities, value types, Ubiquitous Language, Bounded Context, Onion Architecture, and anti corruption layers. I strongly encourage you to study these principles on your own. As far as we are concerned, with this book we will try to keep in mind the guidelines listed earlier as we craft our web application. These concerns will become more familiar to you as we advance through this book.
If you're familiar with Spring, you have probably already landed on Spring's website, http://spring.io. It is entirely made with Spring and the good news is that it is open source.
The code name of the project is sagan. It has numerous interesting features:
The GitHub wiki associated with the project is really detailed and will help you get started easily with the project.