only one thing after discuss my doubt i am a mobile developer and i am trying to adapt DDD, and i say adapt because a lot of information is related to backend applications

My doubt start because i have a User class that is part of my model (im using MVP), and also in terms of DDD it´s a domain object, i know business logic should be in Domain Layer, and here start my first question

  1. My User class is not a plain object its also have functionality, methods like, storeUserInLocalDataBase or StoreCredentialsInKeyChain or createObjectWithJSON, this methods are related to the user so i left in User class, but keep a session is not part of business logic? the ability to remember the user credentials (StoreCredentialsInKeyChain) is not part of the business logic?, so in that way i think i should move that methods to the UserDomain class right?, and here start another doubt

  2. If i have a UserDomain class that means when i made my domain model or UML my User class should interact with other classes and components and the main character in this business process should be the User right? thats the reason i named the class UserDomain

  3. But what happened if there is a Mission model class as part of the UserDomain and a user can getCurrentMission?, this getCurrentMission is part of UserDomain or should be MissionDomain?

  4. What happened if Mission class has more logic? should be in the Model class like my first approach in the user class? or should i move that logic to the UserDomain class?, and if this happens with any other objects in UserDomain, my UserDomain class will be filled with a lot of logic from my Models classes and i guess this could be a problem or maybe not

So thats a few questions that i have i hope to be clear and you can understand why im so confused about this

Thanks, i will really appreciate your comments

  • Are you saying you have both a User class and a UserDomain class? What is the difference in purpose? – JacquesB Apr 25 '17 at 20:15
  • @JacquesB User class is like an entity with some helper methods, UserDomain is business related to the user – Mariano Apr 25 '17 at 22:13
  • 4
    Not all proper OO application architecture is DDD, and not all DDD is proper architecture – TheCatWhisperer Apr 26 '17 at 14:52
  • @TheCatWhisperer so in what cases do you think DDD is a proper architecture? – Mariano Apr 26 '17 at 15:47
  • 1
    Cases that are so complex, the application could easily be broken into many different applications... then there should be a compelling case why the applications cannot be separated. – TheCatWhisperer Apr 26 '17 at 15:49

If your phone gui maps to your web gui 1 to 1, you have a fairly easy issue to solve. Simply apply the MVC/MVP pattern properly. Your phone and web application can share everything except the View.

DB -> Business-Model -> Controller/Presenter -> View-Model -> Html Render/Desktop Gui
                                                     |------> Mobile App

Where you may have gone wrong, is that your models are ambiguous, that is to say, represent both both business entities and view models.

If there is substantial differences in the presentation but not business logic between the mobile and web apps, than you have to move the split lower down the chain:

DB -> Business-Model -> Business-Service -> Presenter -> View-Model -> GUI 
                                |->Mobile-Presenter -> M-View-Model -> GUI

And, if they work completely differently, then you have a lot of work...

DB -> Data-Service -> "  
             |------> "

In case it is not clear, you get your view-model to the mobile app via http/json

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.