Check out a free preview of the full Enterprise Architecture Patterns course

The "Object Modeling Q&A" Lesson is part of the full, Enterprise Architecture Patterns course featured in this preview video. Here's what you'd learn in this lesson:

Lukas answers questions about why it was necessary to create a BaseEntity class, why the string type was used for for the id, and strategies for abstracting the data modeling outside the home component.


Transcript from the "Object Modeling Q&A" Lesson

>> I briefly talked about why I use ID as a string and then why I extract it into like a base entity. So, good question and or a good request in the form of a question slash request. So the reason why I type out my IDs as strings is because the databases would generally generate a UID as an alphanumeric sequence.

And so I think one purely for compliance with if you're dealing with a database, you're maxing it out. More often than not, that's going to be a string as well as when you and so that's just for the kind of the default but by using an alphanumeric sequence you have a lot more options in terms of uniqueness because numbers just keep getting larger and larger and larger versus even reduce alphanumeric strings and it's able to get more versus unique sequences.

So that's one. The other reason why I use base entity is because it allows me to define my interfaces In a way that so the assumption here that I'm making is that every one of my entities is going to have an ID. If you're going to the database specifically, you will have an ID.

And so it's just a way for me to extract that piece out and focus just on kind of the extrinsic properties that I care about. And so it's just kind of a convenience method that, for me, I just assume that every kind of entity that I have is going to have an ID.

And so it's a way for me to not have to keep putting that in there. But by implementing the base entity is that I'm doing that via like, I'm contractually obligated to do that. And so I would I'm very judicious about how I use inheritance. And so I think you should be careful with this but I think a very specific single level inheritance is probably okay.

Some people will say that if you use inheritance at all, you're the devil. I don't agree with that And I think the balance is is just really being cognizant of it and being very judicious about how you use inheritance, okay?
>> So, you're imagining like you'd have multiple interfaces beyond the client, and they'd have the shared base identity of ID.

>> Right, and so, now, you're ensuring that all your entities have an ID. I am creating a coupling here, is that I'm coupling that all of my entities that use base entity to this base entity. So if I came in here, it just flippantly said, this is a number, then I break this.

In this is where you got to have to be careful about this, but in the case of I can safely say I want every entity to have an ID and I want it to be a string or no. And I'm willing to enforce that across all entities and I'm happy I'm okay with that coupling, then it's a fair trade off for me.

>> Yes, now I said that you have everything around, all around your home component and is there a way to better organize this or is this okay?
>> So the question is, everything's in the home component. And is there a better way to organize this? I would never do this for real.

Like this is like we're waxing the car right now. And so this is the only reason why it's even in this home component. Is because that I can come over here and I can render it. But for instance, you could or somebody could pick this up and I've done this entire example in inside of stack Blitz and you could just paste this in and.

Go here and then within this, just dump this out. Just go Tango, no,
>> Yeah. and if you look in the clo I mean in the world from the Gita, It actually is on their API interfaces.ts. So, yeah,
>> Yeah, so I did I did put the interface in.

I do have a top level interface, but I also for the sake of just kind of visual cohesion, it's all in one file. So the idea is we're just starting from nothing and we're gonna build on this. But you could do this in sight of stockless just like this and so.

>> And then another question I have is the reason you have the ID be either spring or Knoll is because when you're creating a new one, it's going to be no to begin with right?
>> So the question is, is the reason or rather comment, which the answer is yes.

Is the reason why I have string. Or ID being string or null is because I'm saying if it exists, it's going to be a string. But if it doesn't, if it's a new client, then it's just going to be null. And so this is typically how you delineate between a new entity and a pre existing entity is that there's an ID a unique ID, a unique identifier for that, so that is yeah, I think that's it.

So also just in case somebody showed up a little bit late that I'm running out of the mezzo application. I was previously floundering in the micro application but, the example that we're running for now is in the metro application, specifically the home component. And actually what we're doing has really nothing to do with angular, other than it just allows us to get a visual representation.

The question is are the solutions in, a branch and there are solutions in the code, and I'm not going to tell you where they are just yet. But if you poke around, you twist my arm, maybe I won't, but they're in the project and I've put them in there.

Okay, fine, you twisted my arm. If you look in each of the projects, you're gonna find a solutions, markdown file. And so kind of everything that I'm going to be typing and going. It's not a secret. Here's the notes. But I would recommend not speeding ahead and actually doing the challenges so that's the first one.

The question is can I explain state and so just briefly to offer commentary on that, objects, your domain model becomes your state. And so when you define a domain model is that your application when it's running, it is creating the essentially any number of those objects, which then produces or makes up your application state.

And this is why we start at the bottom, we do domain modeling and then we use that to construct our feature state and our application state. There's another question. Can I recommend a book on domain modeling? Off the top of my head, I believe pragmatic programmers has a couple pretty good books on this.

Typically, in this case, I would just go to Amazon search for domain modeling and choose the ones with the most stars that I could talk someone into buying and put it into my stocking for Christmas or whatever. But I believe pragmatic programmers has a good one. I'll think about that.

If I come up with it, I'll put the link in the chats for everybody to check out.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now