The Clean Architecture from an Object-Oriented perspective


The Clean Architecture is a new-ish architecture pattern promoted by Robert C. Martin, better known as Uncle Bob. Uncle Bob’s name is probably familiar to anyone who has done any software development in the last decades, from his books like Clean Code, to the SOLID principles, both used and referred to by developers all over the world.

This article is an in-depth analysis of the post The Clean Architecture, from an object-oriented developer’s view, with the goal of determining how well the proposed architecture components and building blocks conform to object-oriented principles. As the book “Clean Architecture” is not yet available at the time of writing of this article, the information is augmented by Uncle Bob’s presentation available on YouTube, and the Clean Code Case Study project on GitHub.


As Uncle Bob is very well known for his lectures and books on object-orientation, it stands to reason that his upcoming book “Clean Architecture” will be read by many object-oriented developers, beginners and experienced ones alike.

It may be important to point out therefore, that his proposed architecture pattern does not seem to target the object-oriented development paradigm. While it may be true, that it can be implemented with an object-oriented language, using object-like constructs and syntax, the bulk of the proposal seems to be based on the procedural mindset.

This article’s goal however is not to compare paradigms, or to argue which one deserves our respect the most, but to analyze The Clean Architecture for those developers who already decided to follow object-oriented principles.

Setting the Stage

Uncle Bob’s post starts by listing several related architectural patterns from which The Clean Architecture drew inspiration from, including:

Though these architectures all vary somewhat in their details, they are very similar.

It is true that there are several concepts in all of the listed styles that appear very similar, and indeed from a mixed-paradigm programmer’s view they might just vary in details, but there are significant differences from an object-oriented point of view.

The DCI Paper for example, although its title suggests an object-oriented approach, clearly isn’t one. The stated goals of those authors is to create a mixed- (or multi-) paradigm approach which very consciously has procedural elements to counteract perceived shortcomings of a purely object-oriented design (see Chapter “Where did we go wrong?” in the Paper). Regardless whether those shortcomings are real or not, the authors decided to deviate from object-orientation at the core of their proposal.

The same can not be said of the other architectural styles. While there might be interpretations of those styles that lead to a contradiction of object-oriented principles, they do not do this by design.

They all have the same objective, which is the separation of concerns.

Separation of Concerns is a very important concept, but it is one that has very different meanings in different contexts. In the context of Clean Architecture it seems to be referring to the complete separation of different aspects of the logic, for example separating the Presentation, Persistence and possibly other aspects out of the objects that are actually containing the data and the context for all those operations.

This is a very common interpretation for layered designs, also often seen in Java Enterprise software. It is in fact part of the best-practices for enterprise designs, and goes hand-in-hand with multi-tier designs.

It is however dangerous territory for an object-oriented developer. In object-orientation the separation of concerns refers to two foundational attributes of Objects, their inner Cohesion and Coupling with other objects.  Simply, but perhaps less precisely stated, these mean that objects should contain every business function that are highly related to other functions and data in the object.

Object-orientation does not discriminate among functions based on purpose. The function to present some object on the screen or present an object as XML is every bit as valid as other functions that “only” modify the object’s state. Therefore all requirements, regardless of technicalities influence object design, and both Persistence and Presentation are part of the business interface of an object, if requested by the specification.

This of course does not mean that details of the Presentation and Persistence should be in business objects, but it does mean that at least some abstract notion of these should be found in the object, and there should be nothing outside the object that knows the object-related details of these function (like which fields are persisted or presented), at least not with the same semantics as in the context of the object.

Nothing actually needs inherent separation, unless dictated by cohesion or coupling, or outside architectural constraints like distribution or other boundaries. Therefore this goal of separation of certain aspects out of the object is very dangerous for, and perhaps irreconcilable with object-oriented design.

They all achieve this separation by dividing the software into layers.

Layers are good way to separate objects which naturally reside on different abstraction levels. For example one could easily imagine a Network Stack to be composed of different groups of objects mirroring the structure of the ISO/OSI Layers. There would probably be objects for the Network Layer which offer routing capabilities, and there would probably be objects responsible for the Transport Layer, implementing the TCP and UDP protocols. The Transport Layer objects would have access to the Network Layer objects, but not the other way around, hence they would form a layered structure.

This interpretation of layering would be a very effective way to decompose the problem of implementing the network stack. It is however not what is proposed above. Clean Architecture proposes to separate different cohesive aspects of the same object into multiple different pieces, which does not seem to be compatible with basic principles of Object-Oriented Design.

Goals of the Architecture

Each of these architectures produce systems that are:
1. Independent of Frameworks. The architecture does not depend on the existence of some library of feature laden software. […]


If we consider the context in which this statement is made, it seems to suggest that the “business objects” need to be completely independent of frameworks and external libraries. No mathematical library, no “commons” library, no messaging library, no CDI, no EJB, and certainly no presentation or database libraries.

Arguably all of these decisions should be made in light of functional and non-functional requirements, instead of categorically forbidding all of them without any clear and present benefit.

There is however a good point made, that the architecture itself should not depend on a library (or framework). It might be helpful to slightly differentiate what a library and what framework is.

A library is merely a collection of objects (classes) that have some functionality. We depend on libraries because we want to re-use some functionality, like logging, I/O, network communication, etc. A framework also offers functionality, but at the same time imposes some form of design control. It offers its functionality only if some or all parts of the code that uses it conform to some design restrictions, or is implemented in a given paradigm or pattern.

Having a dependency on some framework at the core of the application usually comes with a lot of drawbacks, and the above quote is right to say, that the “architecture” itself often becomes dependent on the framework. This may have a catastrophic impact on maintainability later in the software’s life, so frameworks should be avoided if at all possible.

The quote however goes further, implying that all dependencies should be avoided, even dependencies to a plain library. We already depend on classes from the JRE, probably Log4j, possibly others. If “architecture” itself does not really depend on these things, merely the code (the implementation) does, then this is not really a concern.

Complete independence from all dependencies, as suggested by the above point, may be neither achievable nor desirable.

2. Testable. The business rules can be tested without the UI, Database, Web Server, or any other external element.

Testability is an important and desirable aspect, and it should be possible without additional objects or external systems. To be able to write unit tests for a class is actually a good indicator for a good design.

However, this rule should not only include “business rules”. Unit tests should also cover the UI and Persistence too, in exactly the same way, without external elements. The concept of testability should not be used to suggest that the UI or Persistence are inherently less important, or get in the way of testing other aspects of the object.

3. Independent of UI. The UI can change easily, without changing the rest of the system. A Web UI could be replaced with a console UI, for example, without changing the business rules.

4. Independent of Database. You can swap out Oracle or SQL Server, for Mongo, BigTable, CouchDB, or something else. Your business rules are not bound to the database.

5. Independent of any external agency. In fact your business rules simply don’t know anything at all about the outside world.

It is very much debatable whether switching a web-application to a console-based application, or switching a relational database of an application to a NoSQL one are common use-cases in software development. It does happen of course, but it is debatable whether a significant enough portion of a software developer’s work is dedicated to these tasks. Probably much more work is done fixing bugs and implementing new features which do not require a full technology switch.

This complete independence of UI, Database and indeed the whole outside world would therefore be desirable only if this independence would come at no, or very little cost. This is however not the case, as additional “layers” are introduced, with additional boundaries which introduce much unnecessarily complexity into the application. The Keep It Simple principle should apply, and this decision should not be made just for the potential to be a little more flexible for a mostly theoretical use-case.

Other than the above arguably rare use-case, objects should be well aware of the whole spectrum of business functions other objects can ask them to perform. This range of business functions should include at least some abstractions of persistence and presentation if the system is expected to conform to object-oriented principles.

Externalizing the UI and Persistence functions completely also means, that any changes in the “business objects” or “business rules”, even ones which otherwise would be internal to those objects, would ripple through the whole application, or even multiple applications if we are re-using objects.

According to object-orientation, changes to details, like adding or removing private fields in an object should not cause any external changes. This is a very important property which strongly contributes to the maintainability of code, and is arguably impossible to achieve, if parts of the functionality of the object are external to the object itself.


Entities encapsulate Enterprise wide business rules.


What does “Enterprise wide business rule” really mean? Hardly any rule is “enterprise wide”, in the sense that there is some general rule to everything. To sell an upgrade only with a certain product for example is not an “enterprise wide” rule, it is only applicable directly to the sale of the upgrade (whatever that may be), and it probably gets created by the relevant organizational unit (for example Marketing), not involving “the whole enterprise”.

Enterprise wide business rules” might mean that the Entities should be a semantically unified view on something. Like a Product or a Customer, that has meaning to almost everybody in the enterprise. The problem with this approach is, that organizational units and their applications might have a completely different or even contradicting meaning of these things. The bigger an Enterprise, the more unlikely that a unified (“enterprise wide”) model of some aspect can be found.

Domain-Driven Design for example argues that as software (the scope of a problem) gets bigger, finding a unified model is just not worth the effort even if it would be possible. It defines the notion of a Bounded Context, where objects have a specific limited meaning in a very specific context, which can differ or even contradict meanings of the same term in a different context. For example a Product according to Marketing might be something which can be further customized with options like color, or other add-ons, while for Accounting the term “Product” would mean something that has an SKU, which contains all options and add-ons already. The same thing might mean different things to different people or organizational units.

Even if a unified model was possible and it would be re-used across application boundaries, it would become a global dependency for all projects “enterprise wide”. That would cause organizational and operational problems, like: what team would be responsible for it, how to avoid this team becoming the bottleneck for change, and how would an enterprise wide coordinated upgrade even look like when it needs to change, etc.

An entity can be an object with methods, or it can be a set of data structures and functions.

Obviously an object-oriented developer would be limited to the first option, as pure data structures and functions are parts of different paradigms.

It doesn’t matter so long as the entities could be used by many different applications in the enterprise.

This seems to reinforce the idea, that “enterprise wide” above meant some unified model for certain things. Even if this would be possible, it’s doubtful that this property is advantageous for organizational, operational and maintainability reasons stated above.

They are the least likely to change when something external changes.

This only considers one direction of change, and does not address the cost of changing the entities themselves. It implies, that these “core” entities would be stable enough that their cost of change does not matter.

Considering that these entities would have to be unified “enterprise wide” views of things, potentially including multiple different semantics from multiple organizational units and projects, it seems doubtful that they would be stable, unless they were very abstract to the point of having no real meaning at all.

Use Cases

[The use cases layer] encapsulates and implements all of the use cases of the system.

One of the key tools developers have to tackle large problems in computer science is called decomposition. It just means, that we humans are too limited to work with big models and complicated algorithms, so we have to split problems up into smaller pieces. This can be done in multiple ways.

The simplest way to split up a problem, is to try to list the steps necessary to complete the task. Let’s take for example the steps to implement a cash transfer from an account:

  1. Check that the account number exists
  2. Get the account type
  3. Determine transfer limit for given account type
  4. Continue only if given amount is not greater than limit
  5. Check that the account has enough money
  6. Subtract the value from the account
  7. Create the transfer for the amount and send it to clearing

This is very simplified of course, but demonstrates how the larger problem of making the transfer is now split into 7 smaller, easier steps, which can then be further divided as needed until it becomes easy enough to directly code.

This is what is commonly known as procedural design or procedural decomposition. It is procedural, because we are concerned about what steps would need to happen, during which we acquire and modify data (elsewhere) as needed.

The whole thing (“cash transfer”) is called a “Use Case”. Since the “data” part resides in the layer below (“Entities”), the proposed Use Case layer would probably contain the steps necessary to perform it, similar to the above.

Having the individual steps listed sequentially sounds intuitive at first. Indeed, this is exactly what the DCI paper also proposes, and criticizes object-orientation for not doing.

The problem with this approach is, that it does not seem to scale. As long as it contains a limited set of distinct use-cases, the approach works, but as soon as overlapping functions are introduced, it starts to break down.

For example let’s introduce an internal cash transfer Use Case, where the steps are almost the same, but the transfer does not go to clearing, instead it goes directly to the other account internally. The problem now is, that these two share steps. Both have to check whether the money is there, both have to check the limits, etc.

This makes the whole thing error prone an unnecessarily complex. We already solved the checks, but we have to think about them again for this new case. If we forget it, we have a problem, and if not, we increased our cognitive load even if we just have to copy or re-use it. Wouldn’t it be nice, if we could just forget about it once we solved it, and it would get automatically applied when subtracting money from the account?


Well, this is exactly what object-orientation does. Object-orientation proposes a different kind of decomposition, where we don’t really think about the “steps” that need to be taken, but the “things” that need to be involved. In this case “Account”, “Transfer”, “Money”, etc. All these things may have their own rules and behavior, therefore there is no need to think about whether a “step” may mess up an account, or transfer more money than the account has, since the Account object would not let these things happen. In effect we can’t subtract money from the account directly, we have to ask the Account to subtract it for us, thereby also making all necessary checks automatically. This approach however relies on the fact that the “data” is hidden behind operations that already has “parts” of the “Use Case” implemented. Indeed, if all objects are designed correctly, there should actually be nothing left of the Use Case to be implemented separately.

Considering the differences between these two approaches, it seems the proposed Use case Layer might be better suited for a procedural approach, and might be entirely incompatible with an object-oriented one.

These use cases orchestrate the flow of data to and from the entities, and direct those entities to use their enterprise wide business rules to achieve the goals of the use case.

The first half of the sentence seems to reinforce the procedural nature of the design, which would indeed include moving data to and from the entities as discussed above.

The second half implies that the entities may still have some form of proper behavior in the object-orientation sense, not just data, this however can not be seen or confirmed in the case study project or the presentation.

Interface Adapters

The software in this layer is a set of adapters that convert data from the format most convenient for the use cases and entities, to the format most convenient for some external agency…

In an object-oriented approach it is difficult to imagine how such a conversion can happen outside an object, indeed in a completely different layer. Conversion implies access to data, which implies missing encapsulation, one of the key ingredients of object-orientation.

The models [in this layer] are likely just data structures that are passed from the controllers to the use cases…

Since pure data structures are unwelcome in object-orientation, this layer would have to be redesigned to be suitable for an object-oriented software solution. It is not discussed in the Article whether such an alternative design more in line with object-orientation is possible or not.

Frameworks and Drivers

The Web is a detail. The database is a detail.

While it is true, that details of the Web, like whether to use HTML4 or HTML5, and details of the Database like what kind partitioning or indexing is to be used, should be real details and of no concern to business functions, it is highly debatable whether business objects should have absolutely no knowledge of these things.

Arguably the architecture should not be driven by arbitrary notions of cleanliness, but by real requirements and constraints. So the question is: is it really likely that the application will become a non-web-application? If not, why couldn’t an object know that it will be presented on the Web?

What data crosses the boundaries

Typically the data that crosses the boundaries is simple data structures. You can use basic structs or simple Data Transfer objects if you like.

An object-oriented project would probably have to use an alternative approach here, since these things are incompatible with object-orientation.

Or the data can simply be arguments in function calls. Or you can pack it into a hashmap, or construct it into an object.

In the original description of object-orientation, objects are supposed to exchange messages. Objects ask for help to fulfill their own tasks. They ask other objects to do something in their area of responsibility that contributes to the task at hand. Although it is not forbidden, exchanging a lot of data is frowned upon. It usually indicates a bad relationship between objects, where the responsibilities might not be clear enough.

Instead of exchanging data, objects are supposed to exchange other objects for example. These too will have a defined behavior that can be used to fulfill some specific tasks. Whether these parameter or return objects contain a lot of data, or none is usually of no concern to the receiving party.

Therefore, while the above quote could be technically understood to be compatible with object-orientation, the approach itself suggests otherwise.


This analysis revealed fundamental incompatibilities between the proposed “Clean Architecture” and object-orientation in almost all aspects described in the analyzed Post, including:

  • The precursor design ideas, like DCI
  • The goals of the architecture
  • The Entity layer
  • The Use-Case layer
  • The Interface Adapters
  • The Boundaries between layers

Although there are always shades of gray when designing an application or application landscape and there is always room for compromise, it is difficult to image a set of requirements or constraints that would make an object-oriented design similar to what is proposed by Clean Architecture.

This is probably intentional and not an oversight. As Uncle Bob said in his book “Clean Code”:

Good software developers understand these issues without prejudice and choose the approach that is best for the job at hand.

Quite clearly this architecture pattern uses and targets the procedural paradigm, as evidenced by the separation of data and function in almost all building blocks of the architecture.

Furthermore this analysis uncovered some questionable design decisions, which even in non-object-oriented paradigms would probably lead to unwanted consequences. These include:

  • Assuming that changing whole technology stacks (like presentation and persistence) is a significant use-case, worth building the whole application around
  • Assuming a unified enterprise-wide model is possible and feasible
  • Assuming said unified enterprise-wide model will be stable
  • Assuming re-using the same business code in multiple applications is a good thing

These choices influence the whole architecture and it is highly debatable whether these apply to any significant number applications.

The conclusion is, that object-oriented developers should probably avoid the “Clean Architecture” altogether, and even developers of other paradigms should check the fundamental assumptions of the architecture in detail, whether it applies to the application that needs to be build, before applying it in any form.

15 thoughts on “The Clean Architecture from an Object-Oriented perspective

  1. I don’t know how, but you’ve said exactly what I ‘ve been thinking from a long time. I will show your article to every “copy&paste architect”I know, and they are a lot.

    Liked by 2 people

  2. This article open my mind before diving into “Clean Architecture” book. I have little experience in designing applications and i have challenge ahead of me to build one. I think i understand the point of your thoughts and my attention should be directed to architecture design which is based on OOP principels .In short i understand it as objects that exchange messages with other objects, so it has its data encapsulated and we can only get information from objects using his methods (like in example the domain object validate his state itself and we dont have to worry about revalidating state each time we add new use case), so we can use those rich (not anemic) objects and reuse them without thinking again of checking, validating and procedural flow? If i understand it correctly can you give me some clue how to start those approach? I mean something i can follow to consolidate knowledge.

    Liked by 2 people

    1. I think you got it 🙂

      If you need pointers on how to design a well maintainable system, here are some easy rules which almost automatically guarantee a good design:

      – Don’t have getters. Instead of getting data out, objects should do the things themselves.
      – All names (public classes, public methods) should relate to some business thing. Avoid technical names.
      – Try to have any sequence of method calls be something sensible. If it compiles, it should make some sense.

      There is of course always exceptions, especially to the last one for which java doesn’t have strong enough type support, but these exceptions should be rare.

      Does that help?


      1. It helps alot :).

        After writing the post I dived into DDD articles which uses not anemic domain model. A lot information gave me too much confusion. All the concepts like aggregates entities, value objects, business services etc. I don’t want to get into the pattern without understanding why I do it.

        Your rules have simplified the approach that I would like to apply without unnecessary (for now) littering the head with information overload.

        I will stick to this approach and solve problems on a regular basis, thank you 🙂

        Liked by 1 person

  3. > Indeed, if all objects are designed correctly, there should actually be nothing left of the Use Case to be implemented separately.

    Use-Case itself is an object and sometimes introducing processes encapsulated as an object makes the whole system simpler. Consider you have a use-case “If no one can see you take money from the Pocket only with two fingers, but if it is midnight then use three fingers, and then put it into your Wallet.” Just imaging how you add something like this into one of your domain objects (Pocket, Wallet). It is very bad. Instead you should consider creating VeryStrangeButThisIsHowOurAppWorksUseCase.


    1. Why would that not be in `Pocket` or `Wallet`? And even if not, why wouldn’t it be in some other proper object?

      UseCases as defined by Uncle Bob are not objects, they are procedures. They operate on data that is held separately somewhere else, usually in data structures, POJOs, Beans or whatever. Those things are also not objects. The drawbacks are obvious, here are some: There is no encapsulation, because the data structures can be manipulated or used in whatever fashion, the logic to use or manipulate them is not attached. This also means things that influence each other and usually change together are not together. These things are not even using business terminology, they are a technical architecture artifact. What’s a UseCase, Controller, Gateway, etc.? Would a business person know or care?

      I think separating data from logic *by design* should be unacceptable for any system that claims to be object-oriented.


  4. Hm, I am sorry but I have to disagree with you. Clean Architecture and OOP are orthogonal concepts. One can easily do CA in OOP. There are some traps like “anemic models” but in general CA is very OOP friendly.


    1. That would interest me a lot. All examples I’ve seen so far are based heavily on anemic data structures, including Uncle Bob’s own showcase.

      I mean data structures are mentioned a lot, and I’ve seen no alternatives presented yet in general, but also specifically on the issue of crossing boundaries as described above.

      Can you provide some examples or more details?


      1. I will try to find code that I am allowed to share.. but even if I don’t I will try to extract something as an example.
        Still, the bitter reality is the I find CA a bit useless when taken directly without any modifications. In my case it was indeed the “anemic” issue and the complexity for simple scenarios.


  5. I’ve tested out Clean Architecture by quickly prototyping my app with dummy parts, and oh yes.

    Stable entities are impossible to come up with. Only basic data types and things like Url or PciId (backed by standards) are truly stable.

    Data-conversion classes become just functions when using Python, the procedural style really shows.

    Liked by 1 person

  6. I don’t get the issue with Use Case. You are right, the Use Cases are actually procedures that can describe the application logic. But what you are wrong is that you seem to think that you can only have one Use Case for a context. Because from your example, you said that “cash transfer” is the Use Case. While it is correct, you can also separate the steps into their own Use Cases. We can also use a Use Case as a dependency of another Use Case. We can also chain the Use Cases. This is where the scalability of using Use Cases come.

    So based on your example, we will have the:
    1. CheckAccountExistenceUseCase
    2. GetAccountTypeUseCase
    3. DetermineTransferLimitUseCase
    4. TransferAmountValidationUseCase
    5. GetAccountMoneyUseCase + CheckTransferAmountLessOrEqualAccountMoneyUseCase
    6. SubtractAccountMoneyUseCase
    7. CreateTransferUseCase + SendToClearingUseCase

    Now, all of these can be used to construct the “ExternalCashTransferUseCase”. And to expand it further with “InternalCashTransferUseCase”, we can just use a strategy pattern where we use “SendToClearingUseCase” for the external one and not for the internal one.


    1. But to make it more proper, we can refactor it into this:
      1. CheckAccountExistenceUseCase + GetAccountTypeUseCase + DetermineTransferLimitUseCase + GetAccountMoneyUseCase + SubtractAccountMoneyUseCase should be combined into one Entity called Account / AccountEntity that will be used to handle the Account domain / business logic. And in turn, Account entity will be used as the dependency of the UseCases
      2. TransferAmountValidationUseCase + CheckTransferAmountLessOrEqualAccountMoneyUseCase should be refactored into a TransferAmountValidationUseCase with 2 functions: validateByLimit() and validateByAccountMoney()
      3. CreateTransferUseCase + SendToClearingUseCase should be refactored into a Transfer entity.
      4. Create ExternalCashTransferUseCaseStrategy and InternalCashTransferUseCaseStrategy that implements ITransferUseCaseStrategy
      5. ExternalCashTransferUseCase and InternalCashTransferUseCase should use the Account, TransferAmountValidationUseCase and Transfer as the dependencies and use them accordingly.


      1. I just realized, there’s another thing that needs to be refactored:
        1. The CheckAccountExistenceUseCase should be a separate Use Case that uses AccountStore entity to get the account from the database or other storage.
        2. The CreateTransferUseCase can just use the Transfer entity’s constructor or a separate factory class as the Use Case.
        3. The SendToClearingUseCase can be just a method in the Transfer entity or a separate Use Case.

        To understand the whole process in Clean Architecture, we should really look at the whole picture. Since Use Cases, which hold the whole application-specific logic, will always work hand-in-hand Entities, which hold the whole business logic (can be either an object, or POJO), and Gateways / Interface-Adapters, which acts as the intermediary between the app and external resources.


    2. Thanks for your comments. I have two issues with your proposed solution.

      The first one is a little nitpick-y, I guess. The term “use-case” has a specific meaning in the industry. It means an action an external actor can trigger the system to do. I.e. something a user does with the application. Calling any and every step of a use-case also a use-case is a bit confusing, or at least not in line with the terminology. I can get past it, I’m just saying.

      My second point is more important, it is the same point I describe in the article. I agree with you that by doing procedures like the above, you can *reuse* steps easily. My point is that *reusing* steps is insufficient. What I want to do is *forget* about things.

      If you have the procedures you defined, you’ll have to keep a lot of things in your head. What procedures there are, what parameters they take, what do they do, in what order can I or even must I call these methods, etc. Yes, you’ve described the algorithm already, but it did not lessen my cognitive load, I still have to constantly keep everything in mind.

      Whereas, if you use objects, assign behavior to things, you can describe things in a way that lets me (the developer) forget or not know specific things. I can forget about checking the balance, or of double bookkeeping, or any of that, because there’s simply no other way to interact with things. Those are all automatically taken care of. In other words, I do not even have to re-use those things, therefore don’t have to know about them. It frees up my cognitive capacity, so I can increase the project size, hence it scales better.

      Before you say, sure, you can mix that with use-cases too: If you do the above consistently, there is nothing “left over”. Everything is a thing with its own behavior. There will never be a step-by-step description of some instructions of some use-case. (This is what the DCI paper criticizes OO for btw)

      Did that help to describe my position better?


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s