Bureaucratic Design With Java EE
You can structure your Java EE applications without any further thinking by placing the contents into Java packages with names like: "exceptions", "beans", "interfaces" or whatever else emphasizes the obvious content, but not the actual responsibility. The question to answer is: how often do you actually searching for exceptions or interfaces?
In the following screencast, I used the ancient ECB pattern to structure Java EE applications:
My following pet projects: https://github.com/AdamBien/lightfish, https://github.com/AdamBien/e2ftp, http://x-ray.adam-bien.com, as well as, several commercial projects were already built according to the structure described in the screencast with good experiences so far.
See also other screencasts at: http://tv.adam-bien.com or subscribe to http://www.youtube.com/user/bienadam.
[See also an in-depth discussion in the "Real World Java EE Patterns--Rethinking Best Practices" book (Second Iteration, "Green Book"), page 419 in, chapter "Entity Control Boundary (ECB)—The Lean Way"]
See you at Java EE Workshops at MUC Airport, particularly at the Java EE User Architectures workshop!
Not sure I follow you entirely here. You state you don't want to name things after technical terms but just have made up new ones in the package names "boundary", "control" and "entity" and structure your project along these lines. So you traded one kind of technical separation for the other kind.
What's wrong with staying with "blog" as the high level package name and just putting all three classes into the very same package. This has the benefit, that you can even make components, that other parts of the system shouldn't even use (as they make up the internals of you Blog component) package private. This might result in a few more classes inside the package but the view from the outside is much more focussed as the compiler helps you detecting what you're allowed to use and what not.
Read more on that approach at http://www.olivergierke.de/2013/01/whoops-where-did-my-architecture-go/
Cheers,
Ollie
Posted by Oliver Gierke on October 18, 2013 at 03:25 PM CEST #
@Oliver,
I always structured components with sub-packages and had good experiences so far:
- developers liked the clear structure. I got only good feedback so far.
- with sub-packages it is very easy to measure the dependencies between components and automatically validate the architecture with simple tools.
- you can leverage package-private visibility for additional encapsulation / easier communication within the package.
- you can build components without the boundary and so components not accessible to the presentation layer.
However, I made bad experiences with my own naming. I switched to ECB and since then I never had to justify that in boring meetings :-).
Btw. "my" components never comprise 3 classes. A typical component consist of 10 - 20 classes.
thanks for your comment!,
--adam
Posted by Adam Bien on October 18, 2013 at 10:36 PM CEST #
awesome java
Posted by 117.242.144.46 on October 19, 2013 at 08:13 AM CEST #
okay okay questions
Posted by 117.242.144.46 on October 19, 2013 at 08:14 AM CEST #
hi Adam,
Why is it the responsibility of the boundary to persist the entity ? I would imagine one would defer that to the control layer
/rune
Posted by Rune Molin on October 19, 2013 at 02:00 PM CEST #
Haven't watched your screencast, but I want to share an idea:
Why do companies continue to use their company's web domain as a prefix for all packages?
Most, if not all Java EE applications have no security policy applied to Java packages, so why bothering using "com.mycompany.mydepartment.myteam.myproject" before everything?
Just use "package projectname;" as root, and then the rest.
Posted by Bruno Borges on October 28, 2013 at 08:44 AM CET #
@Bruno,
a very good point. For me the company name was always a set default. I never thought about that.
I will steal your comment for the next post :-)
thanks for the inspiration!,
adam
Posted by Adam Bien on October 28, 2013 at 07:12 PM CET #
Hello Adam.
In what package you will put classes with @Named annotation (for example Posts list).
Your BlogEngine is looks like a first step to Rest (savePost, getPostById, getAllPosts) because of @Sateless annotation and injected EntityManager or some kind of Repository.
Does it's not good to mix @Named and @Stateless in one bean?
And you don't have '.core.' package so it's not enterprise :)
Thank you.
Posted by Sergey on October 31, 2013 at 05:23 PM CET #
Hi,
You state you're never design your application by technical structures. Where would you pack exceptions to? Especially if they are used through the whole project.
Moreover do you allow calls from a.boundary to b.boundary/b.controller and a.controller to b.controller where a and b are different domain packages.
Thank you
Posted by Manfred Pauli on November 07, 2013 at 12:22 AM CET #
@Bruno,
the use of the company domain was recommended by Sun as a way to preserve package namespace uniqueness and as a way of "badging" the code.
It is still a good idea to name packages this way, even if they are not destined for public consumption.
Posted by Andy on January 22, 2014 at 02:52 PM CET #
Hi,
Iam actually a PHP developer trying step by step to learn Java EE,
from the following tutorial i've tried to implement the ECB pattern tell me if iam wrong
http://www.adam-bien.com/roller/abien/entry/bureaucratic_design_with_java_ee
- Entity -> JPA entity
- Control -> Managed Bean
- Boundary -> Session bean
Actually i maded a component that retrieve page content from a table "pages" following to the id (Page id) provided by the Managed Bean.
i want to know how to do after ?? i mean should i create a servlet and Inject the Boundary in it and work with a simple JSP pages ??
or work with JSF and use the managed Bean inside the component just created ( Control ) ?? what the correct way to do the job ?
ps: my goal is to implement a CMS like joomla just for example to learn java EE.
thanks.
Posted by Ryadh on April 14, 2014 at 02:30 AM CEST #
@Oliver,
ECB is not a technical separation. Package names like "EJB" and "JSF" are clearly a technical separation because they refers to actual technologies. ECB is taken from object-oriented modelling, which is used to model the business as often as it is the application.
Posted by David on June 28, 2015 at 07:01 PM CEST #
Hi Adam,
where would you put interceptors ?
By definition they are "cross-cutting".
In the project I am currently doing I have the boundary, control and entity packages for each business "component". Because of the cross-cutting nature of interceptors I created a fourth package currently named "interceptors". I know ! That's technical like "ejb" and "jsf" ! I thought about putting it in a control package. But the control package of which business component ? Just choosing at random a component seems contrary to the "cross-cutting" nature of interceptors. It would also introduce unwanted dependencies at the component level.
Your insight on this would be much appreciated.
Regards,
Ronald.
Posted by Ronald Wouters on July 02, 2015 at 12:53 PM CEST #
How would you handle deeper package structures?
E.g.:
company.product.component1
company.product.component2.subcomponent1
company.product.component2.subcomponent2
Each component and subcomponent has it's own entities and boundaries.
Naive solution:
company.product.component1.entity
company.product.component1.boundary
company.product.component2.entity
company.product.component2.boundary
company.product.component2.subcomponent1.entity
company.product.component2.subcomponent1.boundary
company.product.component2.subcomponent2.entity
company.product.component2.subcomponent2.boundary
Problem: In component2 business subcomponents are mixed up with entity and boundary.
Maybe I should use _entity and _boundary instead. What do you think?
Posted by Markus on October 23, 2015 at 11:26 AM CEST #
I have blog application
com.example.post.boundary
com.example.post.control
com.example.post.entity
Where do you put comment ?
Inside
com.example.post
or separate
com.example.comment
?
Posted by tomasz on June 24, 2016 at 02:43 PM CEST #
@Tomasz,
put it into post, but watch it. The component "posts" should primarily host post-related ingredients. One or few comment-related classes are o.k. If you get more "comments" - put them into a dedicated "comments" component.
The approach is "bottom up"
Posted by 192.168.0.91 on June 27, 2016 at 01:38 PM CEST #