When Performing Class Discovery

I usually start by decomposing the systems into interfaces, controllers, and entities. Classes, relationships, and packaging will be refined, adjusted, split, or merged (refactored) in subsequent steps when assigned various design properties-such as operations, methods, and state transitions.

<<Boundary>> (Interface) classes

Boundary classes either represent interfaces to users or to other systems.
Typically, boundary classes represent interfaces to other systems and are modeled as subsystems (service domains at the highest levels). Because they often have complex internal behavior, the internal subsystems can be modeled using boundary classes if the interface behavior is simple and can be decomposed into simple boundary classes using a single (boundary) class per interface type UI, protocol, or API and note special requirements about standards you used in the special requirements of the class.
Boundary classes that represent interfaces to users generally follow the rule of one boundary class for each window, or one for each form, in the user interface. Consequently the responsibilities of the boundary classes can be on a fairly high-level, and need to be refined and detailed through several iterations.
A boundary class (or set of classes) perhaps aligned to the subsystems/service domains can be used to represent the collection of services that can be exposed via a web service. Internal to a given subsystem a boundary class might describe a set of internal interfaces that are available via RPC.

<<Entity>> classes

During analysis, entity classes represent manipulated units of information. Entities are often passive and persistent. The details of designing a database-based persistence mechanism are not the focus of entity modeling at enterprise level. Performance considerations could force some disparate implementations. Since the enterprise entity model forms the basis of data/information governance, all implementations should be able to show consistency to the entity model and standard for inter-domain communication should be the entity model.

<<Control>> classes

A control class is responsible for managing the flow of a use case and, therefore, coordinates most of its actions; control classes encapsulate logic that is not particularly related to interface issues (boundaries) or to data engineering issues (entities). This behavior is sometimes called application logic or business logic.
Take the following issues into consideration when control classes are utilized:
Complexity - You can handle uncomplicated controlling or coordinating behavior using boundary or entity classes. As the complexity of the application grows, however, significant drawbacks to this approach surface, such as:

• the use-case coordinating behavior becomes tied to the interfaces, making it more difficult to model the system and allocate responsibility appropriately
• the interfaces become burdened with additional functionality
• the same interfaces cannot be used in different use-case realizations without difficulty
• the entity objects might become burdened with use-case specific behavior, reducing their generality
• size estimates generated off the model become less reliable because “controller” behavior and size is obfuscated

To avoid these problems, control classes are introduced to provide behavior related to coordinating flows-of-events, life cycle, workflow, etc. However, if the probability of changing flows of events is low or the cost is negligible, the extra expense and complexity of additional control classes might not be justified.

Distribution and performance

The need to run parts of the application on different nodes, or in different process spaces, introduces the need to specialize design model elements. This specialization is often accomplished by adding control objects and distributing behavior from the boundary and entity classes onto the control classes. In doing this, the boundary classes migrate toward providing purely interface services, the entity classes move toward providing purely data services, and the control classes provide the rest.

Transaction management

Managing transactions is a classic coordination activity. Without a framework to handle transaction management, one or more transaction manager classes would have to interact to ensure that you maintain the integrity of the transactions. Therefore these controller classes sometimes get implemented outside of the service domains directly on the service bus (a variation of the node comment earlier)