0

Business Logic Layer contains business objects that contains business logic. Some of them are persistent, those are Entities. Entities along with its logic make Model. Some of them are stateless and contains some extra logic that don’t fit in any entity responsibilities. Those objects are services (also part of Model?).

Then there are some helper/utilities classes like Managers, Factories, Builders. For now is this disassembly correct ?

Then there are objects that are not entities or services and can contain state. Active object that has his own thread. Can be long lived. What are those objects? Just Business Objects or maybe Business Components?

In my project I have Device class. At first I treated it like Entity object, because it is stored in DB. It contains own thread that periodically acquires some data from real device and do some complex logic with that data. So it is an active and long lived object. I realised that it cannot be an Entity because it is to heavy/complex and active and long lived object (or it can ???). So I split it to separate classes:

  • DeviceDescriptor, which is now Entity and
  • DeviceAccess ( or Device ), which contains complex business logic, is long lived and is active. It is also initialized on the basis of DeviceDescriptor object.

What kind of Business Objects is this DeviceAccess object?

If I have project which is structured like this, where should Device/DeviceAccess object be placed in namespace hierarchy?

  • ProjectName.Core – core objects, business objects
  • ProjectName.Core.Entities – persistence business objects
  • ProjectName.Core.Services – services interfaces
  • ProjectName.Core.Services.Default – real implementation of services
  • ProjectName.Core.Repositories – (DAL layer) repositories interfaces
  • ProjectName.Core.Repositories.SqlServer – real implementation of repositories

First I thought that I should put this object under Core namespace. But then I thought that maybe is better to treat it like separate component /module or feature and place it outside the Core namespace to ProjectName.Devices (along with other helper objects, repositories, and entities - DeviceDescriptor) . What do you think?

Could you also tell me if my namespace organisation is correct? It wasn’t guiding by DDD. It is rather 3-layer architecture with some concepts borrowed from DDD. (Repository, Aggregate root, Services, Model).

I will be grateful for any advice.

userx01233433
  • 366
  • 1
  • 4
  • 13

1 Answers1

0

Business Logic Layer contains business objects that contains business logic. Some of them are persistent, those are Entities. Entities along with its logic make Model. Some of them are stateless and contains some extra logic that don’t fit in any entity responsibilities. Those objects are services (also part of Model?).

A domain will contain aggregates, entities, value objects, events, services and so one. An entity simply means a concept that has a lifecycle and gets identified by an id.

Then there are some helper/utilities classes like Managers, Factories, Builders. For now is this disassembly correct ?

What are Managers? Do they represent a concept in the domain? A factory is best implemented on an aggregate root or entity. Think var post = forum.PostBy(user);. Builders can help you construct complex objects, supporting the language. For example; carBuilder.PaintedIn(red).Spinning(bigRims)....

Then there are objects that are not entities or services and can contain state. Active object that has his own thread. Can be long lived. What are those objects? Just Business Objects or maybe Business Components?

Maybe what you're looking for is a Saga or Process Manager?

In my project I have Device class. At first I treated it like Entity object, because it is stored in DB. It contains own thread that periodically acquires some data from real device and do some complex logic with that data. So it is an active and long lived object. I realised that it cannot be an Entity because it is to heavy/complex and active and long lived object (or it can ???). So I split it to separate classes..

It definitely can be an entity, probably an aggregate root. Are you composing the entity of multiple value objects? Value objects are a great way to encapsulate logic.

If I have project which is structured like this, where should Device/DeviceAccess object be placed in namespace hierarchy?

ProjectName.Core – core objects, business objects ProjectName.Core.Entities – persistence business objects ProjectName.Core.Services – services interfaces ProjectName.Core.Services.Default – real implementation of services ProjectName.Core.Repositories – (DAL layer) repositories interfaces ProjectName.Core.Repositories.SqlServer – real implementation of repositories

Have you considered namespacing based on functionality instead of technical patterns? Here is an example of namespacing commands based on functionality.

JefClaes
  • 3,275
  • 21
  • 23