Repository vs. Service

One issue causing confusion about whether to choose a repository or a service is where to put business logic methods like getEntityItemBySomeAttribute(attribute).

The use of Specifications in a standard query method seems to solve this problem.

Where you would want to choose the Service instead is when the logic of the query spans multiple repositories or a combination of repositories and external services -- this is DDD guidance.

Be mindful of the difference between APIs and SPIs. APIs should be final concrete classes and SPIs should be Interfaces. The clients of APIs are callers while the clients of SPIs are implementers.

I've noticed that repositories are typically SPIs while services are typically APIs.

Refs:
http://wiki.apidesign.org/index.php?title=APIvsSPI&useskin=monobook
https://docs.oracle.com/javase/tutorial/ext/basics/spi.html
http://stackoverflow.com/questions/12317126/onion-architecture-repository-vs-service
http://thinkinginobjects.com/2012/08/26/dont-use-dao-use-repository/ -- notes that DAOs are no longer favored because they are too general and loosely typed.

-------
2015-09-03
Current common practice appears to have a topology like Service<T> --injected with--> Repository<T> --injected with--> JDBCTemplate or DataSource. see http://stackoverflow.com/a/24083073/2066936

CQRS and Architecture

lecture from several years ago. Items of interest are  

• an architecture graphic from 48:57 picturing both validation and business rules as components as opposed to layers
• the idea that a database ("persistent viewmodel") with viewmodel tables should replace the in-memory caches
• capturing the user's intent is not necessarily the same as editing a row in the database: "The fact that they are two columns on the same entity does not mean anything!"
• Example of user's intent is "reserve a block of seats on airplane for family/friends" but UI given is seats with checkboxes and a refresh button (to see what's changed to allow what they want)
• What are domain models for?
• "Domain models aren't for validation." Validation is there in its own component"
• see graphic from 48:57 and 1:29:38 where domain model is the "Rules" component
• validation component is actually the same one on the client-side and server-side (see graphic)
• Domain models aren't for queries.
• Domain models are for business rules: e.g. figuring out how much interest to charge once the user has violated terms of agreement and over-withdrawn their account despite the best-efforts of the client-side validation logic.
• Domain models are for doing what business people spend time on -- thinking of "adding weird ways to add functionality to the system to delight their customers" e.g. is it their birthday, should I send them a birthday present, is he a preferred customer, etc.
• "Client-side controllers [that are using the CQRS queries] are supposed to do [business] logic. It's not that big a deal"
• Quote on commands, that they must go through asynchronous messaging pipeline: "You need to design your commands such that you can say 'Thank you. Your email confirmation will arrive shortly."
• On Relationships
• "Once you've taken out all the relationships from your domain models they've actually become smaller and tighter -- focused really just on processing commands"
• And DTOs, ORM, etc. is removed from the query procesing and replaced with the one-table per view ViewModel (note points on search recommendations and removing ability to do complex queries from the user)

Quotes:
"Writing a custom form to accept: how many seats do you want? What kind of seats do you want? Trivial forms to write. Writing these query screens, now that you don't have to go through DTOs and domain models and object-relational mappers, and god-knows what else -- these are a lot of easier to write too! Once you've taken all these relationships from your domain models, they've also become quite a bit smaller and tighter focused really just on processing commands.

"Yes you do need to understand what your users are using the system for. Otherwise just give them access to your database and be done with it. "

"You can't shoehorn a CQRS architecture underneath an editable datagrid. Do not try. User interface design is as much a part of architecture as anything else that you do."

https://skillsmatter.com/skillscasts/1250-udi-dahan-command-query-responsibility-segregation#video

Domain Service vs Application Service

• If you follow Domain Driven principle, Order is a domain object but Email Sender maybe is a service ( different from Domain Service ) so you can’t use it in your model.

http://www.javacodegeeks.com/2013/08/how-to-use-events-in-spring-3-x.html

Other times I think of services as little classes that don't represent a particular person, place, or thing in my application, but that tend to embody processes. Domain services usually fall in this latter category. They tend to be named after verbs or business activities that domain experts introduce into the Ubiquitous Language

http://msdn.microsoft.com/en-us/magazine/dd419654.aspx#id0090088 - goes on to describe in contrast how application services perform mapping between layers or other modules

From Singleton to AOP (And Everything in Between)

This article on game development touches on the nuances faced and the angst developers face when dealing with complex systems and still adhering to best practices ala IoC. The highest voted answer seems to favor neither the service locator pattern nor the singleton, but seems to lean toward dependency injection ("passing around the instances"). Nevertheless the OP appears to settle on Service Locator.
http://gamedev.stackexchange.com/questions/84197/how-can-i-avoid-having-many-singletons-in-my-game-architecture

An alternative to all three could be AOP as shown in this old article: http://blogs.msdn.com/b/simonince/archive/2008/06/30/dependency-injection-is-dead.aspx

But if you think that DI is hard, DI via AOP is certainly an order of magnitude harder -- which is probably why it's not spoken of much.

Private Inner / Local Classes - Advantages / Disadvantages

Good debate found here: http://stackoverflow.com/questions/3353318/how-do-i-test-local-inner-class-methods-in-java

The consensus (and accepted answer) is that in general if it's important enough for a local / private inner class to be tested, it should refactored out, e.g. to a separate package.

On the other hand, "bob" makes a good point about keeping the class internal as an implementation detail for the sake of cohesion.

Kai Sternad provides an answer that probably could have been accepted.