Boundary-Control-Entity (BCE), or Entity-Control-Boundary (ECB), or Entity-Boundary-Control (EBC) architecture is a directory (package) structure pattern for sorting classes. It is an alternative to layered architecture. It is very simple and natural way to structure classes, which goes well with modularized architecture. One creates one BCE package structure per a microservice, feature or module having ideally between 9 to 30 classes.
BCE is distinct from the multi-tier architecture in that it does not see some outside systems as backend and some as frontend. It has single category of outside systems. Sometimes BCE is being compared to MVC architecture where Model ~ Entity and View ~ Boundary.
The package structure is often visualized as tree onion layers, or as a hexagonal layers, where the most outer layer is Boundary, central is Control and inner is Entity.
- Boundary is an interface to the outside world. It contains classes responsible for all communications with systems outside application runtime. It contains configuration, and establishing external connections.
- Control represents all logic that doesn’t fit well into Boundary. It contains algorithms, SQL Queries.
- Entity contains data structures which are allowed to have some behaviour. It contains domain objects with basic functionalities.
Functionality Folders vs BCE Structure
I am very much for structuring, modularization and encapsulation according to end result features. However, often after separation per major features on sub 30 classes level, I think it is more practical to structure according to technical behaviour. Thus I suggest to use BCE architecture which represents that.
At the same time, don’t be dogmatic and if there are good reasons do what works in the specific case. The BCE could even exist in the sub-folders of a parent folder. The parent folder than can follow service-oriented architecture, where each microservice has its own folder and runtime. Or some of the folder could have to have different names e.g. boundary may have to called “mojo” for example. If BCE doesn’t work for you, let me know!
Sometimes an additional dependency rule is being added to BCE: Classes can depend on other classes only within same layer or in one more inner layers. I personally found that this rule impractical mainly thanks to modern tools like annotations. For example annotation on Entity class can reference a serialization class residing in Control.
SQL Queries and Repository Placement Dilemma
Where to place a classes that implement methods to query database? For example Spring Data repository classes in Java? Repositories do define interaction with database. The dataset is an outside system, which would mean we should be placing them into Boundary. But on the other hand they contain application logic in a form of a SQL queries, which should be placed in Control package instead. I place repositories into the Control package. However, code that deals with connections to the database, retries, transactions, database configuration, belongs to the Boundary.
For real world example you can have a look at this version of Gitflow Incremental Builder, which I founded, but which was developed beyond by phenomenal dev Falko. Read more about Gitflow Incremental Builder here. For an overview of boundary control entity architecture folder structure:
- EventController: REST definition.
- DBConnector: DB configuration, connection
- EventTransformer: Transformation between Entity and Payload.
- EventRepository: DB query definition.
BCE Quiz Challenge
Retain what you have just read by taking training quiz generated from this article.
Continue: The Cuts Across Your Architecture
Localize Related, Inline over Extract, Specific over Generic BCE does not tell you everything, there are priciples that cuts across the BCE architecture. Learn about code structure principles - Localize Related, Inline over Extract, Specific over Generic.